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