Brett / Mark,
This all sounds great! I'm already dreaming of ways I could use this
functionality right now in my own builds...
Personally, I'm much more in favor of having separate template files in
the repository, since it helps keep the POMs associated with them lean,
and since it'll make the job of using these templates from other tooling
simpler.
Brett, I'm really starting to get interested in this post-4.0.0
formatting. I'm starting to remember a conversation I had last year this
time, about creating a new slave-pom specification for child modules
that will never be built outside the presence of the parent (where the
relativePath would always be valid, in 4.0.0 terms). That's getting a
little farther afield from the current conversation, but I wanted to
plant the seed... :-)
On 5/24/11 7:48 AM, Brett Porter wrote:
On 24/05/2011, at 7:09 PM, Mark Derricutt wrote:
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
Cool!
You mentioned the possibility of having the templates inline, rather than
<templateSpecs> I was wondering if using<templateManagement> to be
consistent with<dependencyManagement> and<pluginManagement>. If you have
multiple inline templates, how would you identify them?<id>'s like
plugins?
<templateManagement>
<template>
<id>web</id>
<build>
<plugins>
...
</plugins>
</build>
</template>
</templateManagement>
Feels really ik and complicated as you say.
Yep :) I don't see any hassle in pulling these files from the repository - the
only inline usecase is actually to do something once and use it several times
in a POM, but ruling out parameterisation doesn't make that useful.
If the template was external,
how does the template file get attached/referenced? At work, we currently
use the build-helper-plugin from codehaus to attach additional files to our
build to push to the repository, maybe pulling that plugin, or a variation
of it in as something to attach template files ( or any ) to the build, and
still have the<template/> section you mention to use them.
Yep, a packaging plugin that is very simple and uses the same calls as the
build-helper, resulting in something like:
pom.xml
<project xmlns...>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-release-profile-template</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom-template</packaging>
</project>
pom-template.xml (default)
<project xmlns...>
(no coordinates)
<build>
...
</project>
Then, if you have multiple, pom.xml is:
<project xmlns...>
<groupId>org.apache.maven.templates</groupId>
<artifactId>maven-release-profile-template</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom-template</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pom-template-plugin</artifactId>
<version>1.0</version>
<configuration>
<templates>
<template>
<file>pom-template-source-and-javadocs.xml</file>
<classifier>source-and-javadocs</classifier>
</template>
<template>
<file>pom-template-source-only.xml</file>
<classifier>source-only</classifier>
</template>
</templates>
</configuration>
</plugin>
</plugins>
</build>
</project>
The other idea I had a long time ago when thinking about this briefly, is
there any way of using XInclude [1] with a custom URI resolver for
repositories to just pull in POM parts ( not as type safe tho ).
<project xmlns:xi="http://www.w3.org/2001/XInclude";>
<groupId>com.mytest</groupId>
<artifactId>mytest</artifactId>
<version>1.0-SNAPSHOT</version>
<xi:include href="com.mytest:mymixin:1.0:xml" xpointer="mixindeps"/>
</project>
( here - mymixin.xml could be a standard pom, with<dependencies
id="mixingdeps">
[1] http://www.w3.org/TR/xinclude/
Someone else raised this in the threads I listed, but I think we want to retain
the ability to describe the POM in things that aren't XML.
- 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]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
