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. The OpenSource project evolves much faster than the commercial environment is willing to keep in sync. 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. 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. > 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. :-) > Can you wait a few days ? I am in the middle of preparing and shipping > Castor 1.3 RC1, and I'd rather focus on this for the next few days. > > Or maybe some fo my peer committers find the time to have a short peek > at the 1.0 release of the Maven plugin for Castor. > Can you provide us with a minimal sample POM that shows your config > and e.g. XML schema fragments, binding file fragments, etc ? >From (1), you can download a small Maven2 project that reproduces my problems. The only thing you might have to add in the POM is the location of the Maven repos/proxies you use. (I will monitor the list to see if the attachment comes through. Our mail server often strips attachments. If that is the case, I will follow-up myself with other details to get hold of the test project.) The project contains 2 XSD files that are converted. Both files are reduced (and obfuscated :-) ) versions from production XSD files. The XSD files come from one of our business partners, which means that any solution proposed by you should not mention changing the contents of the file. I'm really limiting your options, aren't I? :-) FileA will give you warnings, while FileB transforms correctly. For the inputDetails related classes, FileB generates to an abstract InputDetailsType class and a concrete subclass InputDetails. FileA generates to a class with this definition: public class InputDetails extends InputDetails implements java.io.Serializable I think it is clear that such a cyclic inheritance is not good. There is no InputDetailsType class in the case of FileA, but let me say that there wasn't one in the Maven1 case either! However, Maven1 transforms FileA to a set of classes where the class definition of InputDetails reads like this: public class InputDetails implements java.io.Serializable First of all, I'm puzzled why this seems to work in the Maven1 case, and not with the Maven2 plugin. On the other hand, it does puzzle me why it worked in the Maven1 case since the contents of the file seem to ask for a binding file which wasn't there in the Maven1 case. (1) http://www.atriso.be/CastorGenerator.zip Ringo ************************************************************* Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu. ************************************************************* --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
