Hi Stevo, even if you are using Castor as technology of choice with spring-ws and spring-oxm, there's absolutely no need to generate a mapping file from your XML schema(s). In other words, use the XML code generator through the Maven plugin for Castor to generate Java (and descriptor) classes from your schemas, and Castor will be able to pick those up for (un)marshalling without any need to supply mapping files.
The descriptor classes generated in addition to the Java classes are actually an equivalent to the mapping file(s), with far better support for validation, etc. Just make sure that you include Java classes, descriptor classes and .castor.cdr files with your deployment packaging, and you should be fine. Regards Werner Stevo Slavić wrote: > Hello Werner, > > I'm using Spring-WS with Spring-OXM abstractions over OXM frameworks, and > its Castor support, all for easy replacement of OXM implementation. Thus, > when generating sources with castor-maven-plugin I've set "marshal" > parameter to false, and want to have mapping.xml generated along with > classes from set of XSD's, and configure Spring's CastorMarshaller with > generated mapping.xml. Rest of my comments are inline. > > Regards, > Stevo. > > On Tue, Aug 11, 2009 at 10:21 AM, Werner Guttmann <wgut...@codehaus.org>wrote: > >> Hi Stevo, >> >> can you please let me know why you want a mapping file to be generated >> at all ? Java classes plus descriptor classes should be sufficient for >> you needs, if this is about (un-)marshalling to and from XML (as defined >> by your XML schemas). >> >> Some more answers are inline. >> >> Regards >> Werner >> >> Stevo Slavić wrote: >>> OK, thank you very much! >>> >>> Generating classes works well now, but once I set generateMappings to >> true, >>> generate goal fails with following error: >>> >>> The following exception occured while validating field: _classMappingList >> of >>> class: org.exolab.castor.mapping.xml.MappingRoot: The following exception >>> occured while validating field: _classChoice of class: >>> org.exolab.castor.mapping.xml.ClassMapping: The following exception >> occured >>> while validating field: _fieldMappingList of class: >>> org.exolab.castor.mapping.xml.ClassChoice: The following exception >> occured >>> while validating field: _bindXml of class: >>> org.exolab.castor.mapping.xml.FieldMapping: The following exception >> occured >>> while validating field: _name of class: >>> org.exolab.castor.mapping.xml.BindXml: Name '-error-if-this-is-used-' is >> not >>> a valid QName. >> If you do not set <generateMappings> to true, does code generation >> succeed ? > > > Yes, code generation alone succeeds. +1. Great. Please see above as to wy that should be sufficient. >>> Any idea what could be the problem? Guess I'm hit by this Castor >>> issue<http://jira.codehaus.org/browse/CASTOR-676>. >>> Advices/workarounds are welcome too. >>> >>> Version 1.5 of castor-maven-plugin is being used. There seems to be no >>> (documented) way to set output directory for mappings file ("dest" >> parameter >>> does not seem to influence generation of mapping.xml). >> Correct. But there's two more MOJOs that specialize in creating just >> mapping files. Please have a look at >> >> http://mojo.codehaus.org/castor-maven-plugin/plugin-info.html > > > Thanks for the info, missed those two. There are no usage examples for them > documented neither > here<http://mojo.codehaus.org/castor-maven-plugin/usage.html>nor > here <http://www.castor.org/srcgen-maven-plugin.html>, this might have > attributed to me missing these two goals . For mappings goal I'm having > problems configuring classes parameter. Documentation for the field states > it is a set but in fact it is a map. By looking on source code where map is > used, key is extracted as class name while map value is mapping name. If > classes parameter should be configured using usual way maven plugins > configuration parameters of map type are configured, then classes should be > defined something like this: > > ... > <classes> > <foo.bar.Class1>mapping.xml</foo.bar.Class1> > <foo.bar.Class2>mapping.xml</foo.bar.Class2> > ... > </classes> > ... > > With generate goal bound to generate-source phase, and mappings goal (by > default) bound to process-classes phase with single class (generated by > generate goal) configured to be processed by mappings goal, mappings goal > fails with ClassNotFoundException (can not find class which has been > generated by generate goal in an earlier phase). In eclipse with m2eclipse > installed target/generated-sources/castor gets configured (Update project > configuration) as source directory, but I'm not sure if Maven sees it as > such when building project. Does castor-maven-plugin somehow suggest maven > that castor-maven-plugin's dest directory should be treated as source > directory? If not, am I supposed to use build-helper-maven-plugin to > accomplish this? Nevertheless, I did it, used build-helper-maven-plugin's > add-source goal configured with > ${project.build.directory}/generated-sources/castor source. Unfortunately, > castor-maven-plugin's mappings goal would still fail with same > ClassNotFoundException being thrown. Wondering what could be the cause. I will come up with an answer to this later on. Problem is that I am not familiar with those two goals, but as far as I remember there's integration tests for these two MOJOs. > Let's not forget that using mappings goal is a workaround for failing > generate goal with generateMappings set to true.** In any non trivial usage, > configuration of classes parameter of castor-maven-plugin's mappings goal > will be ugly. Wish there was e.g. packages parameter, or wildcards support > for more coarse grained selection of classes to be mapped. > > One more thought, in maven lifecycle compile phase comes after > generate-resources and process-resources phases. castor-maven-plugin's > mapping file basically generates a resource (mapping.xml), but I guess, > since it requires compiled classes, it is bound to process-classes phase, > first one after compile phase. > > Thinking of trying build with castor-maven-plugin 2.0-SNAPSHOT, maybe it > will help overcome these issues. From the 1.5 announcement it was mentioned > that 2.0 will be soon released - hopefully that's still the plan. Yes, should happen within a few days. >>> Currently, in my case >>> with the error above, (empty) mappings.xml file gets generated in >> ${basedir} >>> of the project. It's a resource so by default IMO it should be generated >> in >>> ${project.build.directory}/generated-resources/castor directory. Couldn't >>> find existing issue for this in MCASTOR JIRA. Is there a way to configure >>> mappings file output directory? >> No, but please feel free to add a new issue. I guess I don't have to >> mention that a patch would be warmly welcome as well. > > > OK > > >> >>> One more issue, plugin fails a build if there is no >>> ${basedir}/src/main/castor directory in the project. If I understood >> well, >>> this will be fixed for v2.0 of the plugin. >> That should have been fixed for 1.5 already. Odd. But if it still does, >> please feel free to raise a issue (even if it's a duplicate). > > > OK > > >> >>> Regards, >>> Stevo. >>> >>> On Mon, Aug 10, 2009 at 8:44 PM, Werner Guttmann < >> werner.guttm...@gmx.net>wrote: >>>> Hi, >>>> >>>> You can always supply a binding file to the (underlying) Castor XML code >>>> generator to override the default output type for <xs:date> instances. >>>> >>>> Regards >>>> Werner >>>> >>>> Stevo Slavić wrote: >>>>> Hello castor(-maven-plugin) users, >>>>> >>>>> Does anyone know why does castor-maven-plugin (1.5) for xs:date >> elements >>>>> generate class properties of org.exolab.castor.types.Date type? Is >> there >>>> any >>>>> way to have it configured to generate java.util.Date instead? >>>>> >>>>> Regards, >>>>> Stevo. >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
