What version control system are you using?
We are using Subversion and are pretty strict about:
a) Branching and tagging
b) Comments.
The fundamental question is "How easy does it have to be to tie a source
version to a snapshot?"
We very seldom need to go back and do a forensic reconstruction of the
crime.
When we do, we have comments and commit dates in the SCM that can be
matched against other evidence (paper notes, Snapshot dates, e-mails,
etc.) to determine where the source and the other event (test,
presentation, e-mail, bug report) coincide in time.
SNAPSHOTS and Subversion commits are both dated so it is always possible
to match them.
It has been required less than 3 times in the past 4 years that we have
been developing with Subversion and Maven, so the extra time to read a
history or go through a set of Maven Artifacts (we have Nexus) is not
really a determining factor in our selection of a methodology and
development protocol.
Ron
On 01/02/2011 10:14 AM, Mate Varga wrote:
That sounds right.
As far as I know, Maven assumes that releases are immutable, but snapshots
are not. So I could just use {some version number}-SNAPSHOT for all of our
projects and they would depend on each others' snapshot versions.
As far as I remember, the reason why I've chosen version numbers instead of
SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a project
and it's runtime dependencies, it is possible to go and find the sources he
artifacts were built from.
So in our current setup, a self-containing 'release' of project a contains
A-12.jar
B-19.jar
C-123.jar
D-111.jar
The version numbers are CI build numbers. Using snapshots (and without
manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT, etc.
However, this should not be a problem as there are hundred other ways of
tying an artifact to a build / source revision...
So you recommend just using a fixed version and SNAPSHOTs instead of
'RELEASE's?
Sorry for being confusing, this is my first encounter with Maven (and even
with these hacks it's much more convenient than Ant, at least for our
purposes).
Thanks,
Mate
On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler
<rwhee...@artifact-software.com>wrote:
It does seem that you are describing the way SNAPSHOTS work.
Can you identify any particular problem in your environment that prevents
you from working according to the Best Practices that thousands of
organizations are following?
I can not see from anything that you have described so far that is
abnormal.
We have 70 projects that make up a large LMS and it depends on 60+ third
party libraries and most of the war files include dependencies on our
utilities and web services.
We do not use CI but dozens of regulars here do and can help make that work
correctly.
Can you give a short description of the issues that made you abandon
SNAPSHOTS?
Ron
On 01/02/2011 9:22 AM, Mate Varga wrote:
What assumptions do I break except the immutability of an artifact with a
specific version? (Which is only broken locally, and mvn should not really
know about it, and it should not affect anything as mvn does not copy
local
artifacts anywhere.)
Well, then the easiest thing is to explain what I'd like to do -- and
maybe
there's some other way to achieve it.
(let's assume we have 3 projects, A, B, C,D; A depends on B, B depends on
C
and A depends on D
- we don't have major / minor versions at all -- we do not want and we do
not need a separate release procedure. Every successful CI build is
considered to be a new version. Obviously, successful CI builds should be
handled as snapshots, but if project B has been successfully built in the
CI, then each following build of A should be using that version. Therefore
the version numbers should be incremented automatically (CI build number
could be used for that)
- developers should be able to modify and build project B locally, and
then
modify and build A (and A should use B which was built locally)
Currently, what I do is
- have two profiles, a 'local' and a 'CI', which are activated
automatically
depending on the environment
- after successful CI builds, artifacts are deployed to the repo manager
(this works perfectly)
- locally built artifacts have version no. 99999999
- if an internal project references another internal project, then it
refers
to its 'LATEST' version
Are there other ways to achieve similar results? Please do not criticize
the
way we do releases, as this is 'given', and it's the result of the
environment we work in. We cannot have major/minor releases, nor can we
manually version each release. I'd be very happy if there were a proper
way
to do what we're doing in a bit hacky way now.
Thanks,
Mate
On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly<
stephen.alan.conno...@gmail.com> wrote:
ugh this is just so wrong I don't know where to start.
please consider using SNAPSHOTS as they are the correct way
LATEST and RELEASE do not mean what you think they mean, and they have
been
deprecated. their use is no longer supported.
maven makes assumptions about non-SNAPSHOT versions which you are
breaking
behind its back.
there be dragons here
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on
the
screen
On 1 Feb 2011 11:13, "Mate Varga"<mate.va...@gmail.com> wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
