11 Replies Latest reply on Sep 10, 2007 12:53 PM by wolfc

    Getting the release process working with javaee

    starksm64

      So one thing we need to do is flesh out the release process for multi-project releases like the mc and javaee. Javaee is the simpler, and needs to have the canonical projects re-released as .Beta1s, so lets start with that.

      What we need working is:

      1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions?

      2. The eclipse project classpath settings need to be updated for the version updates as part of the release process.

      3. The contents uploaded to the legacy jboss repo are some aggregate view of the canonical projects. This generally is not the same as the aggregate contents one wants for a release upload to jboss.org. We need integration between the maven-jboss-deploy-plugin and an aggregrator description to define how to create the jbossrepor/{component-info.xml,resources,bin,lib} contents.

      4. We need a consistent set of steps one can follow in http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenReleaseProcess for any maven based project.

        • 1. Re: Getting the release process working with javaee
          pgier

          It looks like a couple of the dependencies in javaee are now out of sync. For example, jboss-ejb-api has a dependency on jboss-transaction-api 1.0.2-SNAPSHOT, which doesn't really exist. I think they were updated by the release plugin, and then didn't get switched back. I will fix these as I find them.

          • 2. Re: Getting the release process working with javaee
            pgier

             

            "scott.stark@jboss.org" wrote:

            1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions?

            We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one.

            "scott.stark@jboss.org" wrote:

            2. The eclipse project classpath settings need to be updated for the version updates as part of the release process.

            Would it be better to not have the .project and .classpath in subversion? I normally use the IDE plugin (http://m2eclipse.codehaus.org/) and it generates the classpath for me from the pom. It's not perfect, but it's gradually getting better.
            Also, don't some people use IDEA? The .project and .classpath are useless for them anyway.


            • 3. Re: Getting the release process working with javaee
              pgier

              For the release of javaee, should each of the sub-projects to use https://svn.jboss.org/repos/jbossas/projects/javaee/tags/
              as the base directory?

              So we end up with something like ?
              tags/jboss-javaee-5.0.0.Beta
              tags/jboss-servlet-api-2.5.Beta
              tags/jboss-ejb-api-3.0.0.Beta
              etc..

              Another question is do we need to release them all at once? Could we just release the modules as needed, and release the combined jar using previously released versions of the modules?

              • 4. Re: Getting the release process working with javaee
                starksm64

                 

                "pgier" wrote:
                For the release of javaee, should each of the sub-projects to use https://svn.jboss.org/repos/jbossas/projects/javaee/tags/
                as the base directory?

                So we end up with something like ?
                tags/jboss-javaee-5.0.0.Beta
                tags/jboss-servlet-api-2.5.Beta
                tags/jboss-ejb-api-3.0.0.Beta
                etc..

                I would just have the
                https://svn.jboss.org/repos/jbossas/projects/javaee/tags/5.0.0.Beta3/ tag contain the entire project structure that makes up the 5.0.0.Beta3 release, and this would include the various projects with their independent pom versions. It should just be a big bang release. It is likely that many subprojects are not going to change as we go from 5.0.0.Beta3 to 5.0.0.GA, but they should still be revd in terms of the qualifier as the aggregate release is revd. Maybe the aggregate qualifier (Beta3 in this case) should just be appended to all of the subprojects for simplicity.

                "pgier" wrote:

                Another question is do we need to release them all at once? Could we just release the modules as needed, and release the combined jar using previously released versions of the modules?

                This is mostly an issue of ease of release management vs tracking compatibility. If the projects only change their version when there is a code change, its code should still be under the https://svn.jboss.org/repos/jbossas/projects/javaee/tags/x.y.z for the aggregate release. Maven should simply not re-release the same code. If a project depends on another whose version has changed, its dependency/compatiblity range should be updated and re-released.


                • 5. Re: Getting the release process working with javaee
                  starksm64

                   

                  "pgier" wrote:

                  "scott.stark@jboss.org" wrote:

                  2. The eclipse project classpath settings need to be updated for the version updates as part of the release process.

                  Would it be better to not have the .project and .classpath in subversion? I normally use the IDE plugin (http://m2eclipse.codehaus.org/) and it generates the classpath for me from the pom. It's not perfect, but it's gradually getting better.
                  Also, don't some people use IDEA? The .project and .classpath are useless for them anyway.

                  The eclipse project files are already in subversion. I don't care about the IDEA users. Our tools platform is not based on it, so they have to fend for themselves.


                  • 6. Re: Getting the release process working with javaee
                    starksm64

                     

                    "pgier" wrote:
                    "scott.stark@jboss.org" wrote:

                    1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions?

                    We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one.

                    We need to start working towards such a feature request then. This is a simple plugin enhancement to obtain the next version, and the plugin can request what info it needs to determine if the release is moving from Beta1 to Beta2 vs Beta1 to CR1 or GA.



                    • 7. Re: Getting the release process working with javaee
                      pgier

                       

                      "scott.stark@jboss.org" wrote:
                      "pgier" wrote:
                      "scott.stark@jboss.org" wrote:

                      1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions?

                      We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one.

                      We need to start working towards such a feature request then. This is a simple plugin enhancement to obtain the next version, and the plugin can request what info it needs to determine if the release is moving from Beta1 to Beta2 vs Beta1 to CR1 or GA.

                      The release plugin already prompts you for the release version, tag, and next version. What is the enhancement that you are looking for?



                      • 8. Re: Getting the release process working with javaee
                        wolfc

                        I modeled the versions in the javaee subprojects to be the same as the spec version. So we should never bump these. Maybe we need a build number in there as well, like in RPMs (jboss-javaee-5.0-1)?

                        • 9. Re: Getting the release process working with javaee
                          starksm64

                           

                          "wolfc" wrote:
                          I modeled the versions in the javaee subprojects to be the same as the spec version. So we should never bump these. Maybe we need a build number in there as well, like in RPMs (jboss-javaee-5.0-1)?

                          Yes, that sounds like a good approach. So while the aggregate may be at Beta3, the subprojects are at the spec version with a build number qualifier. A version like 5.0-a does not match the osgi version conventions we outlined though. It would need to be something like 5.0.0.X-buildnumber as the qualifer portion is free-form and should not impact compatibility comparisons.


                          • 10. Re: Getting the release process working with javaee
                            pgier

                             

                            "scott.stark@jboss.org" wrote:
                            "wolfc" wrote:
                            I modeled the versions in the javaee subprojects to be the same as the spec version. So we should never bump these. Maybe we need a build number in there as well, like in RPMs (jboss-javaee-5.0-1)?

                            Yes, that sounds like a good approach. So while the aggregate may be at Beta3, the subprojects are at the spec version with a build number qualifier. A version like 5.0-a does not match the osgi version conventions we outlined though. It would need to be something like 5.0.0.X-buildnumber as the qualifer portion is free-form and should not impact compatibility comparisons.


                            Instead of a build number (1, 2, 3, etc..) would it make sense to just append the aggregate release number? So for example jboss-ejb-api 3.0.0.X-5.0.0.Beta3?
                            We should be able to do something like this in each of the modules.
                            <version>3.0.0.X-${project.parent.version}</version>
                            

                            This way we wouldn't have to worry about continually updating the build number.

                            Or we could just keep the build number as a property in the aggregate. So the modules would have:
                            <version>3.0.0.X-${buildNumber}</version>
                            

                            And ${buildNumber} would be a property set in the parent pom.

                            • 11. Re: Getting the release process working with javaee
                              wolfc

                              All the components in the javaee module don't have a direct relationship with AS 5.0.0.Beta3. We could (and probably will) have the same javaee artifacts in AS 5.1. So I wouldn't use 5.0.0.Beta3 as a build indicator. The main reason for the build number is when we misinterpreted spec or just made a bogus of the build itself.