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:[email protected]] Sent: 2011, September, 01 9:26 AM To: [email protected] 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Ron Wheeler President Artifact Software Inc email: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
