-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, Chris. :)
Comments inline.
Chris Berry wrote:
| Greetings,
| I have found that one could easily produce a generic build system in m1
| using the import statement from jelly:core inside of the maven.xml
file. I.e
| .
|
| <j:import inherit='true' file='mybuildtools-1.2.3.xml' />
|
| where the file; mybuildtools-1.2.3.xml, would contain parametrized goals
| which are "filled in" for the case at hand (i.e the goal might contain
| ${artifactId} which is appropriately set to that of the current
project.xml
| ).
|
| Build systems like this are very useful. You can create a system where
your
| general users don't have to know much about what is happening
| under-the-covers. And you can upgrade the system easily. I know some
of you
| are cringing, but in large organizations it is important to homogenize the
| build system, and there are a wide range of experience levels. The last
| thing you want is for every project to do-their-own-thing. Yes, they will
| need some permutations, but the general system remains constant.
|
| How would one accomplish this in m2??
| Could one use a parent POM??
This is exactly how we'd suggest doing it. In muli-user installations,
it's also possible to control plugin versions explicitly using a plugin
registry, and it's conceivable that one could create a global plugin
registry loader that would read from a central URL or something.
| For example,
|
| <project>
| <modelVersion>4.0.0</modelVersion>
| <groupId>myorg.com <http://myorg.com></groupId>
| <artifactId>tools</artifactId>
| <version>1.0</version>
| <packaging>pom</packaging>
|
| <properties>
| <somePluginVersion>1.0-SNAPSHOT</somePluginVersion>
| </properties>
Because plugins always update LATEST version metadata, and the plugin
version resolver looks at LATEST metadata now (as of RC, I believe), you
shouldn't need to do this. Either specify it in the plugin-registry.xml
or allow Maven to resolve it using LATEST/RELEASE metadata.
|
| <build>
| <plugins>
| <plugin>
| <groupId>org.apache.maven.plugins</groupId>
If your plugin's groupId is configured like this in the settings.xml:
<pluginGroups>
~ <pluginGroup>com.myco.plugins</pluginGroup>
</pluginGroups>
then this element can also be left out, though specifying it removes any
chance of ambiguity. Also note that the 'org.apache.maven.plugins' and
'org.codehaus.mojo' groupIds are searched by default, in that order.
| <artifactId>maven-some-plugin</artifactId>
| <version>${somePluginVersion}</version>
| <configuration>
| <someConfig>${artifactId}-${version}</someConfig>
| </configuration>
| </plugin>
| </plugins>
| </build>
| </project>
|
| And in the child POM;
|
| <project>
| <modelVersion>4.0.0</modelVersion>
| <groupId>myorg.com <http://myorg.com></groupId>
| <artifactId>someproject</artifactId>
| <version>1.0</version>
| <packaging>whatever</packaging>
| <parent>
| <groupId>myorg.com <http://myorg.com></groupId>
| <artifactId>tools</artifactId>
| <version>1.0</version>
| <parent>
| </project>
|
| But could this work?? Won't the parent try to replace all of the
variables (
| e.g. artifactId, etc) with what's defined in it's POM??
Expression resolution takes place *after* intheritance and profiles are
applied to the current POM, which means they resolve against the
effective POM. If you run:
m2 projecthelp:effective-POM
(adding, of course, any -D options that might be used to trigger
profiles), you will see the POM that is used to resolve the expressions
in plugin configurations.
Plugin configurations are inherited from parent to child by default,
with local overrides taking precedence. It's possible to change this
behavior (including merging vs. override of plugin configuration
wholesale, and inhibiting plugin inheritance), but in general this
statement holds. So, what you've described above will work.
HTH,
john
| Is there a better way to accomplish this in m2??
|
| Thanks,
| -- Chris
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDVQvJK3h2CZwO/4URAni/AKCpDNWy8G0jmT5Gum8VXhuL3ZvCpwCdFkIn
kspKuWzofISnBe6eenE+UWU=
=x+fs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
