AW: Implementing a Maven plugin with alternate mojo/component implementations?

2012-12-02 Thread christofer.d...@c-ware.de
Hi Robert,

I managed to actually get something working in the meanwhile.

Here's what I did:
- I created an API artifact containing the interface of my modules.
- I created several Implementations of the Interfaces each one annotated with 
@Component with the Role set to the Interface class and each one with an 
individual hint-name.
- I create one Mojo with a map property with MapHintName, ModuleType and a 
String property to select the desired implementation (defaulting to a default 
string)
- Now in the execute method of my Mojo I simply read the desired implementation 
name, fetch that instance from the map and use the Module interface to relay 
the call to that particular instance.

Semms to be doing the jobe nicely ... is this a valid approch or would a best 
practice do it differently?

Chris


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Sonntag, 2. Dezember 2012 15:57
An: Maven Users List
Betreff: Re: Implementing a Maven plugin with alternate mojo/component 
implementations?

Here are some plugins which you should have a look at:
maven-compiler-plugin ( compilerId )
maven-release-plugin ( mavenExecutorId )

Now you need to do some Plexus-stuff, since that's the DI-framework for Maven.
Every task-implementation needs to have the same interface (plexus role) and a 
specific id (role-hint) In your manager you can let Plexus fill a map based on 
the plexus role.
So now you can add a parameter to your plugin with a default taskId, and users 
can overrule it.
I think this meets your requirements.

Good luck,

Robert


Op Sun, 02 Dec 2012 12:33:43 +0100 schreef christofer.d...@c-ware.de
christofer.d...@c-ware.de:

 Hi,

 I am currently setting up a new Maven plugin project and am currently 
 faced with the following problem:

 I have fefined a dafaultLifecycle which defines which mojos should 
 generally be invoked in which phase. My problem now is that I would 
 like to have different implementations used for performing the tasks. 
 There should allways be a default mojo/component that is used if the 
 user doesn't specify which implementation he wants to use, but should 
 offer a way to tell the build to use a different implementation.

 Would it be good to have some sort of proxy-mojo that is allways 
 called and then relays to an implementation component based upon the 
 configuration, or would it be better do define completely independent 
 Mojos?  The Internet seems to be full of tutorials on creating Maven 
 plugins, but I haven't found a single one dealing with this particular 
 problem.

 Help greatly appreciated,
 Chris


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: AW: Implementing a Maven plugin with alternate mojo/component implementations?

2012-12-02 Thread Robert Scholte

Hi Chris,

yes, this is a right approach, matches close to what I described.

Robert


Op Sun, 02 Dec 2012 16:05:23 +0100 schreef christofer.d...@c-ware.de  
christofer.d...@c-ware.de:



Hi Robert,

I managed to actually get something working in the meanwhile.

Here's what I did:
- I created an API artifact containing the interface of my modules.
- I created several Implementations of the Interfaces each one annotated  
with @Component with the Role set to the Interface class and each one  
with an individual hint-name.
- I create one Mojo with a map property with MapHintName, ModuleType  
and a String property to select the desired implementation (defaulting  
to a default string)
- Now in the execute method of my Mojo I simply read the desired  
implementation name, fetch that instance from the map and use the Module  
interface to relay the call to that particular instance.


Semms to be doing the jobe nicely ... is this a valid approch or would a  
best practice do it differently?


Chris


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org]
Gesendet: Sonntag, 2. Dezember 2012 15:57
An: Maven Users List
Betreff: Re: Implementing a Maven plugin with alternate mojo/component  
implementations?


Here are some plugins which you should have a look at:
maven-compiler-plugin ( compilerId )
maven-release-plugin ( mavenExecutorId )

Now you need to do some Plexus-stuff, since that's the DI-framework for  
Maven.
Every task-implementation needs to have the same interface (plexus role)  
and a specific id (role-hint) In your manager you can let Plexus fill a  
map based on the plexus role.
So now you can add a parameter to your plugin with a default taskId, and  
users can overrule it.

I think this meets your requirements.

Good luck,

Robert


Op Sun, 02 Dec 2012 12:33:43 +0100 schreef christofer.d...@c-ware.de
christofer.d...@c-ware.de:


Hi,

I am currently setting up a new Maven plugin project and am currently
faced with the following problem:

I have fefined a dafaultLifecycle which defines which mojos should
generally be invoked in which phase. My problem now is that I would
like to have different implementations used for performing the tasks.
There should allways be a default mojo/component that is used if the
user doesn't specify which implementation he wants to use, but should
offer a way to tell the build to use a different implementation.

Would it be good to have some sort of proxy-mojo that is allways
called and then relays to an implementation component based upon the
configuration, or would it be better do define completely independent
Mojos?  The Internet seems to be full of tutorials on creating Maven
plugins, but I haven't found a single one dealing with this particular
problem.

Help greatly appreciated,
Chris



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org