JBoss build - head is buildable

[ruel.loehr]

I have added the functionality to JBossBuild such that all of the appropiate modules in head can now be built and can produce a build output that is nearly identical to one that is produced by buildmagic. As a disclaimer, I will also note that the since the contents of head build files change rapidly a "nearly" identical build state does not last long, but IS achievable. This work is a logical extension of what Adrian initially wrote and Ryan continued.

So at this point we have a build that can pull the source from cvs, the binaries from the repository, generate any needed source, build the source files, and construct the necessary artifacts and place them in the correct location for release. Also, we can build and release conditionally based upon which jdk compiler is used. I have setup the testsuite in the JBossbuild environment as well in order to get an idea that the build "works".

In the course of accomplishing this we have found areas of the build which I feel still need work before it is ready for "prime time". The course of action will be to detail in this thread each of these areas, the problem description, a proposed solution and a plan of action for resolving it.

The instructions for checkout and building are as follows:

mkdir jbbuild
cd jbbuild
cvs co jbossas
cvs co tools
cd jbossas
ant synchronize
ant

The testsuite does not get checked out upon synchronization yet for reasons I will detail later. Currently, it simply piggybacks the buildmagic system. In order to use it:

cvs co -d testsuite jbosstest
cd testsuite
ant -f jbossbuild.xml
ant -f jbossbuild.xml tests

[adrian.brock]

Congrats!

cvs co jbossas
cvs co tools

These should be consolidated into a single alias in CVSROOT/modules.
Unfortunately, jbossas has been hijacked for other purposes by people
that treat cvs modules as "dumping grounds".

It would be a good idea to create a separate top-level module that doesn't
include all that "integration" rubbish.

ant synchronize
ant

You used to be able to type "ant rebuild" to do both of these in one step?

[ruel.loehr]

Thank you. I'm in agreement with the idea of a single module alias and a seperate top level module. Before I get to that though, I would like to get the discussion rolling on some of the issues which I have found and the best way of addressing them.

Synchronization Issues:

At the top level, we define which dependencies we need project wide. A real world example of this looks like:

 <component name="apache-httpclient" version="2.0" >
 <artifact id="commons-httpclient.jar" release="lib, server/all/lib, server/default/lib"/>
 </component>

This declaration declares a component called apache-httpclient. This component consists of a single jar file, commons-httpclient with a version 2.0 and also describes what happens to this jar file in the release cycle. When targets are generated for this definition they will be named:

synchronize.apache-httpclient and
synchonize.commons-httpclient.jar

Currently, no problems our presented with the present system, but looking ahead could possibly encounter a situation such as the following:

 <component name="foo" version="2.0" >
 <artifact id="foo.jar" />
 <artifact id="local.properties" />
 </component>
 <component name="foobar" version="2.0" >
 <artifact id="foobar.jar" />
 <artifact id="local.properties" />
 </component>

This situation will create a problem as the target local.properties will be generated twice resulting in an ANT error.

We can see that target generation based off of the artifact id could possibly lead to errors and adds the requirement that artifacts housed in the repository must have unique filenames.. The immediate solution would be to modify the target generation to create targets based off of some unique identifaction schema . Perhaps the schema target.component-name.artifact-id (e.g. synchronize.foobar.local.properties. This would assume of, course, that each artifact within a component would be unique.


http://jira.jboss.com/jira/browse/JBBUILD-169

[ruel.loehr]

The second synchronization issue which I ran across is a checkout vs. compilation issue. When I instruct the build to do a sychronization (checkout) I would like the testsuite module to be checked out but do not want it to be compiled as part of the default build (mirroring the buildmagic functionality).

It would seem we would need some type of attribute which would dictate if something is built by default (if this is really a requirement).

<component id="testsuite"
 module="jbosstest"
 version="5.0-SNAPSHOT"
 compile="false"
 >
 </component>

http://jira.jboss.com/jira/browse/JBBUILD-170

[adrian.brock]

Can you split different issues into separate posts
http://wiki.jboss.org/wiki/Wiki.jsp?page=BadPostTooDemanding

Issue 1.
The idea of naming artifacts was that they would go into the release (where you
obviously can't have competing names).
Those aliases were added by Ryan to simplfy the dependencies.
Read the previous discussions.

Issue 2.
Looks ok to me if there is still a simple way to detect that something that
should only be built locally.