maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: getting LATEST version from the local repository
Date Fri, 04 Feb 2011 14:01:10 GMT
On 04/02/2011 6:35 AM, Mate Varga wrote:
> That's completely reasonable -- we don't have more than one version in
> production at a given time, however.
I would bet that frequently you have 1 in production, 1 in alpha or beta 
test and one in development.
Tagging is one of those things that you will find pretty handy when a 
bug arises that you must fix quickly in production and you need to find 
the code in a hurry.
Branching is a bit less critical but is a good way to manage experiments 
that you want to try but are not ready to put into the main line of 
development until you are sure.
Even with a 3 man team we find these useful.

> On Tue, Feb 1, 2011 at 9:29 PM, Ron Wheeler
> <>wrote:
>> On 01/02/2011 11:03 AM, Mate Varga wrote:
>>> Perforce, and we're strict about comments as well, but we don't really do
>>> branching and tagging (the dev team size is just too small).
>> We are very small as well but we really do need the branching and tagging
>> to enable us to support and fix bugs in multiple versions that are in
>> production plus test and development.
>> Ron
>>   It does not need to be very easy to tie source to snapshots.
>>> Besides that, is what I've written about snapshots correct?
>>> On Tue, Feb 1, 2011 at 3:52 PM, Ron Wheeler
>>> <>wrote:
>>>   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
>>>>> 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
>>>>> <>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
>>>>>> utilities and web services.
>>>>>> We do not use CI but dozens of regulars here do and can help make
>>>>>> work
>>>>>> correctly.
>>>>>> Can you give a short description of the issues that made you abandon
>>>>>> 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
>>>>>>> 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
>>>>>>> considered to be a new version. Obviously, successful CI builds
>>>>>>> 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,
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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<
>>>>>>>>     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,
>>>>>>>> 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"<>
>>>>>>>>   ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>>>   ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message