maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nigel Magnay" <nigel.mag...@gmail.com>
Subject POM 'inclusion'? A tricky problem..
Date Sat, 03 Nov 2007 10:56:06 GMT
Hi maveneers. I have an interesting problem which I'm not sure how to
solve, and I wonder if anyone else has met this before or has some
good ideas..

We have 2 products; "Alpha" and "Beta", a "CommonCode" project, and a
"SuperPom" project (it's actually more complex than that, but this is
just to simplify). Each of these has a separate repository (trunk) in
SVN and can be released separately. All projects inherit through
"SuperPom" for company-wide settings.

In addition we have 2 'workspace' projects "AlphaWorkspace" and
"BetaWorkspace", which use aggregation and svn:externals to bring in
their projects into a common build. The projects also use properties
to define the versions of their dependencies - i.e - Alpha's POM has a
property of <commoncode.version>1.0-SNAPSHOT</commoncode.version>.

So - we have something like
AlphaWorkspace
+---SuperPom (5.0)
+---CommonCode (1.0-SNAPSHOT)
+---Alpha (2.1-SNAPSHOT)

and

BetaWorkspace
+---SuperPom (5.0)
+---CommonCode (1.0-SNAPSHOT)
+---Beta (3.3-SNAPSHOT)

So far so good. Developers like this because they can do
'eclipse:eclipse' at the top level, and the dependencies get worked
out correctly, they can patch things in commoncode and not have to
worry too much about which project they're modifying.

At some point, Alpha needs to release. So, it must release all
dependent snapshots as well, meaning CommonCode. So AlphaWorkspace is
released, and then moves to
AlphaWorkspace
+---SuperPom (5.0)
+---CommonCode (1.1-SNAPSHOT)
+---Alpha (2.2-SNAPSHOT)

However. Because CommonCode has changed, BetaWorkspace has now become
BetaWorkspace
+---SuperPom (5.0)
+---CommonCode (1.1-SNAPSHOT)
+---Beta (3.3-SNAPSHOT)

Because Beta uses CommonCode:1.0-SNAPSHOT, not the 1.1-SNAPSHOT that
is now HEAD in CommonCode, fresh 'clean' builds will fail, and
existing developers suddenly find their code builds in an odd order,
and changes they made in commoncode don't seem to be appearing in the
output until.. aha! someone's released CommonCode, we have to change
our property as well.

In effect, Beta just wants the 'LATEST' version of CommonCode,
whatever that happens to be in the repository.

So far, I've thought of
Set the version to 'LATEST' - no: only works for plugins
Have a property in SuperPom for each project <commoncode.latest> - no:
just pushes the problem one project back - still have to change that
version
Have the versions set in some kind of buildscript before calling mvn :
possible, but yuck
Have some mojo contribute the properties : not sure if this would work
- reactor build order is calculated before the plugin runs?
Have some manual step / mojo to update the property commons.latest -
hmm, another step for developers to forget..
Some kind of POM 'import' function? Can't do yet.

Does anyone have any clever ideas or solved this one themselves?

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


Mime
View raw message