I'll try to address some of your questions/concerns/suggestions with info on
what I see as practical/supported/reasonable today. I'll leave the bigger
philosophical and architectural ruminations to those more qualified. (I
will say though that you might be interested in the "composition versus
inheritance" topic at:
http://www.sonatype.com/people/2009/11/maven-3x-paving-the-desire-lines-part-one-2/)
antrun isn't for creating build logic that _non-inheriting_ poms can use.
e.g. references like ${project.artifactId} always refer to the
containing/inheriting pom, and are only relevant/resolved/evaluated when the
antrun:run goal is executed on the containing/inheriting pom. the
antrun:run goal only executes the logic when the containing/inheriting pom
is going through _its_build_process_, not when some other pom depends
(either through <dependency> or <plugin>) on it.
the quickest way to slap together some ant and wrap a maven plugin around it
is to either use
groovy+antdsl: http://groovy.codehaus.org/Using+Ant+from+Groovy
or
ant-based-plugin:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html
I mentioned the groovy+antdsl route because it seems easier and more
powerful to me. You don't have to manually construct the plugin metadata
file (you have to with direct ant-based plugins) and you can use all your
java/groovy/ant knowledge and capability together in the same source file.
--
View this message in context:
http://maven.40175.n5.nabble.com/Create-a-common-shared-task-for-the-maven-antrun-plugin-tp3346449p3349900.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
