6 Replies Latest reply: Mar 27, 2012 2:45 AM by Andrew Rubinger RSS

Shrinkwrap Descriptor Metadata Plugin

Ralf Battenfeld Novice

Hi Folks

 

I am making great progress regarding the Descriptor Metadata plugin. This maven plugin allows to create descriptors much simpler than before. The request is based in SHRINKDESC-92 asking for a tool that allows to generate descriptors separated from the descriptor build. Thanks to Jesper for the suggestions.

 

The usage is fairly simple:

 

            <plugin>

                <groupId>org.jboss.shrinkwrap.descriptors</groupId>

                <artifactId>shrinkwrap-descriptors-metadata-parser</artifactId>

                <version>${project.version}</version>

                <executions>

                    <execution>

                        <id>execution1</id>

                        <phase>validate</phase>

                        <configuration>

                            <verbose>true</verbose>

                            <path>

                                <pathToApi>${basedir}/src/main/java</pathToApi>

                                <pathToImpl>${basedir}/src/main/java</pathToImpl>

                                <pathToTest>${basedir}/src/test/java</pathToTest>

                                <pathToServices>${basedir}/src/main/resources/META-INF/services</pathToServices>

                            </path>

                            <descriptors>

                                <descriptor>

                                    <pathToXsd>${basedir}/src/test/resources/xsd/ironjacamar_1_0.xsd</pathToXsd>

                                    <nameSpace>ironjacamar</nameSpace>

                                    <packageApi>org.jboss.ironjacamar.api</packageApi>

                                    <packageImpl>org.jboss.ironjacamar.impl</packageImpl>

                                    <descriptorName>IronjacamarDescriptor</descriptorName>

                                    <elementName>ironjacamar</elementName>

                                    <elementType>ironjacamar:ironjacamarType</elementType>

                                </descriptor>

                            </descriptors>

                        </configuration>

                        <goals>

                            <goal>parse</goal>

                        </goals>

                    </execution>

                </executions>

            </plugin>

 

Here are some details:

  • Native supports of dtd files
  • Parsing of xsd's are rewritten from ground by using DOM stuff (no xslt)
  • Generating java code is still based on xslt but the plan is to replace this in the future as well. See CodeModel which is as well a fork from jaxb
  • Supports xsd's in a much higher level without enhancements. Example: orm.xsd is parsed without any issues. Cool:-)

 

I have to continue this. Goal is to use this plugin for all descriptors we create. Stay tuned

  • 1. Re: Shrinkwrap Descriptor Metadata Plugin
    Andrew Rubinger Master

    Amazing!  DTD support!  And phase 1 of the parsing of XSD uses no XSLT?  You're on fire!

     

    I'm not sure I yet showed you this, but I'd set up a CI job to track specifically your branch:

     

      https://shrinkwrap.ci.cloudbees.com/job/ShrinkWrap_Descriptors_rbattenfeld-SHRINKDESC-92/

     

    There's also one for the upstream/SHRINKDESC-92:

     

      https://shrinkwrap.ci.cloudbees.com/job/ShrinkWrap_Descriptors_upstream-SHRINKDESC-92/

     

    This is all now in upstream/SHRINKDESC-92.


    S,

    ALR

  • 2. Re: Shrinkwrap Descriptor Metadata Plugin
    Ralf Battenfeld Novice

    Hi Andrew and Bartosz

     

    The latest version includes the following features:

    • all descriptors are generated now by the new maven based metadata plugin.
    • dtd descriptors are natively supported by using the dtd-parser library
    • new are orm_1_0.xsd and orm_2_0.xsd generated. I think, persistence.xml without orm is incomplete.
    • as SD-98 requests, configure.dtd (jetty) is generated. I created seperate modules for this (api-misc/impl-misc)
    • the service files under META-INF/services can be generated as well

    Some general comments about the plugin. The plugin will support much more descriptor out of the box because there are no hacks any more implemented covering a particular descriptor definition. I have to write little more test directly testing XSD specifications but this comes later.

    Have fun!

    Ralf

  • 3. Re: Shrinkwrap Descriptor Metadata Plugin
    Andrew Rubinger Master

    Super!

     

    I've added the latest two commits to upstream/SHRINKDESC-92.

     

    Next steps:

    • Define a roadmap for release
    • Merge SHRINKDESC-92 into upstream
    • Possibly branch out upstream into a maintenance branch?
    • Review the entire API for consistency
    • Start cutting releases off the new APIs

     

    Anything else?  Else I'll start a roadmap with some course dates.

     

    S,

    ALR

  • 4. Re: Shrinkwrap Descriptor Metadata Plugin
    Bartosz Majsak Master

    Sorry for being late in the train guys, but I'm deep into Arquillian Persistence Extension atm... I will have a look at the code this week, you have my word Awesome stuff Ralf!

  • 5. Re: Shrinkwrap Descriptor Metadata Plugin
    Ralf Battenfeld Novice

    Thanks Andrew and Bartosz

     

    I have just two add-ons:

    1. mid-term: Writing test cases based on the XSD specification rather than on particular descriptor XSD. Hoping to solve missing XSD feature in advance:-)
    2. long-term: Replacing the XSLT java code generation by a framework like Code Model or something else.

     

    Tx

    Ralf

  • 6. Re: Shrinkwrap Descriptor Metadata Plugin
    Andrew Rubinger Master

    I've released this prototyping in 2.0.0-alpha-1 and have closed SHRINKDESC-92.

     

     

    Ralf Battenfeld wrote:

    I have just two add-ons:

    1. mid-term: Writing test cases based on the XSD specification rather than on particular descriptor XSD. Hoping to solve missing XSD feature in advance:-)

    We'll see how this pans out now that it's released.

     

     

    1. long-term: Replacing the XSLT java code generation by a framework like Code Model or something else.

    Does this assume that the end-user configuration stays the same?  Looks that way, judging by how we configure gen/pom.xml right now.  If so, that's fine (because the XSLT bit is then a nicely-encapsulated implementation internal).

     

    S,

    ALR