JBossBuild issues - distribution building in declarative fas

[ruel.loehr]

One of things that I really like about the JBossBuild is that it can clearly separate different portions of the build (e.g. compilation declaration, deployment steps). The final step of releasing files is clearly described in the top level jbossas/jbossbuild.xml file. I also feel that this is perhaps one of the areas that is most in need of added flexibility.

For example when building the server and its different configurations we include a number of jboss-service.xml files, one in the minimal/conf, one in the all/conf and one in the default/conf folder. Looking at the deployment declaration for server we see the following:

<!--TODO this is a problem area as it is not easy to understand
 Currently we store a number of files and then rename and release them as jboss-service.xml
 to the various server configurations. -->
 <!-- conf -->
 <artifact id="jboss-minimal.xml" release="server/minimal/conf"
 outputpath="etc/conf/default" rename="true" tofile="jboss-service.xml"/>
 <artifact id="jboss-service.xml"
 outputpath="resources/jmx-invoker-adaptor/META-INF" filename="jmx-invoker-service.xml"
 release="server/all/deploy, server/default/deploy"/>
 <artifact id="conf-jboss-service.xml" release="server/all/conf, server/default/conf"
 filename="jboss-service.xml" outputpath="etc/conf/default"/>

In server/etc/conf/default a file exists called jboss-minimal.xml. It must be moved to server/minimal/conf and renamed to jboss-service.xml as part of the release process.

The file jmx-invoker-service.xml is located at resources/jmx-invoker-adaptor/META-INF and must be renamed to jboss-service.xml and placed in server/all/deploy and server/default/deploy.

Finally the file jboss-service.xml is located in /etc/conf/default. It is given an artifact id of ?conf-jboss-service.xml? to avoid the duplicate id problem and it will be released to server/all/conf and server/default/conf. An example problem would be deploying an artifact to two locations with two different names. This is currently not possible.

We tend to release files to multiple locations and I like the idea of breaking anything that is a list into seperate xml elements (saw this in Maven). A possible way of making this cleaner would like this:

 <artifact id="jboss-minimal.xml" outputpath="etc/conf/default">
 <release name="jboss-service.xml">server/minimal/conf</release>
 </artifact>
 <artifact id="jmx-invoker-service.xml" outputpath="resources/jmx-invoker-adaptor/META-INF">
 <release name="jboss-service.xml">server/all/deploy</release>
 <release name="jboss-service.xml">server/default/deploy</release>
 </artifact>
 <artifact id="jboss-service.xml" outputpath="etc/conf/default" >
 <release>server/all/conf</release>
 <release>server/default/conf</release>
 </artifact>

In this case release would be a type that describes what to do with an artifact. We would have to come up with a way to uniquely identify each release.

[ruel.loehr]

Ryan and I spent a little time talking about this yesterday and have taken the idea a step further. We wanted something that is easily understood, well grouped, and potentially reusable. The notion of profiles was then introduced. The top level build would looks something like this:

Snippet:

<build id="jbossas">

 <componentref name="common"
 module="jboss-common"
 version="5.0-SNAPSHOT"
 />

 <componentref name="oswego-concurrent" version="1.3.4" />
 <componentref name="dom4j" version="1.5" />
 <componentref name="apache-jaxme" version="0.2-cvs" />
 <componentref name="apache-log4j" version="1.2.8" />
 <componentref name="gnu-regexp" version="1.1.14" />
 <componentref name="apache-slide" version="2.0" />
 <componentref name="wutka-dtdparser" version="1.2.1" />
 <componentref name="apache-xerces" version="2.7.0" />
 <componentref name="apache-httpclient" version="2.0" />

 <deploymentprofile id="lib">
 <deployment artifact="commons-httpclient.jar" outputPath="lib"/>
 <deployment artifact="xercesImpl.jar" outputPath="lib/endorsed"/>
 </deploymentprofile>

 <deploymentprofile id="all">
 <deployment artifact="commons-httpclient.jar" outputPath="server/all/lib"/>
 <deployment artifact="dtdparser121.jar" outputPath="server/all/lib"/>
 </deploymentprofile>

 <deploymentprofile id="default">
 <deployment artifact="commons-httpclient.jar" outputPath="server/default/lib"/>
 </deploymentprofile>

 <deploymentprofile id="minimal">
 <deployment artifact="log4j.jar" outputPath="server/minimal/lib"/>
 </deploymentprofile>
 </build>

The first thing to notice is that all reference to artifacts have been stripped from the componentref tags. That portion of the declaration is merely stating what components are required to build jbossas. (I'll touch more on this in a different thread)

The deployment profiles are what dictates where the build outputs are placed. By partioning the deployment instructions into profiles we make it much easier to read and understand. I also think there is a lot of potential here. This could possibly be extended such that a deployment profile includes other deployment profiles. Another useful possiblity might be seperate deployment profiles for different conditions or os's.

On the back end of this is a custom ant task called by the release target to handle deployment. This task will look at each deployment profile and deploy each one of it's deployments to the proper location.

[ryan.campbell]

Suggested changes:

<profile id="minimal">
 <deployment artifact="log4j.jar" path="lib"/>
 </profile>

 <profile id="default">
 <deployment artifact="jbossweb-tomcat55.sar" path="deploy"/>
 <deployment profile="minimal"/>
 </profile>

 <profile id="all">
 <deployment artifact="jbossha.jar" path="lib"/>
 <deployment profile="default"/>
 </profile>

 <distribution path="jboss-5.0.0">
 <deployment profile="all" path="server/all"/>
 <deployment profile="default" path="server/default"/>
 <deployment profile="minimal" path="server/minimal"/>
 <deployment artifact="dom4j.jar" path="lib/endorsed"/>
 </distribution>
 </build>

1. Profiles are sets of artifacts relative to some root. ie, we don't want to duplicate "server/all" like we have been. We set the root for a profile when we create the distribution.

2. As you suggest, we can use composition. My example demonstrates this. This is the profile attribute on the deployment element above.

3. I changed your names to be less verbose ;-)

4. We are almost to a format that could be picked up by izpack?

5. Components should be able to contribute profiles via their component-info.xml.

[ryan.campbell]

We need the above profile/installer functionality regardless of whether we use maven2, jbossbuild, or buildmagic. I propose some ant tasks (which could be adapted to maven plugins) which do the following:

1. Allow components to contribute profiles, which can be compiled into a toplevel profile catalog. Basically an xml file.
2. A task to build jboss server configurations from this catalog. Used by the testsuite and toplevel build for distirbution building.
3. A task to build an izpack distribution from the catalog.

[ryan.campbell]

As for 1., whatever has the notion of the component tree will need to drive the creation of the profile catalog. For builidmagic, this will be in buildmagic.ent and build/build.xml. I will target bulidmagic initially, since I want this to be used ASAP.

So this task will basically concatenate all of the profile descriptors into a profile-catalog.xml, which will look something like this:

<profile id="minimal">
 <deployment artifact="log4j.jar" path="lib"/>
 </profile>

 <profile id="default">
 <deployment artifact="jbossweb-tomcat55.sar" path="deploy"/>
 <deployment profile="minimal"/>
 </profile>

 <profile id="all">
 <deployment artifact="jbossha.jar" path="lib"/>
 <deployment profile="default"/>
 </profile>

 <distribution path="jboss-5.0.0">
 <deployment profile="all" path="server/all"/>
 <deployment profile="default" path="server/default"/>
 <deployment profile="minimal" path="server/minimal"/>
 <deployment artifact="dom4j.jar" path="lib/endorsed"/>
 </distribution>
 </build>