4 Replies Latest reply on Oct 19, 2005 11:38 AM by Adrian Brock

    JBoss build - head is buildable

    Ruel Loehr Novice

      I have added the functionality to JBossBuild such that all of the appropiate modules in head can now be built and can produce a build output that is nearly identical to one that is produced by buildmagic. As a disclaimer, I will also note that the since the contents of head build files change rapidly a "nearly" identical build state does not last long, but IS achievable. This work is a logical extension of what Adrian initially wrote and Ryan continued.

      So at this point we have a build that can pull the source from cvs, the binaries from the repository, generate any needed source, build the source files, and construct the necessary artifacts and place them in the correct location for release. Also, we can build and release conditionally based upon which jdk compiler is used. I have setup the testsuite in the JBossbuild environment as well in order to get an idea that the build "works".

      In the course of accomplishing this we have found areas of the build which I feel still need work before it is ready for "prime time". The course of action will be to detail in this thread each of these areas, the problem description, a proposed solution and a plan of action for resolving it.

      The instructions for checkout and building are as follows:

      mkdir jbbuild
      cd jbbuild
      cvs co jbossas
      cvs co tools
      cd jbossas
      ant synchronize
      ant


      The testsuite does not get checked out upon synchronization yet for reasons I will detail later. Currently, it simply piggybacks the buildmagic system. In order to use it:

      cvs co -d testsuite jbosstest
      cd testsuite
      ant -f jbossbuild.xml
      ant -f jbossbuild.xml tests


        • 1. Re: JBoss build - head is buildable
          Adrian Brock Master

          Congrats!

          "rloehr@jboss.com" wrote:

          cvs co jbossas
          cvs co tools


          These should be consolidated into a single alias in CVSROOT/modules.
          Unfortunately, jbossas has been hijacked for other purposes by people
          that treat cvs modules as "dumping grounds".

          It would be a good idea to create a separate top-level module that doesn't
          include all that "integration" rubbish.


          ant synchronize
          ant


          You used to be able to type "ant rebuild" to do both of these in one step?

          • 2. Re: JBoss build - head is buildable
            Ruel Loehr Novice

            Thank you. I'm in agreement with the idea of a single module alias and a seperate top level module. Before I get to that though, I would like to get the discussion rolling on some of the issues which I have found and the best way of addressing them.

            Synchronization Issues:

            At the top level, we define which dependencies we need project wide. A real world example of this looks like:

             <component name="apache-httpclient" version="2.0" >
             <artifact id="commons-httpclient.jar" release="lib, server/all/lib, server/default/lib"/>
             </component>


            This declaration declares a component called apache-httpclient. This component consists of a single jar file, commons-httpclient with a version 2.0 and also describes what happens to this jar file in the release cycle. When targets are generated for this definition they will be named:

            synchronize.apache-httpclient and
            synchonize.commons-httpclient.jar

            Currently, no problems our presented with the present system, but looking ahead could possibly encounter a situation such as the following:

             <component name="foo" version="2.0" >
             <artifact id="foo.jar" />
             <artifact id="local.properties" />
             </component>
             <component name="foobar" version="2.0" >
             <artifact id="foobar.jar" />
             <artifact id="local.properties" />
             </component>
            


            This situation will create a problem as the target local.properties will be generated twice resulting in an ANT error.

            We can see that target generation based off of the artifact id could possibly lead to errors and adds the requirement that artifacts housed in the repository must have unique filenames.. The immediate solution would be to modify the target generation to create targets based off of some unique identifaction schema . Perhaps the schema target.component-name.artifact-id (e.g. synchronize.foobar.local.properties. This would assume of, course, that each artifact within a component would be unique.


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

            • 3. Synch issues - continued
              Ruel Loehr Novice

              The second synchronization issue which I ran across is a checkout vs. compilation issue. When I instruct the build to do a sychronization (checkout) I would like the testsuite module to be checked out but do not want it to be compiled as part of the default build (mirroring the buildmagic functionality).

              It would seem we would need some type of attribute which would dictate if something is built by default (if this is really a requirement).

              <component id="testsuite"
               module="jbosstest"
               version="5.0-SNAPSHOT"
               compile="false"
               >
               </component>


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

              • 4. Re: JBoss build - head is buildable
                Adrian Brock Master

                Can you split different issues into separate posts
                http://wiki.jboss.org/wiki/Wiki.jsp?page=BadPostTooDemanding

                Issue 1.
                The idea of naming artifacts was that they would go into the release (where you
                obviously can't have competing names).
                Those aliases were added by Ryan to simplfy the dependencies.
                Read the previous discussions.

                Issue 2.
                Looks ok to me if there is still a simple way to detect that something that
                should only be built locally.