Ringo, let me try to address the more general issue presented in this your reply, i.e. stability.
Regards Werner De Smet Ringo wrote: > Werner or other Castor committer, > >> That's a problem, as I was just about to advise you to switch to newer > >> releases of both the Maven plugin as well as Castor itself. > > Sorry to say, but I always find this a problem with OpenSource projects > in use in commercial environments. I think this is a bit unfair, to be honest. I know of many OS projects that stick with 'oldish' design decisions for one reason only: product stability. Just to give you an example: it has taken us 2.5 years to drop Java 1.4 support from this product. We have been going back and forth about this, and only now (with 1.3 RC1) come to the conclusion that it is about time. And this late decision has had some serious side-effects for us committers, in that we e.g. could not drop could that was written with java 1.3 and 1.4 in mind, etc, use generics to simplify things, etc. > The OpenSource project evolves much > faster than the commercial environment is willing to keep in sync. I do consider this to be a benefit, to be honest, having worked myself for years in the (by-now) second largest investment bank for 3+ years. Stability was like a mantra, and there was too much. In general, you do not have to switch to a new release any time one is being made available, and it seems like you have been careful in not doing so anyhow. > In > the Castor case, this is used in a product setup with 200+ Maven modules > of which about a quarter are using Castor for XSD transformation. Okay, and here's where I have to admit that we (actually mself) made a wrong decision about two years ago, changing public API without even noticing it. Unfortunately, there was nobody that told me in time, and as a result the Maven 2 plugin for Castor does not offer a seamless upgrade path from older version of Castor to newer ones, as it basically forces you to upgrade as you switch to newer (recent) versions of the Maven 2 plugin for Castor. > Project managers interpret a Castor upgrade (or any other library/tool) > as an additional risk on top of the functional changes already taking > place within their project scope. With this in mind, I hope you can > better understand why a Castor upgrade is not possible. Let me re-assure you that I am more than aware of those risks and - more importantly - that train if thought (with a project management (only) focus .. ;-)). But let me add that you are not alone out there. a) There's the community (including ourselves). b) There's always an option to engage with e.g. a committer through professional services, and get their time and knowledge to get you moving faster/again on the migration path. I have been doing this myself in the past two years, and quite often that time spent with a company (individually) produced something that either increased the quality of the OS product or added new functionality. <shameless plug> You can always drop by at http://www.indoqa.com and ask us whether we can assist you with any tasks related to OS projects where we are long-term committers, e.g. Castor, Cocoon, .... </shameless plug> In other words, OS is about give and take. Otherwise, it would not be where it is in today's public appreciation. > >> I don't really know. I do know that with recent SNAPSHOT versions of >> the Castor Maven plugin, things work without any problems. Let me put >> it like this: it definitely is not a problem of castor itself. I could > >> have a look at this in detail, but looking at very old code does notg >> look really appealing to me .. ;-). > > As an engineer, I'm with you on that. I also don't like looking back to > far in the past. :-) > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
