We get it right this time w.r.t. extensions so that we don't have to do this again! ;-)
2011/5/24 Arnaud Héritier <aherit...@gmail.com>: > ok, but we'll deploy a new pom with a different classifier for each new > version ? > Whe we'll have 3 possible versions, how will we do ? > If I 'm building a new project with a maven compatible with POM 4.2.0 can I > extend a pom 4.0.0 or 4.1.0 ? > Said differently imagine we have a really new cool feature in POM 4.2.0 and > we want to use it in Apache parent for all projects already using our new > Maven X.Y > What we'll we do for projects using POM 4.0.0 or POM 4.1.0 (knowing that > perhaps the project will be in 4.0.0 but the dev we'll have the latest Maven > version) > > > On Tue, May 24, 2011 at 5:30 PM, nicolas de loof > <nicolas.del...@gmail.com>wrote: > >> +1, simple and efficient >> >> 2011/5/24 Stephen Connolly <stephen.alan.conno...@gmail.com> >> >> > deploy new poms as poms with classifier >> > >> > new maven tries to download pom with classifier... fails and falls >> > back to pom without >> > >> > old maven only ever sees pom without classifier >> > >> > 2011/5/24 Arnaud Héritier <aherit...@gmail.com>: >> > > It doesn't seem so easy for me. >> > > If we deploy 4.0.0 only we'll never be able to reuse new POMs in the >> > build >> > > process by inheritance for example. >> > > Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility >> but >> > > won't allow us to evolve. >> > > The problem is how to depend and how to extend (without talking about a >> > > future : how to mix..) >> > > >> > > >> > > On Tue, May 24, 2011 at 4:09 PM, John Casey <jdca...@commonjava.org> >> > wrote: >> > > >> > >> >> > >> >> > >> On 5/24/11 8:25 AM, Brian Fox wrote: >> > >> >> > >>> 2011/5/24 Arnaud Héritier<aherit...@gmail.com>: >> > >>> >> > >>>> Before talking about a specific change in the model like the >> addition >> > of >> > >>>> mixins (which may be cool but not critical) did we : >> > >>>> - studied that we had everything necessary to manage new versions of >> > POMs >> > >>>> with something a little bit dynamic inside the core and all that is >> > >>>> necessary on repositories side ? >> > >>>> - studied if we couldn't start by really simple issues that may >> > already >> > >>>> do a >> > >>>> very useful 3.1 version like the addition of global exclusions ? >> > >>>> >> > >>>> >> > >>> I didn't read the proposal in detail yet, but my initial concern was >> > >>> on pom compat as well. >> > >>> >> > >> >> > >> I think doing some sort of on-the-fly translation into a 4.0.0 POM >> > purely >> > >> to be deployed for backwards compat would be enough here...though we >> may >> > >> want to explore how we could make Maven smart enough to say, "I can't >> > read >> > >> this POM, use a later version" or somesuch... >> > >> >> > >> >> > >> >> > >>> >> > >>> Arnaud >> > >>>> >> > >>>> On Tue, May 24, 2011 at 7:30 AM, Brett Porter<br...@apache.org> >> > wrote: >> > >>>> >> > >>>> Hi, >> > >>>>> >> > >>>>> I'm working with some projects at the moment that have a high >> amount >> > of >> > >>>>> repetition in the build section (and in some cases dependencies), >> but >> > no >> > >>>>> common parent due to different organisational hierarchies. >> Currently >> > >>>>> it's >> > >>>>> being solved by using archetypes to create projects consistently, >> but >> > it >> > >>>>> isn't very satisfying if someone wants to change the archetype >> later >> > on. >> > >>>>> I've minimised that by limiting what needs to change between >> projects >> > >>>>> based >> > >>>>> on the archetype, but it is exactly the situation that calls for >> > mixins. >> > >>>>> >> > >>>>> At the same time, this issue was filed today: >> > >>>>> http://jira.codehaus.org/browse/MNG-5102, and I was surprised not >> to >> > >>>>> find >> > >>>>> a dupe given how often it has come up here. >> > >>>>> >> > >>>>> Previous discussions I found: >> > >>>>> http://s.apache.org/maven-mixin-1 >> > >>>>> http://s.apache.org/maven-mixin-2 >> > >>>>> http://s.apache.org/maven-mixin-3 >> > >>>>> http://s.apache.org/maven-mixin-4 >> > >>>>> >> > >>>>> I don't see any concrete proposals, other than the notes from Jason >> > >>>>> Dillon. >> > >>>>> So, I thought I'd start collecting them here. >> > >>>>> >> > >>>>> I actually prefer the name "template", so I'll use that here, but >> > happy >> > >>>>> to >> > >>>>> take other's opinions on that. >> > >>>>> >> > >>>>> -- >> > >>>>> >> > >>>>> Pre-requisites: the ability to make modifications to the POM, >> > published >> > >>>>> to >> > >>>>> the repository, without impacting older clients. This needs an >> issue >> > of >> > >>>>> it's >> > >>>>> own, but I don't think it's challenging if we continue to spit out >> > >>>>> v4.0.0 to >> > >>>>> the repository. >> > >>>>> >> > >>>>> Some notes on how I think it should work: >> > >>>>> - templates should look like a normal POM (perhaps only differing >> in >> > >>>>> root >> > >>>>> element, and less strict validation requirements), so that normal >> > >>>>> validation >> > >>>>> can be applied >> > >>>>> - any POM element is valid, other >> > than<parent>,<groupId>,<artifactId>, >> > >>>>> <version>,<templates>,<modules> >> > >>>>> - templates need to be sourced from the repository using the normal >> > >>>>> mechanism (similarly to the parent POM) >> > >>>>> - templates should have an extension "xml" in the repository. It is >> > >>>>> attached to the corresponding POM project with packaging >> > "pom-template". >> > >>>>> Multiple templates can be attached using classifiers. The POM of >> the >> > >>>>> template must be separate to the template itself, as some elements >> > would >> > >>>>> otherwise overlap (e.g.<name> of the template vs the templated >> name, >> > or >> > >>>>> distributionManagement) >> > >>>>> - we rely on the later interpolation step to resolve variables - >> > there >> > >>>>> should be no filtering or macro capability on the template >> > >>>>> - there should be no additional merge semantics - I think they can >> be >> > >>>>> handled very similarly to external profiles in terms of building >> > >>>>> - there should be no conditionals within or around the template >> > (that's >> > >>>>> the >> > >>>>> purpose of profiles) >> > >>>>> >> > >>>>> I think that makes the sequence of project building: >> > >>>>> - parents& templates are resolved >> > >>>>> - templates are injected, sequentially as declared in the POM. Note >> > that >> > >>>>> this happens before inheritance, so templates in parents are >> already >> > >>>>> applied. >> > >>>>> - profiles are selected and injected >> > >>>>> - project inheritance is applied >> > >>>>> - interpolation is applied >> > >>>>> >> > >>>>> Templates would be referenced as follows: >> > >>>>> >> > >>>>> <project> >> > >>>>> <parent> >> > >>>>> ... >> > >>>>> </parent> >> > >>>>> <templates> >> > >>>>> <template> >> > >>>>> <groupId>org.apache.maven.templates</groupId> >> > >>>>> <artifactId>maven-release-profile-template</artifactId> >> > >>>>> <version>1.0</version> >> > >>>>> <classifier>sources-and-javadocs</classifier> (optional >> > element) >> > >>>>> </template> >> > >>>>> <template> >> > >>>>> <groupId>org.apache.maven.templates</groupId> >> > >>>>> <artifactId>maven-team-list</artifactId> >> > >>>>> <version>1.0</version> >> > >>>>> </template> >> > >>>>> </templates> >> > >>>>> ... >> > >>>>> </project> >> > >>>>> >> > >>>>> Some alternatives for discussion: >> > >>>>> - we could allow profiles to be externalised, and use that instead >> of >> > a >> > >>>>> new >> > >>>>> element. Simplifies building, but I think is less descriptive of >> > intent >> > >>>>> - template as a bare POM - instead of attached >> > artifacts,<templateSpecs> >> > >>>>> could be inlined in the POM, deployed as a single POM and then >> > imported >> > >>>>> into >> > >>>>> another project. This seems unnecessarily complicated, though. >> > >>>>> - there are other alternatives on how it is packaged in the >> > repository - >> > >>>>> e.g. a ".pomtmpl" extension or similar. If it is XML, I prefer that >> > >>>>> extension so it is more readily recognised, and I believe the >> > >>>>> group/artifact >> > >>>>> IDs will already describe their intent >> > >>>>> >> > >>>>> Any thoughts? >> > >>>>> >> > >>>>> Cheers, >> > >>>>> Brett >> > >>>>> >> > >>>>> -- >> > >>>>> Brett Porter >> > >>>>> br...@apache.org >> > >>>>> http://brettporter.wordpress.com/ >> > >>>>> http://au.linkedin.com/in/brettporter >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> --------------------------------------------------------------------- >> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>> >> > >>> --------------------------------------------------------------------- >> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >>> >> > >>> >> > >> -- >> > >> John Casey >> > >> Developer, PMC Member - Apache Maven (http://maven.apache.org) >> > >> Blog: http://www.johnofalltrades.name/ >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >> For additional commands, e-mail: dev-h...@maven.apache.org >> > >> >> > >> >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
