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.
Ron
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]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
