Is there a reason to always have common code in snapshot as a dependency? Could it not be set to the latest release and only updated when a change from the new one is needed?
- Brett On 03/11/2007, Nigel Magnay <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
