The problem is that the projects always end up changing quite often - perhaps the example of 'commoncode' is a bad one - in reality we have about 3 'shared' projects that both teams might commit changes to. It's desirable that they move to using a 'release' (and remove the project from their workspace & svn externals) - that's really the purpose of trying to keep them as separate projects with their own lifecycles, but in practice this only seems to happen for short periods of time before someone needs to commit a change, and so needs to flip back onto a snapshot again. Which is fine - but it's when the other project does a release (e.g at the end of their sprint) - they have to be very fastidious about telling everyone 'hey, HEAD of CommonCode is moving to 1.1-SNAPSHOT - update your poms now'. My experience has been that when this happens, there's much wailing and gnashing of teeth :-(
As an aside, what would also be cool would be the ability to know the 'latest' when doing a CI build. What I want to do (but haven't tried yet) is to have an additional build profile, which instead of using, say, the declared version of CommonCode, instead uses the LATEST - that way if that build is failing, you can know you've got trouble ahead if you want to migrate. Thinking about it, I guess POM "inclusion" wouldn't help any more than inheritance, as it'd also have to be versioned. I guess what I could do is have an externalised descriptor of what the versions on each projects /trunk are, and have a mojo that fails the build if the project says it's on a SNAPSHOT, but wants it to be the 'latest' SNAPSHOT and there's a mismatch. Ideally I could get it to modify the pom to be correct and have it automatically re-start the entire build - but I don't know how practical that would be to acheive. On 11/3/07, Brett Porter <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
