On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies <bimargul...@gmail.com>wrote:
> On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick <jesse.gl...@oracle.com> > wrote: > > On 08/25/2011 07:34 AM, Benson Margulies wrote: > >> > >> I discovered yesterday that one team had taken this idea to its local > >> extreme, and were just using release versions, no -SNAPSHOTS at all. > > > I can confirm this: we are using snapshot version (but i could also say "no snapshot at all") during development; while publishing only non-snapshots. In fact, I spent 6 months training up collegues on maven's way of development.. and the only thing they couldn't really digest was publishing/downloading SNAPSHOT version to share things (and waiting for maven to check for the latest SNAPSHOT on the company's repo): they went simply SCM-updating and rebuilding (once) all those 5/10/15 upstream modules when they needed to be working on the very latest. To a certain extent, this could be a good simplification: when using SNAPSHOTS from a mainstream project, some degree of synchronization emerges between different teams to choose between using the last stable, the last snapshot or even a few-days-old version; whilst publishing SNAPs only allow to share the very-last. Using the company repo to share snapshots costs (pom configuration, ci, update checks during builds, disk space, etc.), and could be not always necessary or justified with respect to a rough/simplier "build unstables, download stables" approach. > > > > > By the way it would seem safer if Maven refused to overwrite an artifact > in > > the local repository that had been retrieved from a remote repository (as > > recorded by _maven.repositories), or conversely to download even an > > apparently newer remote update when there was already a locally built > > artifact. However this would prevent you from running e.g. 'svn co > > http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.0.3 . && mvn > > install' if you already happened to have > > > ~/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar > > for unrelated reasons. Perhaps a nonfatal warning could be issued when it > > looks like locally built and remotely downloaded artifacts might be > > colliding. > +1 for the warning it'd help discover locally forgotten "overwrites" > > A published "best practices" document on this topic would be very much > appreciated, > The conversation is already a bit aged - has anything been created since then? Is any help needed? A small real example or even notes in the main documentation could be not so hard to write, based on current experiences. > > since the existing references leave this to your imagination. > Can you point to the exact page(s) in maven doc? PC
