2009/10/25 Stephen Connolly <[email protected]>: > > > Sent from my [rhymes with tryPod] ;-) > > On 25 Oct 2009, at 01:36, David Weintraub <[email protected]> wrote: > >> No one has answered the basic question: Why two repositories? >> >> I know the differences between a release and snapshot. but that doesn't >> explain why the releases and snapshots are in two separate repositories. >> Why >> not keep both snapshots and releases in the same repository. We know >> something is a snapshot simply because it has the word "SNAPSHOT" appended >> to it. >> > > well actually, that only applies if you turn off timestamped snapshots, and > timestamped snapshots are the only kind allowed for 3.x > >> Because of the dual repository structure, I have to configure everything >> with two separate repository names, two separate repository URLs, and two >> sets of accounts and passwords. So, why not simply have a single >> repository >> which can store both snapshots and releases? > > if you use a repository manager, you can group the snapshots and releases so > that the storage is separate but you access the one repository > >> >> These are the only reasons I can think of: >> >> * Administration: Backing up a release repository is extremely important. >> Backing up snapshots -- not so much. But, is this actually true? >> >> * Who can see what. I might want my snapshot repository available to my >> developers, but not to the world. However, this would be more of something >> my repository management software should be able to do. >> >> * Releases should only be added to the release repository by a release >> manager, and not by any developer. However, snapshots would be added by >> developers. Again, this seems better handled via my repository management >> software. >> >> So, what is the reason to have two separate and distinct repositories for >> snapshots and for releases? > > update frequency, you may want to check snapshots with a greater or lesser > frequency than releases > > resolving ranges, ranges are only resolved from release repositories (this > is either a bug or deliberate) so if you have a repository enabled for both > releases and snapshots then any ranges for artifacts from such a repository > will resolve snapshots within the range
not that this is different from a snapshot in your local repository being resolved in a range if I build foo locally and it has a dependency on bar [1,) then I expect to get the latest release of bar eg 1.3 if I then locally build and mvn install bar eg 1.4-SNAPSHOT then rebuilding foo I would expect my local bar version to win in the range which it will because it is in my local metadata I think that some aspects of how this works currently leave a lot to be desired, but for now, if you use ranges, you *must* keep the repos separate > >> >> On Thu, Oct 22, 2009 at 4:43 AM, Costin Caraivan >> <[email protected]>wrote: >> >>> >>> Hello, >>> >>> I saw that most repositories are separated into releases and snapshots. >>> And >>> that most repository managers recommend using releases and snapshots. >>> >>> Now, I know what each of them is: >>> 1. release -> stable version, will be uploaded only once, when you want >>> to >>> change something you make a new release. >>> 2. snapshots -> development version, usually overwritten (you can keep >>> multiple snapshots, but it's not usually done) >>> >>> What are the benefits of having 2 separate repos? Cons & pros. Pros & >>> cons >>> :) >>> -- >>> View this message in context: >>> >>> http://www.nabble.com/Why-are-repositories-usually-separated-into-releases-and-snapshots--tp26006147p26006147.html >>> Sent from the Maven - Users mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> David Weintraub >> [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
