JBoss Build Functionality

[ruel.loehr]

I've been back at work writing jbossbuild.xml files to mirror the buildmagic functionality. A reoccurring theme that I see developers do is:

1) build the module creating jars in the output/lib directory
2) create a new directory under output
3) add jars to that directory
4) add files from the source tree to the directory

We want to mirror this in a flexible, yet declarative fashion.

Let's use tomcat at as an example.

1) First, we compile a jar called tomcat55-service.jar.
2) Tomcat needs a directory, /output/deploy, to be created.

<artifact id="jbossweb-tomcat55.sar" artifacttype="dir" outputpath="deploy"/>

3) Next, tomcat wants to fill that directory with random jars and files

 <!-- note that this is a declaration of a directory -->
 <artifactdef artifact="jbossweb-tomcat55" outputpath="deploy">

 <include component="apache-tomcat"/>
 <include component="apache-modeler"/>
 <include input="tomcat55-service.jar"/>

 <!-- we want to put web.xml in output/deploy/conf -->
 <include input="tomcat-resources" attribute="conf">
 <include pattern="web.xml"/>
 </include>
 </artifactdef>

We are able to make the system place these items where we want by using the prefix tag, and this works well for files of zip nature (e.g. jar, ears, wars and sars), however for directories it does not.

For each artifact type we have a set of instructions for how to handle it:

 <dir>
 <mkdir dir="@{output}"/>
 <copy todir="@{output}">
 <filesets/>
 </copy>
 </dir>

Anytime a prefix attribute is used for an include, a zipfileset is created. In the above, filesets is a macro which is essentially a zipfileset. Unfortunately, the ant copy task does not support the zipfileset type.
The only solution we see at this point is to write our own copy task which can support the zipfileset.

Thoughts on this?

[adrian.brock]

We discussed this before about 6 months ago.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=60599

Or in summary, lets try to make a simple/direct incremental build
rather than jaring/unjaring all over the place.

[starksm64]

I would not look at the current build constructs as well thought out. This is a pile that has accumulated over 4 years now without much thought to consistency. We should first think about an easy to understand artifact notion that is sufficient for the artifacts we build and then resolve how it applies to the current usage.

Many uses are convoluted by incorrect cvs module definitions, and notion of the jbossas release build leaking into a component artifact. We need to be thinking about how I can reuse the component module including its artifact outputs in differing higher level aggregate projects from jbossas to new packaging of projects such as seam+ejb3+tomcat.