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?
...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.
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.
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.
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.
<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
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?