Let's make this an agenda item for this week's call. Vinh, please attend if you'd like to help craft the solution we use in the 2.2 dev cycle. Call details are on the web site under "Contact Info".
Dan Andrew Eberbach/Durham/[EMAIL PROTECTED] wrote on 12/21/2006 02:01:26 PM: > Hi Vinh, > > Yeah the whole update script is a stop-gap because of the legalities > involved in packaging other people's code. Also there's the fun of keeping > links to the specific version of specific libraries before the maintainer > takes them down because they're "obsolete." Ideally we could just bundle > everything together in one big muse-bin-VERSION.zip which would really > avoid this entire mess, but we can't due to Legal Reasons. You're right, > it's going to get hairy with new releases and nightly builds. But I think > supporting nightly builds is also going to be addressed through that id > issue I mentioned so that we can debug based on the code at that specific > time and not have to keep all of the nightly builds around forever because > the apache web master will be none too pleased about the space usage. > > Thanks, > Andrew > > Andrew Eberbach > Autonomic Computing > (919) 254-2645 > T/L: 444-2645 > [EMAIL PROTECTED] > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> > 12/21/2006 01:35 PM > Please respond to > muse-user@ws.apache.org > > > To > <muse-user@ws.apache.org> > cc > > Subject > RE: update_install script > > > > > > > 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: muse-user@ws.apache.org > 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 > muse-user@ws.apache.org > > > To > <muse-user@ws.apache.org> > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
