[ 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