[ http://jira.codehaus.org/browse/MNG-823?page=comments#action_47206 ]
John Casey commented on MNG-823: -------------------------------- I think it'd be pretty easy to have a Map stored in the plugin container's context, and add get/setContext(..) to Mojo/AbstractMojo. The plugin manager would pull the Map out of the plugin container context, and populate it into the Mojo...this would eliminate the problems associated with implementing Contextualizable directly (exposes plexus APIs to mojo developers), and provides a way of still supporting direct implementors of Mojo. Since the plugin container is reused, this should work for passing information between mojos. For embedding, we should have a method that will null/reset these maps in each plugin container...or maybe just destroy the plugin container... > 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 > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
