SD-92 preview

[rbattenfeld]

Hi Andrew

This is a preview on SD-92.

I have done so far the following:

1. Enabled xslt transformation for the ironjacamar xsd's. The only missing transformation is the old dtd.
2. Full test case for the ironjacamar.xsd
3. A new module called cli for executing the xslt transformation on command line.
   a) First option via maven exec plugin. You can find in the cli/pom.xml an example that generates the
   java classes.
   b) Second option, with mvn assembly:assembly we can create a jar that contains all required classes.
   I think this would be very handy for the users.
4. Passing configuration. This version requires a properties file containing few parameters. You can configure
   almost everything. Even metadata.xslt and ddJava.xslt can be externalized. Of course, you can define the
   output folder for all three packages individually. I the most simplest case, only the context xml file is
   required (the schemaXXX.xml). In case of the assembled jar, the required xslt are extracted from the jar,
   copied to a configurable working folder, and then the generation is starting.

There are couple of questions:

1. Naming? Is cli ok? I don't have a preference here.
2. How should create the service files?
3. We should test the generation for all xsd's, which we now that these xsd's are used by others. Currently,
   the ironjacamar xsd are generated in the jboss context. But cli already generates these descriptors
   by executing the cli main class as part of the compile phase. Cool, the test cases are executed nicely,
   but I couldn't make the static test runnable. Comes later.
4. What is your opinion about the reqiuired dependencies on the other libraries? May this is in the
   responsibility of the user.

Let me know what you think.

Cheers,
Ralf

[jesperpedersen]

A couple of comments.

I don't mind using the IronJacamar XSDs as a test resource, however the official generated files will be within the IronJacamar project and the org.jboss.jca namespace. So the service files, and XSDs needs to be moved to src/test instead.

The official EE descriptors (1.0, 1.5 and 1.6) can stay.

An Apache Ant task and a Maven Mojo for the generator would be nice.

[rbattenfeld]

I think, this is almost designed in this way. In the properties file, you can specify the following:

1. The location of the XSDs to be transformed.
2. The different output directories for the generated interfaces, implementation and test classes.

In the context xml, you can bundle XSD's which should belong into same context, say Java EE 6 specs or all ironjacamar XSDs, whatever you like. In this xml file, you can define as well the package names.

I have included the IronJacamar XSD's only for this preview, later we should move it to a test area for regression testing.

Can you have a look at the pom.xml in the cli folder? There is a maven exec plugin that allows the execute the tool including passing of a configuration file. I hope this fullfills your requirements. Of course, the maven dependencies have to be configured accordingly.

[jesperpedersen]

Ok.

The Apache Ant task and Maven Mojo was just for easier integration in build environments.

[ALRubinger]

I'll look to dig in here at the top of the week when back from JavaOne and team meetings. :)

[rbattenfeld]

Cool:-)

I added in the meantime test cases for the datasource and resource adapter descriptors. All ironjacamar xsd's are now supported. I am starting with the dtd. There are two options I am evaluating:

1. Processing the dtd directly
2. Converting the dtd to xsd and then let the generator doing the rest. My XML editor (oxygen) supports this approach.

I have the feeling that option 2 is better.

[ALRubinger]

Can we schedule an IRC meeting for Tuesday w/ me, Ralf, and Jesper to discuss this? Propose 10AM EDT/4PM GMT+2.

[rbattenfeld]

That is fine for me (it is 16:00 GMT)

I have implemented a version that supports connector_1_0.dtd via conversion to an xsd. Static test case is implemented as well.

Additional question:

1. Shell we support the connector_1_0 via shrinkdesc or only via cli (generator tool)?
2. Currently, we cannot add the dtd reference () into the generated connector10 descriptor since this is not supported in the XmlDomDescriptorExporterImpl (SPI) class. Is that a problem?
3. All arguments in connector10 descriptors are strings. No boolean, integers at all. This is related to the dtd definition. Is that a problem?
4. Jesper, do you have a good example for a connectorDescriptor10 which we can use for static tests? I found one but this one is short.

[rbattenfeld]

Is the IRC meeting confirmed?

[ALRubinger]

I'll be at the IRC meeting, yep. :)

[ALRubinger]

This is now living https://github.com/shrinkwrap/descriptors/tree/SHRINKDESC-92.

Let's keep all development in our local forks synced there. And I'll also rebase this w/ upstream/master as appropriate.

[rbattenfeld]

I opened a discussion in the developer forum: http://community.jboss.org/thread/173534?tstart=0
I added a little description how to use the cli tool.