This is an interesting discussion as well as a very relevant direction of thoughts. I feel that the maven distribution strategies (mainly within site/release plugins) are full of [fairly undocumented] assumptions - the net result of which is a confusing experience for the users.
It would seem that the most important task is to devise and describe a simple and consistent model for 1. How to derive values for relativization [of URLs or values]. This is relevant for (at least) release and site plugins, but should be exposed from a common component to enable simple integration for any plugin requiring it. 2. How to compose effective values using in multi-project reactors. This is relevant for releases, such as when combining values from settings.xml and settings-security.xml are joined with extrapolated values from poms. *Exactly* what parts go in which files to achieve a properly working reactor? 3. [A best practise for] how to manage big multi-project reactors in a maintainable way - without either answering 250 versioning questions from the release plugin or resorting to a common version for all projects in the reactor (changed or not). IMHO these requirements indicate current-state itches which we need to scratch. Hopefully with a common component, to minimize deviation in plugin behaviour. 2013/3/14 Robert Scholte <[email protected]> > At least the maven-help-plugin and probably the maven-site-plugin too. > There's a small difference between the resolved pom for Maven(core) and > the way paths are transformed for the maven-release-plugin and > maven-site-plugin. > > here are some examples: > https://jira.codehaus.org/**browse/MSITE-669<https://jira.codehaus.org/browse/MSITE-669> > https://jira.codehaus.org/**browse/MSITE-672<https://jira.codehaus.org/browse/MSITE-672> > https://jira.codehaus.org/**browse/MSITE-657<https://jira.codehaus.org/browse/MSITE-657> > > Probably all URLs of distributionManagement are transformed for children, > but that's not exposed with the help:effective-pom. > > Robert > > Op Thu, 14 Mar 2013 21:35:15 +0100 schreef Stephen Connolly < > stephen.alan.connolly@gmail.**com <[email protected]>>: > > > On Thursday, 14 March 2013, Robert Scholte wrote: >> >> Let's create a new shared component[1] for it: there are more plugins >>> depending on this intelligence. >>> >> >> >> What other plugins could be concerned with knowing which projects are >> roots >> for the release plugin? >> >> Or maybe you gave something else in mind? >> >> >> Looks to me there's no component for this kind of stuff yet. >>> >>> Robert >>> >>> [1] >>> http://maven.apache.org/****shared/index.html<http://maven.apache.org/**shared/index.html> >>> <http://**maven.apache.org/shared/index.**html<http://maven.apache.org/shared/index.html> >>> > >>> >>> >>> Op Thu, 14 Mar 2013 10:32:26 +0100 schreef Stephen Connolly < >>> stephen.alan.connolly@gmail.**com <[email protected]>>: >>> >>> No it makes more sense in the release plugin >>> >>>> >>>> >>>> On 14 March 2013 09:16, Rahul Thakur <[email protected]> >>>> wrote: >>>> >>>> >>>> And perhaps this capability can reside in Maven core? Just a >>>>> thought.... >>>>> >>>>> >>>>> >>>>> >>>>> On 3/12/2013 2:56 AM, Robert Scholte wrote: >>>>> >>>>> Hi, >>>>> >>>>>> >>>>>> There are several MSITE/DOXIA and MRELEASE issues related to this >>>>>> subject. >>>>>> >>>>>> For the SCM-section and the site-section of the distributionManagement >>>>>> we >>>>>> need a more intelligent way to resolve this. >>>>>> Right now this logic is hidden inside the maven-release-plugin and >>>>>> maven-site-plugin, causing a different result when resolved as >>>>>> effective-pom, so IMO it is resolved at the wrong place. >>>>>> They way it should be resolved depends on the type of MavenProject: >>>>>> >>>>>> - aggregator (I'm not the parent of my modules) >>>>>> - multimodule-root (I'm the parent of modules) >>>>>> - module (I'm a module of my parent) >>>>>> - standalone (I'm not a module of my parent/I don't have a parent or >>>>>> modules) >>>>>> >>>>>> IMO modules should by default expand their parents path. >>>>>> >>>>>> Robert >>>>>> >>>>>> >>>>>> Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly < >>>>>> stephen.alan.connolly@gmail.******com <stephen.alan.connolly@gmail.** >>>>>> com <[email protected]>>>: >>>>>> >>>>>> Hey one and all, >>>>>> >>>>>> >>>>>>> So we all know how multiple projects with multiple release roots are >>>>>>> a >>>>>>> pain... >>>>>>> >>>>>>> Here's some experiments I've been playing with... >>>>>>> >>>>>>> Not yet brave enough to have it fire up release:prepare >>>>>>> release:perform >>>>>>> on >>>>>>> each release root, nor fire up versions:set on the downstream >>>>>>> projects >>>>>>> with >>>>>>> explicit dependencies, nor lather rinse repeat until there is nothing >>>>>>> needing a release... >>>>>>> >>>>>>> But even the simple report should be useful, and if anyone has >>>>>>> suggestions >>>>>>> to help improve its recommendations towards getting confidence that >>>>>>> the >>>>>>> automated stuff could work... please give me pull requests. >>>>>>> >>>>>>> If this proves useful, I will probably roll it into the release >>>>>>> plugin... >>>>>>> but for now I'll keep it in a holding pattern on github (where it is >>>>>>> not >>>>>>> in >>>>>>> a default plugin groupId and hence relocation is less of an issue if >>>>>>> I >>>>>>> do >>>>>>> happen to make any releases into central) >>>>>>> >>>>>>> $ mvn com.github.stephenc.maven:mpr-******maven-plugin:list-roots >>>>>>> >>>>>>> from an aggregator pom should identify all the release roots and >>>>>>> whether >>>>>>> they might need a release >>>>>>> >>>>>>> -Stephen >>>>>>> >>>>>>> >>>>>>> ------------------------------******--------------------------** >>>>>> --** >>>>>> --**--------- >>>>>> To unsubscribe, e-mail: [email protected].******org< >>>>>> [email protected].**org <[email protected]> >>>>>> > >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------******--------------------------**--** >>>>> --**--------- >>>>> To unsubscribe, e-mail: [email protected].******org< >>>>> [email protected].**org <[email protected]>> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> [email protected].**org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >>> > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: [email protected] | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
