[
http://jira.codehaus.org/browse/MGROOVY-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=167317#action_167317
]
Les Hazlewood commented on MGROOVY-189:
---------------------------------------
I looked at the Maven AntRun plugin's source - it is not a trivial exercise (at
least not in their code) to enable the 4 classpath references noted above -
wouldn't it be nice if the GMaven plugin provided similar references to avoid
people defining these themselves?
Would you mind pointing me to an example of how to do what you recommend? If
it looks dead easy, then I'll be happy to close this issue ASAP. Any pointers?
(If anything, your link would be in this issue and help other people searching
for similar solutions).
> Access Maven Classpaths for Ant Tasks
> -------------------------------------
>
> Key: MGROOVY-189
> URL: http://jira.codehaus.org/browse/MGROOVY-189
> Project: GMaven
> Issue Type: Improvement
> Components: examples
> Affects Versions: 1.0-rc-5
> Environment: gmaven 1.0-rc4
> Reporter: Les Hazlewood
> Assignee: Jason Dillon
> Priority: Critical
> Fix For: 1.1
>
>
> One of my biggest desires for the GMaven plugin is the ability to encapsulate
> legacy Ant build targets in a Maven plugin using the Ant Builder. This
> allows people to configure a Maven plugin as expected without knowledge of
> Ant (or Groovy of course) being used 'under the hood'. Granted, this is
> already available today, but it is missing one big thing that I know of that
> precludes many Ant tasks from running:
> Any ant scripts require a taskdef definition. e.g.:
> ant.taskdef( name: "blah", classname:"some.pkg.FQCN", classpath:"$aClasspath"
> )
> It doesn't appear that there is any way to access a Maven classpath to
> achieve this. The Maven AntRun plugin for example generates 4 classpaths:
> maven.compile.classpath
> maven.runtime.classpath
> maven.test.classpath
> maven.plugin.classpath
> It would be greatly beneficial if GMaven also enabled these (or similar)
> classpaths for use with the Ant Builder, then we could encapsulate all Ant
> details inside a GMaven plugin and the plugin consumer never needs to know
> these details. Perhaps use the AntRun plugin's support for this?
> Until then, our POMs must be littered with numerous unsightly embedded ant
> xml chunks (via the maven-antrun-plugin) since we need access to many 3rd
> party ant tasks that do not have a maven plugin equivalent. It'd be much
> nicer to hide this away from the POM configurer via a GMaven-based plugin
> with normal Maven configuration attributes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
