On 12/3/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > At 11:19 PM -0700 12/2/05, Wendy Smoak wrote: > >On 12/2/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > > >> In short, it builds a JAR with a timestamped version (like > >> struts-core-20051106.203359.jar) and then makes a copy of it with the > >> name struts-core-SNAPSHOT.jar So for my team, if we are depending on > >> a nightly build, we use the timestamped version, not the SNAPSHOT, so > >> that there is no inconsistency. > > > >(The artifact plugin was finally convinced to cooperate.) Before I > >deleted them, http://cvs.apache.org/repository/tiles/jars/ had: > > > >tiles-core-0.2-20051203.055551.jar 02-Dec-2005 21:56 82K > >tiles-core-0.2-20051203.060733.jar 02-Dec-2005 22:07 82K > >tiles-core-0.2-SNAPSHOT.jar 02-Dec-2005 22:07 82K > >tiles-core-SNAPSHOT.jar 30-Aug-2005 21:27 106K > >(plus all the signatures and metadata) > > > >A Joe explained, you can declare a dependency on a particular snapshot > >and not have to worry about Maven retrieving the latest version. > > do we want to remove tiles-core-SNAPSHOT.jar ? I'm afraid there > might be confusion; from the listing details, it's clearly not the > same as the other files (is that 24K the result of Greg's aggressive > pruning? Nice work! ;-) ) > > I think we should disclaim any responsibility for maintaining > specific JARs in the cvs.apache.org repository; if people are > depending on SNAPSHOTS, they should be prepared for things possibly > being removed. Is that fair?
That certainly makes some logical sense ... but it has a down side too. Another project's trunk cannot do any useful development against the trunk build of Standalone Tiles at all, because there's no guarantee that I can download the source of the dependent project, use Maven or Ant to pull down the dependencies, and know that I'm going to be able to retrieve it. The only option would be to package the binary jar that was used (say, with this particular daily build) and then have to corrupt the build scripts to use that instead of the usual dependency. Of course, the other approach to this problem is to do 0.1, 0.2 types of snapshot releases on the way towards a refactored 1.0. Then, at least, you can point at a dependency that is likely to be there for a while. (In case it's not obvious, the "dependent project" in this case is Shale :-). Joe Craig
