-
1. Re: JBoss Third Party Build
starksm64 Jun 22, 2005 10:40 PM (in response to ruel.loehr)Ok, but I first want to see 4.0 building from a repository generated thirdparty structure which only entails getting the repository populated for 1).
For 2), the existing jboss-4.0/build/build-thirdparty.xml needs to be populated with the componentrefs for the thirdparty repository libraries needed to build the server.
3-5 are the same.
I'm thinking that it will take less to get this working for 4.0 than introducing component-info.xml for every module. If you don't think this is the case, fine, but this needs to be working for the 4.0.3 release. -
2. Re: JBoss Third Party Build
ruel.loehr Jun 24, 2005 3:53 PM (in response to ruel.loehr)I worked with this yesterday and created a build-thirdparty.xml based off of what was in the thirdparty directory in the 4.0 branch. I found a couple of things that will need clarification.
1) hibernate thirdparty vs. hibernate module
Currently when we try to pull down the thirdparty modules the build sees a directory "hibernate" (our integration module). Because this module exists it will not pull down the thirdparty component "hibernate". How should we resolve this? The way the build is currently structured a thirdparty component cannot have the same name as a source module. Should the hibernate thirdparty be moved to jboss/hibernate?
2) what we use vs. what is there
If I go through every module under 4.0 (e.g. iiop, varia) looking at the build.xml file and look at what library classpaths are defined, and then creating a list of all library dependencies required, the list does not match the number of items in thirdparty. I assume some items in thirdparty (the early version of tomcat for example) are no longer used. Should I base the generated libraries.ent off of the cvs thirdparty dir as a whole, or just off of what is used.
3) naming conventions
Currently in the repository we have some dual directories, one called juddi, one called juddi-juddi. Which should I base off of?
4) new thirdparty items
In some cases, such as apache commons, the jars have been moved to their own repository locations. Won't this necessitate a change to the build.xml files ?
Thanks!
Ruel Loehr -
3. Re: JBoss Third Party Build
ryan.campbell Jun 24, 2005 4:08 PM (in response to ruel.loehr)1. This is a by product of using the directory name as the component id. We might be able to fix jbossbuild to have two components by the same name, one in thirdparty and one source component, but I'm afraid this leads to ambiguity.
We shouldn't rename the thirdparty hibernate. If anything, the hibernate integration module needs to be renamed to hibernate-intg or something.
2. just what is being used.
3. We aren't using the double named convention anymore, so just use juddi. Make sure it has the correct version from the 4.0 versions.xml
4. Yes it will, but let's commit what we have before making changes to build.xmls. -
4. Re: JBoss Third Party Build
starksm64 Jun 24, 2005 11:26 PM (in response to ruel.loehr)1) This is because there is a notion of a component and it can be either a source or binary module? The hibernate integration module can be changed in the current jboss-4.0.x definition:
jboss-4.0.x -d jboss-4.0 \ &_jboss_aop \ ... -d har hibernate \ ...
The build.xml modules reference to hibernate would have to be changed locally to do the build.
2) There certainly is tons of garbarge in there. The thirdparty build should be created by only referencing the direct dependencies of the toplevel components. Build the thirdparty strucuture and try the build and add thirdparty componentrefs as needed until it builds.
3) As Ryan said, drop the double name usage as its a cvs hack issue that we should not propagate.
4) The only place the new thirdparty lib names should be showing up at is in the libraries.ent definitions. Nearly all build files in the modules should simply be referencing the *.classpath from librariens.ent. The only problem will be that there will not be an aggregate classpath like apache.commons.classpath. You could deal with this by adding a notion of being able to merge multiple component paths to the libraries.ent generation:<path id="apache.commons.classpath"> <componentref id="apache-lang" /> <componentref id="apache-logging" /> <componentref id="apache-modeler" /> ... </path>
-
5. Re: JBoss Third Party Build
ruel.loehr Jun 25, 2005 5:47 PM (in response to ruel.loehr)Excellent! That leaves me with only two references from the collection of build.xml files that I am not sure how to handle.
1) ant
The current libraries.ent has an entry for ant.<!-- Ant --> <property name="apache.ant.root" value="${project.tools}"/> <property name="apache.ant.lib" value="${apache.ant.root}/lib"/> <path id="apache.ant.classpath"> <pathelement path="${apache.ant.lib}/ant.jar"/> </path>
The version of ant is found in the tools directory, not in the thirdparty. For the generated libraries.ent to have an entry for it, it would need to exist in the repository. How should we handle this?
2) EJB-Pesistence
The current libraries.ent handles ejb-persistence like this:<!-- hibernate3 --> <property name="hibernate.root" value="${project.thirdparty}/hibernate"/> <property name="hibernate.lib" value="${hibernate.root}/lib"/> <path id="hibernate3.classpath"> <pathelement path="${hibernate.lib}/hibernate3.jar"/> <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/> <pathelement path="${hibernate.lib}/asm.jar"/> <pathelement path="${hibernate.lib}/asm-attrs.jar"/> <pathelement path="${hibernate.lib}/antlr*.jar"/> </path> <!-- ejb3-persistence --> <path id="ejb3-persistence.classpath"> <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/> <pathelement path="${hibernate.lib}/hibernate-entitymanager.jar"/> <pathelement path="${hibernate.lib}/ejb3-persistence.jar"/> </path>
An ejb3-persistence classpath is defined, but it is part of hibernate (in the directory structure). The same problem exists as with ant. For an entry to be generated, it needs to have its own repository location, but does it make sense to break this out as a seperate entity?
Ruel Loehr
JBoss QA -
6. Re: JBoss Third Party Build
starksm64 Jun 25, 2005 6:31 PM (in response to ruel.loehr)1) Ant should be in the repository as well, but currently we do not include it into jboss. Tomcat used to until the switch to the jdt compiler. As of now there should be no need for this in libraries.ent.
2) So really, hibernate, hibernate annotations, and hibernate entitymanager (which is what I assme has the ejb3-persistence.jar artifact, ask Bill or Emmanuel) should be seperate entries in the repository as they are three seperate releases currently:
http://www.hibernate.org/6.html -
7. Re: JBoss Third Party Build
ruel.loehr Jul 1, 2005 4:01 PM (in response to ruel.loehr)I committed an initial pass at the thirdparty-build.xml file. At this point it should be a very close representation of what is required to build the 4.0 branch.
I am sure other adjustments will be required after generating the libraries.ent and attempting building (my next task) (e.g changing module names of hibernate & xdoclet).
user instructions:
mkdir test
cd test
cvs co -r Branch_4_0 jboss-4.0.x
cd jboss-4.0
cd build
ant -f build-thirdparty.xml
cd ../thirdparty
ls
Ruel Loehr
JBoss QA -
8. Re: JBoss Third Party Build
starksm64 Jul 5, 2005 10:56 AM (in response to ruel.loehr)It looks ok, but until the libraries.ent is generated and we can actually get the codebase to compile and tested I can't say for sure.
-
9. Re: JBoss Third Party Build
ruel.loehr Jul 5, 2005 5:24 PM (in response to ruel.loehr)While working on building I ran across an inconsistency with the old system. In the file modules.ent, from the buildmagic system, the following is defined:
<!-- AOP --> <property name="jboss.aop.root" value="${project.root}/thirdparty/jboss-aop"/> <property name="jboss.aop.lib" value="${jboss.aop.root}/lib"/> <path id="jboss.aop.classpath"> <pathelement path="${jboss.aop.lib}/jboss-aop.jar"/> </path>
This file defines only module properties except for the above. I think this definition should be moved to the libraries.ent file for the following reasons:
1) Consistency
2) If the property exists in the libraries.ent file we can give it the proper value (with the version number in the path) when we generate a new one. If it remains in the modules.ent the property is set and immutable. The build.xml would have to be modified to reference the correct path. (bad)
Are there any reasons why we couldn't or shouldn't do this?
Ruel Loehr
JBoss QA -
10. Re: JBoss Third Party Build
starksm64 Jul 6, 2005 3:09 PM (in response to ruel.loehr)No reason not to move it. The aop used to be a module in the jboss-4.0 but has now been moved to thirdparty and its classpath should be moved there as well.
-
11. Re: JBoss Third Party Build
ruel.loehr Jul 8, 2005 4:58 PM (in response to ruel.loehr)Using the thirdparty-build.xml definitions file, a generated libraries.ent file, and a generated thirdparty folder, I have succesfully completed builds using both the 1.4 and 1.5 compiler. The following instructions will execute this functionality.
mkdir test cd test cvs co -r Branch_4_0 jboss-4.0.x cd jboss-4.0 cd build ant -f build-thirdparty.xml generate-lib-file ./build.sh cd output cd jboss-4.0.3RC1 cd bin ./run.sh
The dependencies are downloaded and then the target "generate-lib-file" creates a libraries.ent file which has the correct path information.
I will continue work on validating the build and running the testsuite.
Ruel Loehr
JBoss QA -
12. Re: JBoss Third Party Build
ryan.campbell Jul 11, 2005 1:29 PM (in response to ruel.loehr)We should run the testsuite, but the easiest way to verify that the distros are exactly the same is just to compare the output of one with the other:
diff -br jboss-4.0/build/output/ jboss-4.0.x/build/output -
13. Re: JBoss Third Party Build
ruel.loehr Jul 11, 2005 5:25 PM (in response to ruel.loehr)The diff yielded excellent results. The structures are the same except for jar files which were constructed by the build, and these differ by only a few bytes (due to time stamps, or version numbers in the manifest files and such).
I do have one task left which needs to be resolved. The testsuite build.xml file uses /tools/etc/libraries.xml for its properties definitions while the rest of the modules use libraries.ent. Upon examination the files look to be relatively the same (libraries.xml is slightly out of date). Could we modify the libraries.xml to include the libraries.ent rather than redefining it? This way we would only have to worry about the maintenance of one file. -
14. Re: JBoss Third Party Build
adrian.brock Jul 11, 2005 5:34 PM (in response to ruel.loehr)Yes please. We should remove libraries.xml and replace it uses with libraries.ent
And do the same with modules.xml -> modules.ent
if you have the time while you are there.