component-info.xml vs release.xml artifacts

[tom.elrod]

For the remoting build I have updated the component-info.xml to look like:

<project name="remoting-component-info">
 <component id="remoting"
 module="jboss-remoting"
 version="5.0-SNAPSHOT">
 <artifact id="jboss-remoting.jar"/>
 <artifact id="jboss-remoting-tests.jar"/>
 <artifact id="jboss-remoting-loading-tests.jar"/>
 <export>
 <include input="jboss-remoting.jar"/>
 </export>
 </component>
</project>

which allows both the jboss-remoting-tests.jar and jboss-remoting-loading-test.jar to be built as part of the new build. I assume that these jars are not part of the ../output/jbossremoting-1.0.1beta/lib directory because they are not included in the export tag, but are in the ../output/lib directory (which all good so far).

So my question is if I need to change the release.xml to be any different? Right now, it is:

 <component id="remoting"
 module="jboss-remoting"
 version="5.0-SNAPSHOT"
 >
 <artifact id="jboss-remoting.jar" release="lib"/>
 </component>

 <includes id="remoting-project">
 <include input="jboss-remoting.jar"/>
 </includes>

I assume this is to declare the remoting component and the files related to the component (jboss-remoting.jar), which should be pulled from http://cruisecontrol.jboss.com/repository/remoting/5.0-SNAPSHOT/lib/. Then the includes tag decalres which component artifacts I actually want for my relase build?

So should I add the jboss-remoting-tests.jar and jboss-remoting-loading-test.jar as I did in the component-info.xml, but not add it in the includes?

Thanks.

-Tom

[ryan.campbell]

The component-info allows other components to reference your artifacts. It also allows you to create an artifactdef for that artifact in your jbossbuild.xml. IE, it must be declared before it can be implemented.

The release.xml (toplevel build) dictates your release structure, as well as what jars should be downloaded upon synchronize. However, it doesn't seem like you want these jars in your release and since you are building the remoting component from source, they won't be downloaded. So in this case, there is no practical value in adding these artifacts to the component definition in your release.xml.

That said, I think it's a good idea to keep these two in sync for now. I realize that this duplication is evil. I will detail in another thread where I think we should take the toplevel build. But for now, we should move forward with what we have and keep these two component declarations in sync.

Regarding the includes element in the release.xml. This was obsoleted by the component-info's export element. You should remove this from your release.xml for *all* components. I apologize for not doing this earlier as it just confuses the issue. So your release.xml should look like this:

 <component id="remoting"
 module="jboss-remoting"
 version="5.0-SNAPSHOT"
 >
 <artifact id="jboss-remoting.jar" release="lib"/>
 <artifact id="jboss-remoting-tests.jar"/>
 <artifact id="jboss-remoting-loading-tests.jar"/>
 </component>
 <!-- no includes id=remoting-project here -->

[starksm64]

How is the version info supposed to be tracked in the thirdparty? I'm updating the commons jars and I don't see any version info for the jars listed in this. These jars are basically indepdendent so there is no single version here.

<project name="apache-commons-component-info">

 <!-- ============================================================ -->
 <!-- Apache Commons -->
 <!-- ============================================================ -->

 <component id="apache-commons"
 licenseType="apache-2.0"
 version="mixed"
 projectHome="http://jakarta.apache.org/commons/index.html">

 <artifact id="commons-logging.jar"/>
 <artifact id="commons-httpclient.jar"/>
 <artifact id="commons-discovery.jar"/>
 <export>
 <include input="commons-logging.jar"/>
 <include input="commons-httpclient.jar"/>
 <include input="commons-discovery.jar"/>
 </export>
 </component>
</project>

[ryan.campbell]

This was an accomodation for testing the new build in jboss-head. The id of a component points to its location in the thirdparty directory. Now that we are populating thirdparty from the repository, I will need to decompose apache commons into individual components which can have their own versions.

<component id="apache-commons-logging"
 licenseType="apache-2.0"
 version="1.2"
 projectHome="http://jakarta.apache.org/commons/index.html">
 <artifact id="commons-logging.jar"/>
</component>
<component id="apache-commons-httpclient"
 licenseType="apache-2.0"
 version="1.3"
 projectHome="http://jakarta.apache.org/commons/index.html">
 <artifact id="commons-httpclient.jar"/>
</component>

This will also involve going in to each jbossbuild.xml and determining which parts of apache-commons it depends on and changing the

<source id="main">
 <include component="apache-commons"/>

to

<source id="main">
 <include component="apache-commons-logging"/>

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

[starksm64]

Ok, that is what I figured. Where is the thirdparty repository being populated from? Another baby step to getting the build integrated would be to actually build the 4.0 branch thirdparty contents from a checkout of the thirdparty repository. That way, there would be a single declarative statement in the form of a build file that defined what is going into a given 4.0.x release in terms of the thirdparty elements.

[ryan.campbell]

I see no reason why we couldn't do this for the 4.0 branch.

+ create an alias for jboss-4.0 which doesn't include the thirdparty directory (jboss-4.0-repo?)

+ add jbossas to jboss-4.0, and tag its contents as Branch_4_0.

+ remove all the jboss components from the jbossbuild.xml so that a synchronize will only download thirdparty components.

+ add synchronize target to build/build.xml which delegates to jbossas/jbossbuild.xml so that folks just need to:

ant synchronize
ant build

[ryan.campbell]

erm that should be:

ant synchronize
ant most

[starksm64]

So I created such a minimal build file that only references the apache-commons component:

<?xml version="1.0"?>

<project name="jbossas-thirdparty"
 default="synchronize"
 basedir=".">
 <!-- Import the types -->
 <import file="../tools/etc/jbossbuild/tasks.xml"/>

 <property file="synchronize.properties"/>
 <property file="local.properties"/>

 <build id="jbossas-thirdparty"
 impltitle="JBossAS"
 implversion="4.0.2"
 implvendor="JBoss Inc."
 implurl="http://www.jboss.org"
 description="JBoss Application Server"
 cvsroot="${cvs.prefix}@cvs.forge.jboss.com:/cvsroot/jboss"
 thirdpartypath="../thirdparty/"
 location="http://cruisecontrol.jboss.com/repository"
 targetdefs="targets">

 <component id="apache-commons"
 version="mixed">
 <artifact id="commons-logging.jar" release="lib"/>
 <artifact id="commons-httpclient.jar" release="lib"/>
 <artifact id="commons-discovery.jar"/>
 <artifact id="commons-collections.jar"/>
 </component>

 </build>

 <!-- Generate the targets -->
 <generate generate="jbossas-thirdparty"/>

</project>

but when I try to execute the build, it says there is no synchronize target. Using synchronize.artifacts works, so is that what you meant or is there a synchronize target that is supposed to be created?

[starksm@banshee9100 jboss-4.0_thirdparty]$ ant -projecthelp
Buildfile: build.xml
Overriding previous definition of reference to jbossas-thirdparty

Main targets:

 show Show the targets
 synchronize.artifacts Synchronize for all the artifacts
 synchronize.commons-collections.jar Synchronize for the artifact commons-collections.jar
 synchronize.commons-discovery.jar Synchronize for the artifact commons-discovery.jar
 synchronize.commons-httpclient.jar Synchronize for the artifact commons-httpclient.jar
 synchronize.commons-logging.jar Synchronize for the artifact commons-logging.jar
Default target: synchronize

[starksm@banshee9100 jboss-4.0_thirdparty]$ ant synchronize
Buildfile: build.xml
Overriding previous definition of reference to jbossas-thirdparty

BUILD FAILED
Target `synchronize' does not exist in this project.

Total time: 0 seconds

Also, why is there the

Overriding previous definition of reference to jbossas-thirdparty

message?

[ryan.campbell]

jbossbuild looks at the project name to determine if it should generate the toplevel targets such as "synchronize". If the project name of the current build file is "main.build", the toplevel targets will be generated.

Also,

Overriding previous definition of reference to jbossas-thirdparty

This occurs when you have two ant references with the same name. In this case, I'm guessing that the first ant reference is the project itself, and the second is the build element. Both of these are named "jbossas-thirdparty".

If you change the project name to "main.build" it will solve both of these problems.