-
1. Re: component-info.xml vs release.xml artifacts
ryan.campbell Apr 26, 2005 3:12 PM (in response to tom.elrod)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 -->
-
2. Re: component-info.xml vs release.xml artifacts
starksm64 Apr 26, 2005 6:24 PM (in response to tom.elrod)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>
-
3. Re: component-info.xml vs release.xml artifacts
ryan.campbell Apr 26, 2005 7:26 PM (in response to tom.elrod)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 -
4. Re: component-info.xml vs release.xml artifacts
starksm64 Apr 26, 2005 8:59 PM (in response to tom.elrod)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.
-
5. Re: component-info.xml vs release.xml artifacts
ryan.campbell Apr 27, 2005 4:07 PM (in response to tom.elrod)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 -
6. Re: component-info.xml vs release.xml artifacts
ryan.campbell Apr 27, 2005 4:09 PM (in response to tom.elrod)erm that should be:
ant synchronize
ant most -
7. Re: component-info.xml vs release.xml artifacts
starksm64 May 2, 2005 2:47 PM (in response to tom.elrod)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 theOverriding previous definition of reference to jbossas-thirdparty
message? -
8. Re: component-info.xml vs release.xml artifacts
ryan.campbell May 2, 2005 3:42 PM (in response to tom.elrod)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.