[ http://jira.codehaus.org/browse/MNG-823?page=comments#action_46102 ]
John Fallows commented on MNG-823: ---------------------------------- There is another usecase for sharing context between mojos in the same plugin. Here is the email sent to Maven Users List. I'm writing a maven2 plugin that needs to parse various xml metadata files to drive it's behavior. There are a number of different (optional) goals in the same m2 plugin that need to consume the same xml metadata. Right now, each different goal is a different Mojo, with different instance state, so each Mojo is re-parsing the metadata files. Is there a best practice for sharing information across goals within the same plugin for the same lifecycle execution? Could the metadata be parsed on demand, and then maybe stored somewhere on the MavenProject for subsequent Mojos to locate? > 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-2 > 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]
