[
http://jira.codehaus.org/browse/MPLUGIN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2512 to MPLUGIN-50:
------------------------------------------
Description: (was: On ocassion a plugin may have dependencies upon
non-java artifacts even though the plugin/Mojo is written in Java. For example
the maven-exec-plugin could be extended to support execution of dotnet
executables. It is assumed the dotnet executable (perhaps a code generator)
will be executed by executing a system call. The Mojo should somehow be able
to make maven aware of the dotnet executable (and it's transitive dependencies).
This can be done today as long as the dotnet executable is a versioned
dependency. On the other hand if the dotnet executable is a snapshot version
found in a sister module (released/packaged together) , the only way to avoid
problems is to be very careful of the ordering in the modules configuration of
the top level pom. (Thats what I'm doing today).
Chat log from #maven IRC channel
================
[15:26] nawkboy: How far out is mvn 2.1?
[15:26] jdcasey: nawkboy: :-)
[15:26] jdcasey: ...get comfortable
[15:27] jdcasey: we're still putting together the list of subjects we want to
tackle, from a much larger list of possibilities
[15:27] jdcasey: it's slow going, because many of us have less time to work on
it than we'd like, unfortunately
[15:27] nawkboy: Are you going to allow a plugin to inject dependencies in some
fashion?
[15:28] nawkboy: For example I have a mojo which runs a dotnet executable.
[15:28] nawkboy: My mojo has to first download the dotnet executable from the
repo (using the artifact resolver).
[15:30] nawkboy: So although the mojo needs to execute a given artifact , the
mojo code itself doesn't actually need the artifact to run. Its just the
system call my mojo is making that needs the artifact resolved.
[15:30] nawkboy: So in conclusion I have a Mojo which effectively has a
dependency maven isn't aware of.
[15:31] jdcasey: nawkboy: can you not use a plugin-level dependency in that
case?
[15:31] jdcasey: should be injected straight into the plugin container's
classpath
[15:31] jdcasey: is the app dependent on that artifact before or after the
plugin runs?
[15:31] nawkboy: If my mojo could somehow register this extra dependency things
would be improved.
[15:32] nawkboy: Well my plugin is java, but the executable I resolve and run
is dotnet. The java based Mojo won't like having a dotnet dependency.
[15:32] jdcasey: hmm
[15:32] jdcasey: and the executable is not tailored to that particular app,
right?
[15:32] nawkboy: Another way to think about this is in terms of the
maven-exec-plugin.
[15:33] jdcasey: it's not really a project dependency, though, is it?
[15:33] jdcasey: it's not used by any project code, right?
[15:33] jdcasey: hmm
[15:33] nawkboy: The fix I made http://jira.codehaus.org/browse/MEXEC-4 lets a
csharp project use the maven-exec-plugin to start up a java based server.
[15:34] jdcasey: well, I think a better solution in that case would be to
provide better tools for resolving these things, or an annotation saying "I
don't need this in my classpath, but get it anyway, and inject the path here"
[15:34] nawkboy: But my fix only works nicely since the server I am starting is
java based. If the server I wanted the maven-exec-plugin to run was written in
say perl, I would have a smilar to problem to that described above.
[15:34] nawkboy: bingo. I think you got it.
[15:35] jdcasey: nawkboy: file a jira for that, if you would...in the MNG
project
[15:35] jdcasey: so we can track it.
[15:35] jdcasey: that's a pretty new request, AFAIK
[15:36] jdcasey: there are some folks who want to inject a new project-level
dep because they're instrumenting the source/classes...
[15:36] jdcasey: but IMO that's a wrong approach...but this is different
[15:36] nawkboy: Potentially, a Mojo (say the maven-exec-plugin trying to start
a perl based process) might only know what these sort of dependencies where
based on the plugin's configuration.
[15:37] nawkboy: where=were
[15:39] nawkboy: MNG? Where is that? I'm on the codehaus JIRA, but don't see
a project of MNG.
[15:39] *** yuri has joined #maven.
[15:39] jdcasey: hmm...ok, but it would be nice to have some plumbing for that,
so we can accommodate it in things like a "go-offline" mojo
[15:39] jdcasey: http://jira.codehaus.org/browse/MNG
[15:40] nawkboy: What component should I place it under?
[15:40] jdcasey: is there one for plugin tools?
[15:40] jdcasey: or plugin management?
[15:40] * jdcasey goes to look
[15:40] nawkboy: Plugin API, Plugin Creation Tools, Plugin Requests, Plugins
and Lifecycle
[15:41] jdcasey: Plugins and Lifecycle and Plugin Creation Tools, I
think...just use the CTL-click method :)
[15:41] jdcasey: should get you close enough, anyway)
Fix Version/s: (was: Reviewed Pending Version Assignment)
Component/s: (was: Plugin Creation Tools)
(was: Plugins and Lifecycle)
Key: MPLUGIN-50 (was: MNG-2512)
Project: Maven 2.x Plugin Tools (was: Maven 2)
> Special Runtime Plugin Dependencies
> -----------------------------------
>
> Key: MPLUGIN-50
> URL: http://jira.codehaus.org/browse/MPLUGIN-50
> Project: Maven 2.x Plugin Tools
> Issue Type: New Feature
> Reporter: James Carpenter
>
--
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
