You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Dan Tran (JIRA)" <ji...@codehaus.org> on 2005/09/03 07:10:03 UTC
[jira] Commented: (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=comments#action_45738 ]
Dan Tran commented on MNG-823:
------------------------------
It is also needed by native compiler mojo where it can pass a list of its object (.o, obj) files to link mojo. This is a cleaner approach.
Currently, both compiler and linker mojos share the list of source files configuration. The linker has to figure out the actual paths of all compiled object file based
on an ouputdirectory and the source files (note the object file extension can be .o or .obj depending on compiler provider type and OS ).
> 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
> Fix For: 2.0-beta-1
> Attachments: pom.xml
>
>
> 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