You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kenney Westerhof <ke...@apache.org> on 2006/05/12 20:02:22 UTC
design issue
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.
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.
Thoughts on how to best approach this?
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: design issue
Posted by Kenney Westerhof <ke...@apache.org>.
On Sun, 14 May 2006, Jason van Zyl wrote:
>
> 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?
Essentially, yes, except there's no component lookup because the
"component"'s class is specified.
> And you did the work in Plexus to support this (I saw a commit
> related to it I believe)?
Actually, the work is related but not needed. I've added support for
auto-detecting classes in the component package using the field name
of a private property. The work in maven core has essentially the same
effect, except there's no auto-detecting and you can use objects from
other packages than the component's package.
Also, this autodetecting was already in place for Collections; for
instance, defining
private List someThing;
had the effect that it will be a list of SomeThing objects, if available.
> Also just curious what the use case was that was the impetus for
> adding this. I think it's a good idea, just curious.
Jerome would have to answer that, but technically it comes down to
not being able to specify a fields type as an interface and providing a
default implementation:
/* @parameter implementation="InterfaceImpl" */
private Interface field;
You had to specify the implementation as the field's type.
So if a user specifies a configuration like <field implementation="X"/>
then X has to extend the field's type. Now you don't have to extend,
but you can also implement an interface.
> > 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.
Hm. Well here we have a problem. This is pretty much maven specific, since
we're not dealing with components. But I think a standard component
definition as used everywhere in plexus is a good use case:
- you specify a role (the interface: Interface, above)
- you specify an implementation class (InterfaceImpl, above).
There's no way to do this in Maven Mojo's using the @parameter
annotations, except by adding a plexus component descriptor for each
implementation and using the @component directive.
Also, all that's actually used from the plugin.xml is the <configuration>
section from <mojo>. The tags within <configuration> map to
parameters/fields, and are only present if there's a default value
supplied. So you cannot say
'IF the user specifies a configuration for that parameter
AND the type of that parameter is an interface,
THEN use _this_ implementation'.
Meaning: you can only specify the implementation for a parameter/field if
it has a default value. Btw, this is weird: WHY is the implementation
specified in plugin.xml, as plexus uses the same scheme to detect field
types as qdox: use the type of the field as the implementation type.
There's really no need to specify an implementation, since it can never be
different from the field type.
It basically comes down to being able to define the types of fields
as interfaces, much like List, in order to keep proper abstraction, and
not declare an implementation in the class' binary, without needing
to specify plexus component descriptors.
Also, since we're (maybe) on this path, i'd like to toss in the
following idea: it might be worth-wile to be able to specify the types
of elements used in a list, like List<SomeInterface>, but without using
Java 5.
For instance, the implementation attribute of @parameter will, in my local
version of m2, specify the implementation for the list only. The same goes
for Maps.
We could use java 5 notation in the implementation attribute:
/* @parameter implementation="java.util.ArrayList<some.package.Foo>" */
List fooList;
... until we properly support Java 5. :)
On the other hand, all this is probably already possible by using plexus
component descriptors.
But the current trend (J2EE 5) is to abandon component descriptors and
use runtime @Annotations. I've already written a working mini component
detector and configurator for this, and it would be pretty easy to
update plexus to also support this scheme. We could do away with qdox and
use proper annotations and in the mean time also drop component
descriptors.
But these are just dreams for the future :)
Sorry for the long reply and thanks for reading this far!
-- Kenney
>
> >
> >
> > Thoughts on how to best approach this?
> >
> >
> > -- Kenney
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> Jason van Zyl
> jason@maven.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: design issue
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org