1 2 3 Previous Next 44 Replies Latest reply on Dec 31, 2005 11:06 PM by anil.saldhana Go to original post
      • 30. Re: JBoss Third Party Build

        The two issues raised, to reiterate some posts that didn't make it into the forum are:

        1) Eclipse classpath generation
        2) The download of dependencies to path structure with a version number

        Eclipse classpath generation is a difficult concept for this "hybrid" build. I use the word hybrid in terms that it is mostly buildmagic with a bit of jbossbuild. The jbossbuild is the portion which is responsible for downloading the dependencies.

        Keep in mind that the jbossbuild at this point essentially only has a list of dependencies which it knows about, however it does not have any concept of modules or which dependencies are required by each module. In order to properly generate an eclipse classpath file for each module we would need the information defined in the buildmagic system (e.g. which modules, which depedencies).

        I would guess its not a big deal to simply drop the local repository version info. The generated get ouput location and local path checks would simply drop the version portion. The libraries.ent generation would also need to be updated.


        Dropping the local version information shouldn't be tough. I will begin work on it today. If we are to drop the local version info from the paths, this will give us a very similiar thirdparty folder as to what was being checked out from cvs. In this case, even if no eclipse classpath is generated, aren't we basically at the same point we are with the standard buildmagic build as far as classpath information is concerned?

        • 31. Re: JBoss Third Party Build

           

          "rloehr@jboss.com" wrote:
          ...this will give us a very similiar thirdparty folder as to what was being checked out from cvs. In this case, even if no eclipse classpath is generated, aren't we basically at the same point we are with the standard buildmagic build as far as classpath information is concerned?


          Yes, except that now we have more control over the versions, (and we will get even
          more control as the new build move forwards), something that was
          a nightmare when it was in a non-versionable module definition in CVSROOT/modules.

          • 32. Re: JBoss Third Party Build
            starksm64

            We are never back to the current situation because:

            1. Its not an unversioned CVSROOT/modules admin file that defines the makeup of the thirdparty tree.
            2. The master build is defining the versions explicitly so this is what controls what goes into a release. This is a versioned file that can easily be monitored and manged for project specific changes.
            3. Developers are not updating thirdparty libraries with who knows what version, license, etc. and checking them in. This is done by populating the repository, and strict adherence to population of a valid component info will be required for any content checked in there.

            All Adrian is saying is that propagation of the version info to local workspace paths just makes life difficult. The local version info is superflous.

            • 33. Re: JBoss Third Party Build

              Now that the build for the 4.0 branch has been deployed I am looking at my roadmap. The next item in my queue is to port the thirdparty build to head. Is this in line with everyone's expectations?

              • 34. Re: JBoss Third Party Build
                starksm64

                Yes. Send out an email to the dev list so everyone is aware.

                • 35. Re: JBoss Third Party Build

                  Where would one get a current such set of ant tasks as would be found in the mentioned,

                  build-thirdparty.xml

                  more,
                  l8r,
                  v

                  • 36. Re: JBoss Third Party Build
                    anil.saldhana

                    Should we make a clean build of jboss clean up the thirdparty folder?

                    The reason is that I had a case where tomcat folder in thirdparty was holding onto a version that should have been replaced with a rolled back version.

                    Might be an arbitrary case.

                    • 37. Re: JBoss Third Party Build

                      Cruise control always does a clean checkout and build.

                      If you roll back a version there can be issues if the jars in your thirdparty directory are newer than the versions you have rolled back to. A jira issue has been opened for this.

                      You can delete your local thirdparty folder and let it be rebuilt.

                      • 38. Re: JBoss Third Party Build
                        anil.saldhana

                         

                        "rloehr@jboss.com" wrote:

                        You can delete your local thirdparty folder and let it be rebuilt.


                        If I was satisfied with manually cleaning up the thirdparty folder and rebuilding, I would not have raised a question. ;)

                        Maybe the ant built script should be smart enough to do the following:
                        If access to repository.jboss.com exists, then the clean build should clean up the thirdparty folder. If you are building offline, better not clean the thirdparty folder.


                        • 39. Re: JBoss Third Party Build
                          starksm64

                          A clean should not be required to detect a pickup a new version. the difference in the version should be detected and the thirdparty component replaced. The current get task used for this does not have enough capability last time I looked.

                          • 40. Re: JBoss Third Party Build
                            starksm64

                             

                            "oommoo" wrote:
                            Where would one get a current such set of ant tasks as would be found in the mentioned,

                            build-thirdparty.xml


                            See the tools/etc/jbossbuild/* content in the workspace.

                            • 41. Re: JBoss Third Party Build
                              anil.saldhana

                               

                              "scott.stark@jboss.org" wrote:
                              A clean should not be required to detect a pickup a new version. the difference in the version should be detected and the thirdparty component replaced. The current get task used for this does not have enough capability last time I looked.


                              Thats the right approach. In the interim, I do suggest a cleanup of the thirdparty folder on a clean build, until the get task is made smart.

                              • 42. Re: JBoss Third Party Build
                                anil.saldhana

                                 

                                 <componentref name="jboss/cache" version="1.2.4_sp1"/>
                                 <componentref name="jboss/remoting" version="snapshot"/>
                                 <componentref name="jboss/serialization" version="snapshot"/>
                                


                                Both the remoting and the serialization projects work off the snapshot concept. This is not friendly for developers when they want to check if something is failing because of a snapshot. There is no way we can rollback to an earlier version, without contacting Tom/Clebert.

                                Can we mandate all projects to have version numbers please?

                                http://jira.jboss.com/jira/browse/JBWS-547 has a comment from me at the end where I was unsure if the testcase was choking because of something I did to the security layer or the remoting snapshot update. I did not have to contact Telrod to roll back to see if there were issues. :)

                                User: telrod
                                 Date: 05/12/29 10:10:26
                                
                                 Modified: jboss/remoting/snapshot/lib jboss-remoting.jar
                                 Log:
                                 Rolling back to version 1.6 (last known version working).
                                
                                 Revision Changes Path
                                 1.12 +2062 -2182repository.jboss.com/jboss/remoting/snapshot/lib/jboss-remoting.jar
                                


                                • 43. Re: JBoss Third Party Build

                                  Yes, we should mandate version numbers.

                                  • 44. Re: JBoss Third Party Build
                                    anil.saldhana

                                    I take back what I said earlier (Adrain would have corrected me - he is on vacation though, plus at the beginning of this forum thread, he does mention about this).

                                    If a clean of JBoss build, cleans up the thirdparty folder, then eclipse freaks out unless the cleaning retains the eclipse metadata files for the project in the thirdparty folder. I would have to delete the thirdparty project in eclipse and recreate it AND it will do a time-consuming full build.

                                    So an interim solution I suggested (about cleaning up the thirdparty folder during jboss clean) is not perfect for eclipse users (incl. me).

                                    The only solution and the right solution is to enhance the gettask of jbossbuild to consider rolled back version of thirdparty libraries and bring them accordingly.

                                    Wonder if we have any volunteers to do this task?

                                    1 2 3 Previous Next