Re: Thought: write some doc about how not to use snapshots?

[Paolo Compieta <pa...@gmail.com>]

On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies <bi...@gmail.com>wrote:

> On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick <je...@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

Re: Thought: write some doc about how not to use snapshots?

[Stephen Connolly <st...@gmail.com>]

On 15 March 2012 00:55, Paolo Compieta <pa...@gmail.com> wrote:
> On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick <je...@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.

What I tend to favour is never publishing -SNAPSHOTs to remote
repositories... on the basis that if it is good enough to be pushed to
a remote repo, it is good enough to release ;-)

I normally check out all the projects I am working on, create a local
"aggregator" pom that just pulls all the different projects into one
build. I then use a prototype extension I have for the versions maven
plugin (*not released yet* as you really need to know its limits) mvn
versions:link-from-reactor from that aggregator pom and that
associates all the dependencies to the version in the reactor. Then
"mvn clean install" and I am good to go with everything using the code
I checked out.

One of these days I will iron out the bugs in
versions:link-from-reactor and release the code for it... but until
then you will just have to dream! ;-)

-Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org