I would like to know if some of you can check her out and give it a whirl... especially someone on win32.
It works very similar to Greebo... well it was greebo until I got my hands on it. There is a task inside of the configure target which does all of the work. Note that there are some issues with it and the clean/clobber targets which I have fixed yet. Anyways, the task looks like:
<!-- Configure thirdparty libraries -->
<dependency-manager
cacheDir="${project.thirdparty.cache}"
metadataFile="${module.output}/dependencies.metadata"
dependencyFile="${module.root}/dependencies.xml"
offline="${dependency-manager.offline}"
pathID="library.classpath">
<repository url="http://jboss.sf.net/buildmagic/thirdparty"; type="jboss"/>
</dependency-manager>
By default project.thirdparty.cache is set to ${project.root}/thirdparty-cache. Some of the mods to Greebo include the ability to work offline, automatic generation of the classpath and some semi-intelligent attempts to speed up the process once files have already been downloaded.
I setup only the required libraries under http://jboss.sf.net/buildmagic/thirdparty. The structure of the files contained here are a mix of the thirdparty directory style from JBoss HEAD and Maven. The structure is identical in the cache directory. The major differences between JBoss HEAD and this is the addition of version information to the file names.
Anyways, the first time you run a build you will see something like this:
<snip>
...
[dependency-manager] Created dir: /Users/jason/ws/jboss/buildmagic-2.0/thirdparty-cache
[dependency-manager] Verifying 7 dependencies...
[dependency-manager] 1) Downloaded log4j-1.2.4.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 2) Downloaded webdavlib-1.0.16.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 3) Downloaded commons-httpclient-1.0.16.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 4) Downloaded junit-3.7.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 5) Downloaded regexp-1.0.8.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 6) Downloaded jmx-1.0ri.jar from: http://jboss.sf.net/buildmagic/thirdparty/
[dependency-manager] 7) Downloaded dom4j-1.3.jar from: http://jboss.sf.net/buildmagic/thirdparty/
...
</snip>
After the files have been downloaded you will either see:
<snip>
...
configure:
[dependency-manager] Verifying 7 dependencies...
[dependency-manager] 1) log4j-1.2.4.jar is up-to-date
[dependency-manager] 2) webdavlib-1.0.16.jar is up-to-date
[dependency-manager] 3) commons-httpclient-1.0.16.jar is up-to-date
[dependency-manager] 4) junit-3.7.jar is up-to-date
[dependency-manager] 5) regexp-1.0.8.jar is up-to-date
[dependency-manager] 6) jmx-1.0ri.jar is up-to-date
[dependency-manager] 7) dom4j-1.3.jar is up-to-date
[dependency-manager] Creating /Users/jason/ws/jboss/buildmagic-2.0/common/output/dependencies.metadata
...
</snip>
or:
<snip> ... [dependency-manager] Dependencies are up-to-date (metadata check). ... </snip>
The latter is some of the semi-intelligence I added to avoid hitting the repository webserver when we are fairly sure that we have the right files. This is done via an internal uptodate task which checks to see if the build or dependency files are newer than the metadata file (output/dependencies.metadata by default). If they are, then deps might have changed so we do a check. If they have not then we check to see if the files we depend on exist. If they don't we have to check. Else we just skip all of that. Note that this will cause problems when jars are updated on the remote server but the version number was not changed. To make it do a check, just nuke the metadata file.
As I mentioned before, this task will generate an Ant path with the id given by pathID. This makes it integrate very nicely into the current systems framework (or chaos depending on how you look at it).
Lastly I added a flag to allow the build system to function even if there is no network connection. This will only work if your thirdparty-cache directory contains the correct bits though... not much I can do about that. If you set -Ddependency-manager.offline=true, then when doing dependency verification, only files will be retrieved from local repositories (protocol is 'file'). If the protocol is anything else then only a simple check is done to see if the file exists in the cache. If it does then it warns you that it might be stale, but continues. If the files is gone, then the build will fail.
* * *
Give it a try:
cvs get -r buildmagic-2_0 buildmagic cd buildmagic ./build/build.sh
* * *
If this works out then we can remove much of the library and tool config complexity as well as tailor the download size of required dependencies.
--jason
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
