1 2 3 Previous Next 44 Replies Latest reply: Dec 31, 2005 11:06 PM by Anil Saldhana RSS

JBoss Third Party Build

Ruel Loehr Novice

To get a complete libraries.ent file which will accommodate the third party directory being built from items in the repository, I feel that these are the steps which need to transpire:

1) create/update component-info.xml files for all modules under jbossas
a) some have not been created yet, others which do exist will need to be modified with compatibility information
b) a complete list of modules can be found here: http://jira.jboss.com/jira/browse/JBBUILD-1


2) create a top level jbossbuild.xml file which contains a componentref for each of the necessary modules (e.g. server, iiop, common)

3) generate a complete graph of components based off of what is defined in step (2)
a) when the graph is complete it will contain a component for each of the originally defined componentrefs as well as all dependencies required


4) generate libraries.ent file based off of the graph made in step (3)

5) Complete a build using the generated libraries.ent


Once this is verified we should have a thirdparty folder that is built dynamically from items in the repository as well as backwards compatibility for the buildmagic system. I am beginning today with component-info files.

Ruel Loehr
JBoss QA




  • 1. Re: JBoss Third Party Build
    Scott Stark Master

    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 Novice

    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 Expert

    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
    Scott Stark Master

    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 Novice

    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
    Scott Stark Master

    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 Novice

    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
    Scott Stark Master

    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 Novice

    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
    Scott Stark Master

    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 Novice

    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 Expert

    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 Novice

    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 Master

    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.

1 2 3 Previous Next