You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2005/09/27 21:53:11 UTC

[jira] Closed: (MNG-823) Ability to allow mojos to communicate with each others - other than project's source root and project's attachment

     [ http://jira.codehaus.org/browse/MNG-823?page=all ]
     
John Casey closed MNG-823:
--------------------------

    Resolution: Fixed

see it0073 for a test case, and maven-core-it-plugin for two mojo implementations that use this feature.

> Ability to allow mojos to communicate with each others  - other than project's source root and project's attachment
> -------------------------------------------------------------------------------------------------------------------
>
>          Key: MNG-823
>          URL: http://jira.codehaus.org/browse/MNG-823
>      Project: Maven 2
>         Type: Bug
>   Components: maven-model
>     Versions: 2.0-beta-1
>  Environment: xp, linux
>     Reporter: Dan Tran
>     Assignee: John Casey
>      Fix For: 2.0-beta-3
>  Attachments: pom.xml
>
> Original Estimate: 2 hours
>        Time Spent: 2 hours
>         Remaining: 0 minutes
>
> For native case, I need ability to allow my resource compiler mojo to tell my linker mojo additional resource output file (.res) to link at link time.
> This is for windows environment only.
> Brett suggests M2 to provide a share context between mojos
> Here is the the conversation on IRC
> <dantran> brett, I have a special case in native plugin where I need to tell linker to use additional files at packing phase, but the file is not on dependency list
> <dantran> like the ouput of microsoft resource compiler ouput
> <dantran> does it make sense?
> <brett> yes
> <dantran> resource compiling is a extra step at compile phase for windows env
> <brett> I think we should allow plugins to share a context
> <brett> so you can pass the results of that mojo onto another mojo within your plugin
> <dantran> yup
> <brett> but you probably don't even need that
> <brett> you can use the same condition used to trigger the resource compiler to trigger the addition of the files, right?
> <dantran> thinking..
> <dantran> resource compliler is triggered by user... 
> <dantran> just like generate-source type mojo.. but only at compile phase
> <brett> oh, really?
> <dantran> the linking api.. is very dummy .... 
> <brett> I thought it would be registered for any native build, and only do something if the target platform was win32
> <dantran> user has  a rc file ... adn compile it to .res file ..then pass to linker
> <brett> yes, I vaguely remember how it works :)
> <brett> ok, you are probably right, its not always configured
> <brett> for now, can the linker just use it if it exists?
> <dantran> yeah .. add target/native/myres.res to linker option
> <dantran> ugly thou
> <dantran> yes, the linker use it if it is on its list of external libs
> <dantran> plus its .o/.obj it knows about
> <dantran> so I have to specify the fullpath of the .res file .. ${basedir}/target/native/myres.res in linkermojo configuration
> <dantran> perhaps i can get the resourcecompilmojo to place the path of res file on what you called plugin context .. have the linker mojo to look for  that and pass to linker commandline
> <brett> we don't have a plugin context though
> <dantran> what about a context you mentioned?
> <brett> it doesn't exist
> <brett> yet
> <dantran> should i create a jira so you can track it?  or you already have one... a enhancement request
> <brett> create one
> <dantran> will do

-- 
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, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org