Unfortunately, "easy" is relative. I appreciate the desire for a project to be more deterministic about what particular build of a dependency it is using at the moment. That is a good thing and very necessary in some cases. It's also something that should be used as a last resort, when there isn't a suitable release available and the latest "snapshot" release isn't working. One would definitely NOT want to release a project that depends on a timestamp dependency for the same reason one would not want to release a project that depends on a snapshot dependency: such a dependency is not reproducible (the timestamp can help find the source that built it, but only actual releases are reproducible). It might be better if the timestamp version of the dependency also contained the term "snapshot" so it is more obvious that it isn't a release version of the dependency. (Part of the process for releasing a project is to make sure all of its dependencies are using released versions. If all snapshot versions contain "snapshot", then a plugin can do this automatically.)
Getting back to my central repository, since other projects may be depending on any arbitrary timestamped release, I can't really clean up my central repository of timestamped releases any time I want because I could break other projects. I can't really clean them up once I release my project because I should give projects that depend on me some time to move to the newly released version. So I need to come up with some policy about when it's okay to clean up the repository. When it's time to clean up there will be several new timestamped versions deployed for the new version which should not be cleaned up, so it becomes a bit more complicated. Because of the continuous builds, there could easily be hundreds of timestamped releases to clean up. And there are very many such projects that need to be cleaned up (each with their own hundreds of timestamped versions). That's a lot of files, so I should try to clean up on a regular basis. I'd rather not do this cleaning up by hand because it will take a lot of my time, so it would be best to schedule some daemon to do the cleaning for me. Something that sounded so "easy" is not so much anymore. This is a lot of work to take care of files that I really didn't want in the first place. It's not that I think that the timestamped releases themselves are bad (if I thought that, then this really would be easy--I'd just delete them all as soon as the build completes), but producing one with each continuous build is bad. It would be much better to be able to control when such timestamped releases are made (either explicitly or on a scheduled basis). Then the number of these files in the repository is much more manageable. ..David.. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 7:19 PM To: Maven Users List Subject: Re: jar:install-snapshot - deprecated jar:snapshot Yes, but as they are timestamped they are really easy to clean up. It allows you to be more deterministic about what build you are actually getting, and is consistent with the way m2 was implemented. - Brett On 8/25/05, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Brett Porter wrote on Wednesday, August 24, 2005 4:57 PM: > > > As of the 1.5 release of the Maven Artifact plugin, anything with a > > SNAPSHOT name will automatically get timestamped. > > ... and with continuous integration builds we will have a new unique artifact > with every build automatically deployed? It's triggered with every commit. > > - Jörg > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
