1 2 3 Previous Next 44 Replies Latest reply: Dec 31, 2005 11:06 PM by Anil Saldhana Go to original post RSS
  • 15. Re: JBoss Third Party Build
    Ruel Loehr Novice

    As the build based upon the repository is now complete my next thoughts are on how is the best way to deploy this.

    A couple of points to consider are :
    1) Maintaining backwards compatability
    2) How maintenance will occur when changing the version of a dependency

    At one point it was discussed that a thirdparty folder that has been generated from the repository would be checked into cvs. This folder would then be aliased into the 4.0.x module. Does this still hold true?

    Whenever the build-thirdparty.xml file is modified a few events will need to transpire:

    1) Regenerate the thirdparty directory
    2) Check-in changes
    3) Generate a new libraries.ent file
    4) Check-in changes

    (provided that these items are being stored in cvs).

    Previously we had discussed storing the libraries.ent file as an artifact somewhere in the thirdparty directory. At some point (preferably build time) we must choose which version of the libraries.ent file to use; the one which contains the repository path structure, or the existing libraries.ent. This could be determined via a property passed in to the script.

    Thoughts?

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

    I'm inclined to not checkin the thirdparty contents into cvs and to simply change the directions for building 4.0.3+ to include using the jboss-4.0.x cvs alias. The first dependency of the jboss-4.0/build/build.xml should be to build the thirdparty contents based on the build-thirdparty.xml.

    The libraries.ent file should be an artifact generated in the thirdparty directory and the scripts should be updated to use this version.

    The source release associated with a dist would continue to include the thirdparty contents so that its a self contained bundle.

    The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions.

  • 17. Re: JBoss Third Party Build
    Adrian Brock Master

     

    "scott.stark@jboss.org" wrote:

    The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions.


    This already exists as part of the "synchronize" in the new build, but it has been
    broken by all the refactoring.

  • 18. Re: JBoss Third Party Build
    Ruel Loehr Novice

    Two issues have come up today which I would like to get confirmation on.

    1) libraries.ent generation location

    If we generate a libraries.ent and store it in the thirdparty folder this will require a change to the build.xml files. The buildfiles currently reference it in this manner:

    ENTITY libraries SYSTEM "../tools/buildmagic/etc/libraries.ent"
    which we change to look like this:

    ENTITY libraries SYSTEM "../thirdparty/libraries.ent"


    If this were to be modified to point to the thirdparty location we will have a problem when the thirdparty folder is not yet present. For example, if we were to perform a clean checkout of JBoss-4.0.x (which does not pull down the thirdparty folder) and then try to build we will immediately get an exception stating that the the libraries.ent file is not found. This is valid as we have not generated it yet.

    A simple solution would be to place the generated file in the same location as the pre-existing file. If a user ever wished to revert back he would simply pull down the old version from cvs.

    Next:

    Adrian raised a valid issue regarding making the thirdparty downloading the first target of the build.

    You cannot do that, unless there is mechanism to disable it (e.g. an unless="property").
    What happens if somebody is working offline?


    The way that I have set this up is that there is indeed an unless property. If the build-thirdparty.xml file is newer than the libraries.ent file then the downloads from the repository will take place. Otherwise the build will transpire as usual. If you do not have the thirdparty components on your machine and you do not have a net connection you will not be able to build.



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

    The libraries are only used by the main build when creating the dist. They have no purpose for building thirdparty or compiling the modules. Couldn't we simply break out the install target into a seperate build-dist.xml file that contains the install and related targets?

    Unless you do this, the initial build will be using the obsolete ../tools/buildmagic/etc/libraries.ent version and would fail anyway when the incorrect libraries were used.

    There should be a way to disable initiating the thirdparty build as suggested.

  • 20. Re: JBoss Third Party Build
    Ruel Loehr Novice

    As suggested, I was able to move the installation targets from the main build.xml file and into a build-distr.xml file (work done locally).

    At this point I am ready to commit and perform integration testing on the thirdparty build system. In order to not disturb development during this period we will create a branch to do this.

    Ruel Loehr
    JBoss QA

  • 21. Re: JBoss Third Party Build
    ryan.campbell Expert

    I have created Repo_Branch_4_0 for this.

  • 22. Re: JBoss Third Party Build
    Ruel Loehr Novice

    I have fully integrated all changes for the jboss thirdparty build on the branch Repo_Branch_4_0. The output directories match up and testsuite results are consistent with a regular 4.0 build both with 1.4 and 1.5 compilers.

    You can test this in the following fashion:

    mkdir test
    cd test
    cvs co -r Repo_Branch_4_0 jboss-4.0.x
    cd jboss-4.0
    cd build
    ./build.sh

    The first time build.sh is executed the dependencies will be downloaded from the repository. Later attempts at building will not download the thirdparty dependencies unless the build-thirdparty.xml file has been updated.

    In anticipation of migration to the thirdparty build I have set up a JBossBuild wiki page:
    http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild

    The final step for deployment will be to merge this branch into the Branch_4_0.

    What is the best process for doing this (e.g. notifying people, lead time, day to do it...)?

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

    I have gone through the build and it looks good so far. I'm still running the unit tests.

    The wiki page needs to be more strict about how the thirdparty contents are maintained. Generally, one should never update existing binaries. The only time this should be done is for snapshots on pre-release binaries.

    The respository is also independent of any existing build, so the discussion about looking to the build/build-thirdparty.xml for the correct version is off target. Someone has version x.y.z of a binary and they simply need to know how to add this to the repository.

    Its a independent choice to update the jboss-x.y/build/build-thirdparty.xml version to refer to the newer version. It may very well never happen, and there needs to be a jira issue that documents every change in thirdparty dependencies.

    As for merging this, announce it on the dev list and give it 24 hours to sink in. If I find a major problem in running the testsuite I'll followup to the dev list announcement.

  • 24. Re: JBoss Third Party Build
    Ruel Loehr Novice

    I have released the 4.0 thirdparty build.

    It can be checked out and build in the following fashion.


    cvs co -r Branch_4_0 jboss-4.0.x
    cd JBoss-4.0/build
    ./build.sh


    I have updated and will continue updating the wiki as quesitons arise. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild .

    The cruisecontrol scipt is also in the process of being update to reflect these changes.

  • 25. Re: JBoss Third Party Build
    Adrian Brock Master

    This doesn't work for me. It looks to be problem with the version of ant in tools
    since plain "ant" works but build.sh does not:

    adrian@adrian-srv01:~/jboss-4.0/workspace/build> ant -version
    Apache Ant version 1.6.5 compiled on June 2 2005
    adrian@adrian-srv01:~/jboss-4.0/workspace/build> ./build.sh -version
    Apache Ant version 1.6.2 compiled on July 16 2004

  • 26. Re: JBoss Third Party Build
    Adrian Brock Master

    Also, I thought we were keeping the thirdparty directory structure the same?

    I've now got to waste god knows how long revamping the eclipse build to have the
    new location of all the thirdparty jars.

    I went through a long argument before about why it was NOT a good idea
    including the version in the directory structure or the jar name that the local build sees.

    The version belongs in the manifest and the repository directory structure
    and it comes originally from the description in the build.xml or component-info.xml

  • 27. Re: JBoss Third Party Build
    Adrian Brock Master

    This is the error I see:

    adrian@adrian-srv01:~/jboss-4.0/workspace/build> ./build.sh -f build-thirdparty.xml
    Buildfile: build-thirdparty.xml
    
    synchronize.main:
     [exec] Unknown argument: -cp
     [exec] ant [options] [target [target2 [target3] ...]]
     [exec] Options:
     [exec] -help, -h print this message
     [exec] -projecthelp, -p print project help information
     [exec] -version print the version information and exit
     [exec] -diagnostics print information that might be helpful to
     [exec] diagnose or report problems.
    etc.
    


  • 28. Re: JBoss Third Party Build
    Ruel Loehr Novice

    Adrian,

    Please execute the below command and send me the results. It will create the errorlog.txt file in the build directory. This will eliminate the need for me to ask the standard what os are you using questions.

    ./build.sh -f build-thirdparty.xml -verbose -logfile errorlog.txt


    From your previous posts it looks like you are getting additional arguments added in when ant is launched for the synchronize.targets target.

    When I run in verbose mode my output is the following:

    synchronize.main:
     [exec] Current OS is Windows XP
     [exec] Executing 'cmd.exe' with arguments:
     [exec] '/c'
     [exec] 'ant'
     [exec] '-f'
     [exec] 'c:\projects\fresh40backup\jboss-4.0\build\build-thirdparty.xml'
     [exec] 'synchronize.components'
     [exec]
     [exec] The ' characters around the executable and arguments are
     [exec] not part of the command.


    I think we will see extra arguments in the above in your error log.

    The process is launched in this fashion (found in the tasks.xml file):



    Was this checked out to an empty directory? I would like to eliminate the possibility of the ${execant.args} being set in a property file.




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

    I thought we were going to generate the eclipse library classpath. The same issue applies to intellij projects though. These should be generated anyway as the transitive closure of dependencies is still a function of the version whether or not its included in the path.

    If the thirdparty version info is thrown away, isn't there an inconsistency in treatment of local vs remote repository in terms of identifying if a component is up to date? If I update the local thirdparty component to a newer version?