1 2 3 Previous Next 44 Replies Latest reply: Dec 31, 2005 11:06 PM by Anil Saldanha 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 ?

            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" />

                • 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"/>

                  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"/>
                   <!-- 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"/>

                  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:


                    • 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

                      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"/>

                          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
                              cd output
                              cd jboss-4.0.3RC1
                              cd bin

                              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