On 24 May 2011 16:30, nicolas de loof <nicolas.del...@gmail.com> wrote: > +1, simple and efficient
Well we still have to cache the fact that there is no pom with classifier for any of the "old" artifacts... But at MRM should be able to handle that / generate a map from the "old" to the 5.0.0 model > > 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
