maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Kolotyluk <>
Subject Re: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
Date Thu, 01 Sep 2011 14:45:27 GMT
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

   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.

Cheers, Eric

On Thu, Sep 1, 2011 at 6:26 AM, Ron Wheeler

> 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' or
>>>> '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 than
>>>> Ant in most respects, Ant is still head and shoulders above Maven in
>>>> stability.
>>>> [ERROR] Failed to execute goal on project intersystem-jni4net: Could not
>>>> 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 to
>>>> find com.kodak.intersystem:**intersystem-common:jar:0.0.2-**SNAPSHOT in
>>>> 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
>>>> 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message