+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 > >
