Jason van Zyl wrote: >Strictly speaking properties don't have to correspond to fields, they >may involve a calculation say. I was just trying to account for that >case even though in the case of mojos the field name will most likely >match the the read/write method name. > > Sorry, I don't get what you mean by this - do you have an example?
>>This means that they don't work >>under bean conventions (and IDE generation of getters/setters :) >> >> > >That's just a convenience where the IDE uses the field name as the basis >for the read/write methods. > Actually, I was thinking more along the line of how javabeans are specified to work. >But you may very well have a property where >the corresponding read/write methods use no fields, or use multiple >field values, or mutate a field value. > > How would you introduce a property that didn't have a field in the current set up, or one that used multiple fields without just picking one of those fields as the one with attached metadata? You can definitely do calculations on one field in the getter/setter as is - but this technique just seems like a way to give it a different name than the field name, for which we already have "alias" for configuration. I assume configuration maps to the setters, not the field itself when present, so this is equivalent. I'm only looking at this from the mojo perspecitve, but I'd prefer to keep it simple. >Easy enough to change to as in the case above Plexus will simply attempt >to use the setter first. > > So does this mean that it works without the property parameter? If that's the case, then I'm fine with it and we can just use the default case with property as the field name. property can remain as an advanced use case. I still wonder how this could be made to be useful - attach the metadata to the getter instead perhaps (like in beanshell)? - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
