Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly
<stephen.alan.conno...@gmail.com>:
The real issue I see is people not defining their snapshot policy (and I
mean that in a wider sense)
Personally speaking I favour *never* deploying snapshots. Only using them
for local speed up where a large reactor required to wire everything up
using either the `package` or `verify` phase (with or without tests
skipped) would just take too long.
exactly my thoughts as well. I see a lot of users still doing 'install'
for the wrong reasons:
- coworkers said so / internet said so.
So for me, with my pattern of creating local aggregator projects and not
really installing let alone deploying snapshots, there is no problem...
When working on projects however that use a CI system to deploy snapshots
after every build... Well I tend to curse them (or turn off snapshot
update
checking)... Worse is where this was done because building a specific
artifact requires a toolchain I do not have access to on my machine...
So I
am forced to turn on snapshot checking for every build while working on
that module.
What you usually find is people have not realised the cause and effect.
I favour the CI server deploying snapshots with every build *but* into a
repo only for use by the CI server.
I favour never deploying smapshots to developer repositories... Any time
you think you need to... Well you probably just need to cut a release...
Can't cut a release because tests are failing? Wtf are you giving me that
broken shit for... Timestamped snapshots are just a crutch...
My €0.02
I like to improve the lifecycle even a bit. If you do a deploy, the
install should be skipped. This way all co-workers will pull the same
instance. If the deploy fails, your local repo is still clean.
My current thought is to introduce the ability to split the lifecycle.
:
:
verify
/ \
install deploy
This would improve the reliability of Maven, make it a bit faster and in
the end both 'mvn install' and 'mvn deploy' will keep the same behavior.
thanks,
Robert
On Sunday, 15 June 2014, Mark Derricutt <m...@talios.com> wrote:
Hey all,
A recent discussion on one of the github PR's led to a discussion on
SNAPSHOT resolution, which is a long standing issue in maven range
support
with several long standing open tickets lingering.
A thought I just had, which relates to some things I've been playing
with
in my C.I. builds, could quite simply resolve this. Maybe....
I know a few people who say "they just don't allow/use SNAPSHOTs" but
whenever you do an `mvm install` you end up with a -SNAPSHOT in your
~/.m2/repository - and that then affects resolution.
My thought was.... why is the local _repository_ treated differently to
normal repositories - in that it's as tho
`<snapshots><enabled>true</enabled></snapshots>`
is defined for them - and maybe it is? Why not simply.... _disable_
that.
But further than that, what if maven tracked TWO local repositories:
~/.m2/repository
~/.m2/snapshots
Much like `distributionManagement ` has two a `repository` and
`snapshotRepository` section, what if we have an
`installationManagement`
section ( probably limited only to `settings.xml` for install wide
settings? ) that did the same, but for the local repository? -SNAPSHOTs
installed via `mvn install` or downloaded via dependencies would go in
here.
This way - there's a clear separation of snapshots and releases, if you
don't want snapshot resolution - disable that local repository....
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
