On Fri, Apr 11, 2008 at 1:01 PM, Werner Guttmann <[EMAIL PROTECTED]> wrote: > > > Jerome Lacoste wrote: >> >> On Thu, Apr 10, 2008 at 2:34 PM, Werner Guttmann <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> >>> I have been looking at the existing code base of the Castor plugin for >>> some >>> days now, and it looks like I will have to break existing contracts to >>> get >>> it working again (fully, against all Castor releases). >>> >>> Right now (SVN), the plugin will run against versions of Castor starting >>> from 1.0.5 to now. But I'd like to get it working against older versions >>> of >>> Castor as well, but the way it's implemented would not allow that. >>> >>> There's an arae of code where the plugin tries to outsmart the way >>> Castor >>> normally works. And the way this has been implemented .. well, moves a >>> couple of configuration parameters supplied by the means of a file to the >>> plugin configuration section. >>> >>> As already said, I'd like to get it working again against all versions >>> of >>> Castor, and would like to refactor the plugin. For this, I would have to >>> drop this 'smartness'. >>> >>> >>> My question: is this actually an option with Mojo plugins. Can we (well, >>> not) easily drop some configuration parameters even though they have been >>> supported in the past. Of course we'd make this clear in the plugin >>> configuration (as much as we don't like this), but I cannot see a way >>> around. >> >> I think Trygve was very against that idea some months ago arguing that >> we can not break backwards compatibility. > > Which I can perfectly understand, as per my explanation(s) above. I am just > arguing with myself whether the pragmatic approach as outlined by yourself > doesn't complicate things for users. > > Personally, I think that the benefit that has been provided by the current > implementation with regards to 'over-engineering' plugin configuration (and > thus configuration of the underlying Castor source generator) is limited, if > not tending towards 0. I mean, the same can be achieved by supplying a > source generator configuration file as part of the plugin configuration. And > as it's this duality that makes the code hard to maintain, I'd like to get > rid of it. > > Anyhow, I think you've got a point there, and we'll definitely consider it.
Hei, What's the status with/plans for the castor plugin ? Do you plan to release 1.0.2 or 2.0 as next release (POM says 2.0, Jira says 1.0.2) ? I've commented some of the issues in Jira: http://jira.codehaus.org/browse/MCASTOR Cheers, Jerome --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
