Hi Andrew, I'm not sure how strict the rules are for determining what type of items go into the svn, but I agree that there must be a way to tag libraries by release. That way, we can download just a specific version of Muse. Otherwise, everyone is forced to only use the latest, and whoever upgrades won't be able to go back. If binaries aren't maintained by version, then the Muse downloads should be a full download. That is, when I download and install a specific version, I shouldn't need to run the update_install script because I should already have the latest files for that version.
The only reason I can see why update_install needs to be run is if the download has dependencies on other non-Muse libraries (i.e. Axis2) which Muse does not maintain. So if the download is not complete and libraries aren't tagged, there should be a README.txt that describes what those other libraries are and what versions, so that we can manually download them from the other sites as needed, and not have to run update_install. Your team is doing good work with Muse tough, just that the release process will now become a bit more complicated as various versions are being released:) -Vinh -----Original Message----- From: Andrew Eberbach [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 5:52 AM To: [email protected] Subject: Re: update_install script 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
