Yes, definitely. Just trying to address them ... Werner
Jerome Lacoste wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
