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/02 08:14:02 UTC

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

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


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

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-823?page=all ]

Brett Porter updated MNG-823:
-----------------------------

    Fix Version:     (was: 2.0-beta-1)
                 2.0-beta-2

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


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

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
    [ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


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

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-823?page=all ]
     
John Casey closed MNG-823:
--------------------------

    Resolution: Fixed

This is purely within the context of a single plugin. It's not MNG-831. There shouldn't be much in the way of concerns related to lifecycle stuff...

> 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


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

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-823?page=all ]
     
Brett Porter reopened MNG-823:
------------------------------


reopening due to concerns about workability of solution in the lifecycle.

> 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


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

Posted by "Dan Tran (JIRA)" <ji...@codehaus.org>.
    [ 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


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

Posted by "John Fallows (JIRA)" <ji...@codehaus.org>.
    [ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


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

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-823?page=all ]

John Casey updated MNG-823:
---------------------------

           Description: 
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




  was:

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




            Complexity: Expert  (was: Intermediate)
    Remaining Estimate: 2 hours
     Original Estimate: 7200

added ContextEnabled interface to maven-plugin-api, which adds get/setPluginContext(..). AbstractMojo now implements this class, which allows the plugin manager to add a shared context map to a mojo before executing it. I didn't modify Mojo directly, in order to preserve API integrity for direct implementors out there.

> 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
>         Remaining: 2 hours
>
> 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


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

Posted by "Dan Tran (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-823?page=comments#action_45767 ] 

Dan Tran commented on MNG-823:
------------------------------

One more use cases from maven-native-plugin.

There are cases where I need to compile a list of source file using diffrent compiler flag.  From plugin configuratoin
I can force the compiler mojo to execute more than one.  Now I need to a way to passing more than one  set of compiler output files ( .o, .obj, .res) into my linker mojo.

The work around is to create a separate static lib project to produce a lib artifact and have the main project to 
depends on this lib artifact.

So a share context within a pom execution is the answer.





> 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


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

Posted by "Dan Tran (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-823?page=comments#action_45789 ] 

Dan Tran commented on MNG-823:
------------------------------

I figured out a solution for maven-native-plugin where all compiler ouput file paths are placed in a temporary file in target dir so that the linker mojo can pickup the file list.



> 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


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

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ 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