maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matta, Sunil" <sunil.ma...@rbccm.com>
Subject RE: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
Date Thu, 01 Sep 2011 13:42:49 GMT
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.

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 [mailto:rwheeler@artifact-software.com] 
Sent: 2011, September, 01 9:26 AM
To: users@maven.apache.org
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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
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 use.

E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel.


Such communications are retained and may be produced to regulatory authorities or others with
legal rights to the information.

IRS CIRCULAR 230 NOTICE:  TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY
U.S. FEDERAL TAX ADVICE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED,
AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND
TO ANOTHER PARTY ANY TRANSACTION OR MATTER.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message