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: [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] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
