Hi, It downloads them to the bin directory in muse and then deletes that directory. Unfortunately we don't keep the old libraries around to download, that's probably a good idea. I want to figure out which version of muse it is based on the pom metadata in, say, muse-core.jar. This goes back to MUSE-126 because between releases I'm sure there'll be nightly versions of the jars. I think a better option might be versioning the zip files and puttying symbolic tags on the repository which would be the name of the build. So nightly builds would all be called NIGHTLY_YYYYMMDD, releases would be RELEASE_X.X.X. So the repository would be tagged every night and this build id would be put into the base distribution so that when we diverge on versions (as we are doing now where some people are going to 2.0.0) and when the nightly builds are up (Christmas present?) then we'll be able to tell who's on what version and be able to check out the repository exactly at that state. And since the lib zip files would also be tagged like this the build script would pick up the right libs.
What do you think? I am missing something? The onlynegative I see is that we're checking in binaries into svn which isn't The Best thing to do. But since we have the workspaces (which should also go into version control) life should be good. Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> 12/21/2006 05:00 AM Please respond to [email protected] To <[email protected]> cc Subject update_install script I downloaded Muse 2.1.0 to do some testing. Now, I want to revert back to the old 2.0.0. But when I run the update_install script, it downloads the latest 2.1.0 libraries. Is there way to run the 2.0.0 script and only retrieve 2.0.0's latest libraries? This way, I can test between the two versions on the same machine. Also, on a Windows machine, where exactly does it download the libraries to?
