6 Replies Latest reply on Nov 14, 2006 12:22 PM by David Lloyd

    improving the build

    Tom Baeyens Master

      I'm going to make some slight improvements to the build:

      1) add build profiles
      2) improve versioned dependencies

      1) add build profiles
      I'm going to factor out all the library version properties to a separate properties file. Many of these files can go into the profile directory. E.g. for each version of jboss, we can create a set of properties that match these of jboss. Also jbpm internal dependencies will be included in the profile property files.

      2) improve versioned dependencies
      For each top level subproject, you'll be able to specify wether the sources are used (using version 'snapshot'). Or wether a specific version from the repository is being used.

      For each of the third party libs, you'll be able to specify the filename and version in the profile properties files.


      Any early feedback comments on this are appreciated. Let me know asap when i should happen to break your build.

        • 1. Re: improving the build
          David Lloyd Master

           

          "tom.baeyens@jboss.com" wrote:

          1) add build profiles
          I'm going to factor out all the library version properties to a separate properties file. Many of these files can go into the profile directory. E.g. for each version of jboss, we can create a set of properties that match these of jboss. Also jbpm internal dependencies will be included in the profile property files.


          Maybe it would be a good idea to have a "common" file, and then a specific file for each version that overrides anything that's different, to avoid lots of duplication?


          2) improve versioned dependencies
          For each top level subproject, you'll be able to specify wether the sources are used (using version 'snapshot'). Or wether a specific version from the repository is being used.


          Just an FYI, I'd like to not be using any snapshot versions by the time we do a final release. Apart from that, everything sounds good.


          • 2. Re: improving the build
            David Lloyd Master

             

            "david.lloyd@jboss.com" wrote:
            "tom.baeyens@jboss.com" wrote:

            2) improve versioned dependencies
            For each top level subproject, you'll be able to specify wether the sources are used (using version 'snapshot'). Or wether a specific version from the repository is being used.


            Just an FYI, I'd like to not be using any snapshot versions by the time we do a final release. Apart from that, everything sounds good.


            Also, every time I use a snapshot version, I put the corresponding future release version above it. That way I won't forget what release will include the changes that were not in the last stable release. And I only used snapshots when the fix is actually committed into that project.

            • 3. Re: improving the build
              Tom Baeyens Master

               

              "david.lloyd@jboss.com" wrote:

              Maybe it would be a good idea to have a "common" file, and then a specific file for each version that overrides anything that's different, to avoid lots of duplication?


              The profiles are just a set of versions of
              1) third party libs
              2) jbpm modules

              This can be used to be compatible with a specific JBoss version, but it could also be used to tweak things for other compatibility issues. E.g. another hibernate version, another JSF implementation, ...

              "david.lloyd@jboss.com" wrote:

              Just an FYI, I'd like to not be using any snapshot versions by the time we do a final release. Apart from that, everything sounds good.


              What is the motivation for this? I would guess that in such times you would want to check if everything works with the versions that will go into the release. no ?

              • 4. Re: improving the build
                David Lloyd Master

                I only say it because then we can be able to state dependencies on tested versions of software. It is always possible for us to miss something during testing; but if we use tested and "supported" releases of software, it decreases the likelihood that there's a problem that we missed. Also, if customers want to build on what we have, it makes their life a little easier if they know what versions of support libraries they're running.

                That said, it's more of a recommendation than a mandate. :-)

                • 5. Re: improving the build
                  Tom Baeyens Master

                   

                  "david.lloyd@jboss.com" wrote:
                  I only say it because then we can be able to state dependencies on tested versions of software. It is always possible for us to miss something during testing; but if we use tested and "supported" releases of software, it decreases the likelihood that there's a problem that we missed. Also, if customers want to build on what we have, it makes their life a little easier if they know what versions of support libraries they're running.

                  That said, it's more of a recommendation than a mandate. :-)


                  for third party libs this is automatically the case (except for the snapshot libs that should be avoided in final releases).

                  for internal jbpm dependencies this doesn't have to be the case cause the sources are tagged. so the complete build is reproducable. the suite bundle serves as the base line.

                  many of the jbpm sub projects are tied together and used together. (just like the jboss components are mostly used in the jboss overall distribution).

                  i don't want to get into a situation where we are forced to label and upload every single internal subproject just to do an overall build. tagging the overall sources should be enough. only if we want to use a specific version of a jbpm subproject, then it should be tagged separate and uploaded and referenced.

                  that was the overall idea. not sure yet if it covers all the needs.

                  • 6. Re: improving the build
                    David Lloyd Master

                     

                    "tom.baeyens@jboss.com" wrote:
                    for third party libs this is automatically the case (except for the snapshot libs that should be avoided in final releases).


                    That is exactly what I was referring to; I didn't mean the internal build dependencies. Looks like we are in full agreement.