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:34:26 GMT
On 01/09/2011 9:42 AM, Matta, Sunil wrote:
> Ron, all: this is exactly what I have been going through over the last few weeks.
> Coming from a C++/makefile environment, this is my first foray into the maven world.
> We have 70+ projects as well, and the plan has been to only release that were modified,
followed by projects that depend on them, and so on.
> So, we have to modify each pom, go up the dependency tree and figure out the inverse
transitive dependencies.
We made our life a bit easier:
- we separated out the database access stuff into a set of modules
- we organized our utilities and common functions into modules with few 
dependencies on each other.

We also organized our release plan spreadsheet so that it had a build 
group sequence associated with each module so that you could build all 
of the "1"s before doing the "2"s and so on.
We only had to do the dependency analysis once and did a review of the 
sequence as part of the planning session for a new release.

As a very small team, we tended to work on a few modules at once so we 
did not need a massive rebuild script.
The developer just updated the pom and the code for  the module, tested 
it and deployed the SNAPSHOT and moved to the next one in the sequence 
which had been assigned to them.


> This release process takes forever when we have to do a FULL release. Even incremental
releases can be painful if one of the most dependent project have been updated/released.
> I too wanted to keep all versions of modules in the parent pom file. Much like a top
level make file. So, I am very curious in why this parent pom file approach didn't work ??
> Here is what I have done to help with the release process:
> I wrote a perl module to go through the full tree to figure out the projects that need
to be released, and modify the relevant pom files.
> However, the order of release is still a concern. I can use the output of the mvn command
to release, but this gives me the _name_ of the project, and not the artifactId. I could keep
a mapping but this is error prone and should not be necessary.
> To complete the process, I have a couple of questions though:
> 1) What prints the output of a simple "mvn clean" command ? Is it some plugin ? Reactor
? Or maven itself ??
> 2) Is there a configuration to get the artificatId instead of/in addition to the project
name from the mvn output ?
> tia,
> Sunil
> -----Original Message-----
> From: Ron Wheeler []
> Sent: 2011, September, 01 9:26 AM
> To:
> Subject: Re: resolution will not be reattempted until the update interval of nexus has
elapsed or updates are forced
> 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 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> ________________________________________
> This E-Mail (including any attachments) may contain privileged or confidential information.
 It is intended only for the addressee(s) indicated above.
> The sender does not waive any of its rights, privileges or other protections respecting
this information.
> Any distribution, copying or other use of this E-Mail or the information it contains,
by other than an intended recipient, is not sanctioned and is prohibited.
> If you received this E-Mail in error, please delete it and advise the sender (by return
E-Mail or otherwise) immediately.
> This E-Mail (including any attachments) has been scanned for viruses.
> It is believed to be free of any virus or other defect that might affect any computer
system into which it is received and opened.
> However, it is the responsibility of the recipient to ensure that it is virus free.
> The sender accepts no responsibility for any loss or damage arising in any way from its
> E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory
> Such communications are retained and may be produced to regulatory authorities or others
with legal rights to the information.
> ---------------------------------------------------------------------
> 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