SHRINKDESC-92

[rbattenfeld]

Hi Jesper

The current preview provides good examples how to configure in the cli module.

• In src/test/resources/xml/schemasIronJacamar.xsd you can define your own package names. Please specify your XSDs location accordingly. Just copy it.
• The cli tool expects a property file with the following properties:
  • descriptor.cli.working.dir=target/test   --> mandatory, define a working directory
  • descriptor.cli.path.context.xml=src/test/resources/xml/schemasIronJacamar.xml  --> mandatory define here the path to your context file
  • descriptor.cli.result.dir.api=src/main/java  --> define here the path where the interface files are created. It is relative to the working directory
  • descriptor.cli.result.dir.impl=src/main/java  --> apply the same for the implementation files
  • descriptor.cli.result.dir.test=src/test/java  --> apply the same for the test files

You can execute the cli tool for example with the following maven settings:

      <plugin>

        <groupId>org.codehaus.mojo</groupId>

        <artifactId>exec-maven-plugin</artifactId>

        <version>1.1.1</version>

        <executions>

          <execution>

            <phase>compile</phase>

            <goals>

              <goal>java</goal>

            </goals>

            <configuration>

              <mainClass>org.jboss.shrinkwrap.descriptor.cli.Main</mainClass>

              <arguments>

                <argument>-c</argument>

                <argument>src/test/resources/ironjacamar.properties</argument>

              </arguments>

            </configuration>

          </execution>

        </executions>

      </plugin>

Finally, you have to create the service files manually. You can find examples in

shrinkwrap-descriptors-cli/src/main/resources/META-INF/services

Let me know if you have problems.

Cheers

Ralf

[jesper.pedersen]

I think having it as arguments to the Main class would also be ideal:

org.jboss.shrinkwrap.descriptor.cli.Main -target build -package org.jboss.jca.common.dsl.ironjacamar /path/to/ironjacamar_1_0.xsd

would generate

build/org/jboss/jca/common/dsl/ironjacamar/api
build/org/jboss/jca/common/dsl/ironjacamar/impl

directories with the files in them based on the XSD. Having test classes generated should be optional IMHO.

If you do

public class Main {

    void setTarget(String v) {}
    String getTarget() {}

    // and so on
}

it would be easy to create the Ant Task and Maven MOJO for the generator. See https://github.com/jesperpedersen/tattletale/blob/master/src/main/java/org/jboss/tattletale/ant/ReportTask.java of how I did it in Tattletale.

It should be possible to generate the service files too...

[rbattenfeld]

Cool. Yes this as well possible. I will change the implementation as you have suggested. Two things are a little bit complicated:

• The context xml is still mandatory. The generation process requires such a file. So, I cannot leave this file out. That means, this file must be passed as parameter.
• Making the test classes optionally

I focus on this. The moving the ironjacamar xsd's is already done.

[rbattenfeld]

I worked on this. You can have alook at: https://github.com/shrinkwrap/descriptors/pull/53

My repo for covering SHRINKDESC-92 is: https://github.com/rbattenfeld/descriptors/tree/SHRINKDESC-92

Meanwhile, I have an idea how to make test cases optional and also how to generating the service files. Comes soon:-)

[jesper.pedersen]

It must possible then to bundle a default context.xml file and use that one - loaded as resource through the classloader of the cli.

You missed the "TransformerTask extends org.apache.tools.ant.Task" requirement... Also include an antlib.xml file in the .jar which identifies the available tasks. Same thing for Maven: org.apache.maven.plugin.AbstractMojo + plugin.xml

[rbattenfeld]

Yes, I will enhance the ant task. Cool, I am learning these ant + maven tasks

I am not sure about the context file. It looks strange to me that part of the configurations are passed via command line args but the context file not. The context file is part of the user configuration and defines in your case the ironjacamar xsd files. Even the name of the file is not static.

Why not having this file somewhere in your build system?

[jesper.pedersen]

Well, the context.xml file can be argument, but having the settings exposed directly through command line arguments, Ant or Maven properties would be better IMHO.

<descriptor-generator src="${resources.dir}/ironjacamar_1_0.xsd"
                                   dest="${target.dir}"
                                   include-testsuite="false">
    <package>org.jboss.jca.common.dsl.ironjacamar</package>
</descriptor-generator>

and so on.

[rbattenfeld]

Hmm, I see your point. There are two reasons why this is difficult:

1. The first xslt transformation requires exactly such a xml file. Even  we could pass everything over command line, these arguments have to be written to an xml file.
2. The number of arguments. I think even for the IronJacamar descriptors are about 10-15 arguments required. That is compared to other descriptors not so much. If you see the schemaJava6.xml file with all the descriptors belonging together, you will end up by passing up 100 command line arguments.

I will work over the weekend for resolving the things you have mentioned.

Regards,

Ralf

[jesper.pedersen]

The first xslt transformation requires exactly such a xml file. Even  we could pass everything over command line, these arguments have to be written to an xml file.

Well, hacks like taking the parameters passed and writing out an XML file based on those, and then pass that could work. Maybe system properties could be used for substitution...

The number of arguments. I think even for the IronJacamar descriptors are about 10-15 arguments required. That is compared to other descriptors not so much. If you see the schemaJava6.xml file with all the descriptors belonging together, you will end up by passing up 100 command line arguments.

Yeah, it is basically two different "schools" - I find it is easier for people to understand if everything is exposed directly in the build environment files (build.xml / pom.xml) versus "hidden" in a configuration file.

However, we should also look at it from a time PoV - using a configuration file and exposing the path to that in the build environment takes the least amount of time. Improvements can always be made down the road.

And since you are doing the coding means that you get to decide

[rbattenfeld]

Hi Jesper

You are right, we can go futher with the configuration file and improved it later. I would love to support all of your suggestions but I don't see a practical  solution at the moment.

I implemented so far the maven plugin and the ant task according the guide lines I found. I am stuck at the moment with writing test cases for the maven cli plugin. How do you tested the tattletate maven plugin (and the ant task)? According http://maven.apache.org/plugin-developers/plugin-testing.html

there are several test strategies available. The one with using maven-plugin-testing-harness throws an exception during the setup of, I guess, plexus stuff.

[jesper.pedersen]

I don't have any automated test suite for those - just a manual test. So up to you

[rbattenfeld]

The maven plugin is running. You can integrate it with the following declaration:

<plugin>

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

        <artifactId>shrinkwrap-descriptors-cli-plugin</artifactId>

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

        <executions>

          <execution>

            <id>transform</id>

            <phase>install</phase>

            <goals>

              <goal>transform</goal>

            </goals>

            <configuration>

              <contextFile>${project.build.directory}/../../cli/src/test/resources/xml/schemasIronJacamar.xml</contextFile>             

              <targetDir>${project.build.directory}/../../cli-test/src/main/java</targetDir>             

              <testDir>${project.build.directory}/../../cli-test/src/test/java</testDir>

              <tempDir>${project.build.directory}/cli</tempDir>             

              <trace>true</trace>

            </configuration>

          </execution>         

        </executions>

      </plugin>

Two things are not done so far:

• The ant task is not tested
• Generating of the service files

When you define an empty <testDir></testDir> then the test cases are not generated.

Do you need the ant task really?

Let me know what you think and how to proceed.

Regards,

Ralf

[alrubinger]

Hey Ralf:

So per our last discussion in Stuttgart, I went to pull your latest rbattenfeld/SHRINKDESC-92 commits into upstream/SHRINKDESC-92.  Some blockers on there, however:

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

If you ping back when this is resolved then I'll squash it all and put into the upstream sync point for further dev on SHRINKDESC-92.

S,
ALR

[rbattenfeld]

Heya Andrew

Yep, I will have a look. I will tweet you when this is resolved. Have a good time at the devoxx converence.

Tx, Ralf

[rbattenfeld]

Hi Jesper

Did you had a chance to look at the latest push? The current version should support almost everything you need. I couldn't test the ant task but the maven plugin task is integrated and is part of the build, e.g. it produces the ironjacamer descriptors which is then tested by the following cli-test module.

Let me know, if you need help.

Tx,

Ralf