On 12 May 06, at 11:02 AM 12 May 06, Kenney Westerhof wrote:
Hi,
(none of this is committed)
Jerome and I have added support for an 'implementation' parameter
to the @parameter tag, so that you can use interfaces as field-types.
So this will essentially work in the same way that component
requirements are listed as interfaces, yes?
And you did the work in Plexus to support this (I saw a commit
related to it I believe)?
Also just curious what the use case was that was the impetus for
adding this. I think it's a good idea, just curious.
The plugin descriptors now have an extra <implementation> tag next to
<type> (which is currently unused, btw).
There's just a little problem in merging that information with the
plugin
configuration. There are 2 ways to do this:
1) PluginDescriptorGenerator can add a configuration line for each
parameter that has an implementation attribute. This way the
DefaultPluginManager doesn't have to be modified, since the
mergeTopDown* method automatically picks up these configuration
lines.
Currently configuration lines are only added if a parameter has an
expression or a default-value attribute. This means that the
configuration
is only present if it has a value. Adding 'empty' configuration lines
like
<bla/> (this is just an example - my change would result in <bla
implementation="..."/> if there was an implementation
present, otherwise old behaviour)
cause maven to initialize that field, even if it does not appear
in the pom. I suspect the same goes for specifying them in the pom
since
the configurations are merged.
So the check whether to initialize a field / mojo property is
currently
located in the PluginDescriptorGenerator - which I feel isn't
right. If
this were to be fixed then this option would be valid.
2) have DefaultPluginManager merge the parameters <implementation>
tag as an xml attribute, but only if the configuration tag is
specified in
either the pom or the mojo descriptor. This is rather
straightforward, but
it's a breach of the abstraction currently employed in that code, and
it'll result in ugly code. I feel that it's not good practise add
'special cases' like this in places where they don't belong.
Can I see the case you are using as I think it's best to try and put
everything required for this in Plexus (if you haven't already) and
then figure out how to map it best from the Maven side. So to support
this in a standard Plexus component descriptor and then make it work
with the generated plugin.xml.
Thoughts on how to best approach this?
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jason van Zyl
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
