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 [email protected] http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
