maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
Date Thu, 01 Sep 2011 15:19:09 GMT
On 01/09/2011 10:45 AM, Eric Kolotyluk wrote:
> Interesting - thanks for sharing that.
> At the moment I do not really need to change versions, I was experimenting
> to see if I could understand the process. Do I have the following ideas
> right?
>     1. I changed my version from 0.0.1-SNAPSHOT to 0.0.2-SNAPSHOT as a test
>     to see what happens. Since I have not actually done a release, then
>     technically I really do not need to increment the version.
>     2. Would the normal practice be to:
>        - Perform a mvn release
>        - Create a new SCM branch from the current release on the main branch
>        - Increment the version(s) on the main branch
>     3. Or would it be better to:
>        - Create a new SCM branch from main
>        - Perform a mvn release from the new branch
>        - Increment the version(s) on the main branch
>     4. In my case I have less than a dozen modules and they are tightly
>     related, so I want all the versions to match the parent. It would be nice if
>     I could just change the version of the parent POM and have everything fall
>     out from there, but I seem to have to change it elsewhere too.
When preparing a new release, you will need to take 10 minutes to 
prepare a new set of poms that match up.
If you are not changing anything else in the configuration - same third 
party libraries - then you are  done.
In the parent, you change its version and in the children you change the 
version of the children and that of the parent. No big deal for 12 modules.
Rebuild to see that you did not forget a dot or a digit and you are 
ready to release the hounds.
It is not worth automating or worrying about.

Prior to that, in the SCM, we tag or branch the old release and work on 
the head if we are doing new development.
If we are bug-fixing an older release while development is progressing 
on a new release, we create a branch on the buggy release if it does not 
already exist and work on that branch.

Not worth automating if you have a decent IDE and SCM. 10-15 minutes 
tops for a junior programmer.


> Cheers, Eric
> On Thu, Sep 1, 2011 at 6:26 AM, Ron Wheeler
> <>wrote:
>> We started by changing the version of every module but eventually went to a
>> policy of only changing the versions of modules that changed.
>> The project was a portal with 70+ modules so it was a PITA to change all
>> the versions.
>> Not a big project overhead but we got tired of it and once we had moved
>> much of the architecture to SOA with Web Services, it became clear that in a
>> new release of the portal, most of the modules did not actually change.
>> We then just reversioned the changed modules, produced a new parent version
>> and a new version of the core modules that dealt with the persistence since
>> the database had changed.
>> We used a simple spreadsheet to document the versions of the modules that
>> were required to build the new version of the portal.
>> Made our lives a lot simpler and we started to think of our own code in the
>> same way that we viewed third party libraries - if we did not need to
>> upgrade to fix a bug or get new functionality then we left the old version
>> intact.
>> This obviously had a lot of benefits in testing and reduction of useless
>> builds.
>> We did not use the parent for managing the versions of dependencies in the
>> modules since we had a better scheme for managing that.
>> Ron
>> On 01/09/2011 3:59 AM, Guillaume Polet wrote:
>>> For me, there are two strategies there:
>>> 1) You use the parent pom as an aggregator (your parent pom reference its
>>> children through modules) of several projects that always work together and
>>> make a coherent package-->parent/children should keep the same version, it's
>>> just simpler to anyone's mind and simpler to maintain.
>>> 2) You use a parent pom to define well-defined practices, coherent set of
>>> dependencies, general properties used across all your projects, plugins and
>>> their configuration that you don't want to repeat in all your projects, but
>>> the parent does not know about its "children"-->Then children should
>>> necessarily follow your  parent version
>>> Cheers,
>>> Guillaume
>>> Le 1/09/2011 06:57, Eric Kolotyluk a écrit :
>>>> OK, seems the problem was some data inconsistency with some things
>>>> pointing to 0.0.2-SNAPSHOT and other things still pointing to 0.0.1-SNAPSHOT
>>>> What is the best practice for when you want to change the version of the
>>>> parent POM, and have all the children follow?
>>>> I'm trying to use managed dependencies as much as possible, but somehow
>>>> that is not enough.
>>>> Also, is there some simple way to remove all 0.0.1-SNAPSHOT artifacts
>>>> from Nexus?
>>>> Cheers, Eric
>>>> On 2011-08-31 8:54 PM, Eric Kolotyluk wrote:
>>>>> Is it just me, or does anyone else ever get tired of the message
>>>>> resolution will not be reattempted until the update interval of nexus
>>>>> has elapsed or updates are forced
>>>>> Everything was working fine yesterday. For some reason, that I cannot
>>>>> explain, now my builds keep failing with this symptom. I have not actually
>>>>> changed any pom files or really anything - other than to stop and restart
>>>>> Eclipse. The same problem happens whether I build from Eclipse or the
>>>>> command line. I cannot seem to find any combination of '-U' or 'clean'
>>>>> 'deploy' or anything to correct things. I feel like a chicken who pecks
>>>>> randomly at things until one of them is food.
>>>>> It is really unnerving that maven is so fragile and unpredictable, and
>>>>> things so randomly go from working to broken. While Maven is way better
>>>>> Ant in most respects, Ant is still head and shoulders above Maven in
>>>>> stability.
>>>>> [ERROR] Failed to execute goal on project intersystem-jni4net: Could
>>>>> resolve dependencies for project com.kodak.intersystem:**
>>>>> intersystem-jni4net:jar:0.0.2-**SNAPSHOT: The following artifacts could
>>>>> not be resolved: com.kodak.intersystem:**intersystem-common:jar:0.0.2-*
>>>>> *SNAPSHOT, com.kodak.intersystem:**intersystem-client:jar:0.0.2-**SNAPSHOT,
>>>>> com.kodak.intersystem:**intersystem-service:jar:0.0.2-**SNAPSHOT,
>>>>> com.kodak.intersystem:color-**repository:jar:0.0.2-SNAPSHOT: Failure
>>>>> find com.kodak.intersystem:**intersystem-common:jar:0.0.2-**SNAPSHOT
>>>>> http://nexus:8081/nexus/**content/groups/public<http://nexus:8081/nexus/content/groups/public>was
cached in the local repository, resolution will not be reattempted until
>>>>> the update interval of nexus has elapsed or updates are forced ->
 [Help 1]
>>>>> When I look in my local repository I can see
>>>>> intersystem-common-0.0.2-**SNAPSHOT.jar.lastUpdated
>>>>> intersystem-common-0.0.2-**SNAPSHOT.pom.lastUpdated
>>>>> but
>>>>> intersystem-common-0.0.2-**SNAPSHOT.jar
>>>>> intersystem-common-0.0.2-**SNAPSHOT.pom
>>>>> are missing. Why is that when the previous 'deploy' succeeded?
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**<>
>>>> For additional commands, e-mail:
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**<>
>>> For additional commands, e-mail:
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

View raw message