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