Hi Martin,
impressive observations, congratulations....
- about schema imports: yep, I had the same problems with svcutil when
compiling WSDL, and now I start to see some implementation pattern
that eventually is motivated by some minor detail that suggest the
developers to do so :(
- about the warnings: my strategy is to generate the classes and pac
in a JAR file, without ever keep in the project structure. Since it is
generated, does not make sense to keep the generate source code, just
the binaries :) IMHO... And then your warning goes away....
You can checkout my schema and ant tasks here:
https://footprint.dev.java.net/source/browse/footprint/
I am compiling a set of schemas and using import, and I don't remember
much problems regarding warnings.... perhaps I am just out of the
point...
best regards,
Felipe Gaścho
Footprint Owner
On Feb 6, 2008 3:30 AM, Thomson, Martin <Martin.Thomson_at_andrew.com> wrote:
> As a new user of JAXB, I've encountered a number of things that range
> from confusing features to irritations. Rather than raise issues
> directly, I thought I'd see if my gripes are reasonable or not before
> progressing. Some of these are sure to have come up in the past.
>
> There are a couple of features mentioned in the JSR or documentation
> relating to the bindings file that are not reflected in the schema (at
> <http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd>). I can
> understand that the "bindings_at_scd" attribute is an extension, but
> couldn't this at least be defined in an extension namespace? This would
> be consistent with standard practice for extending schema. This would
> require an anyAttribute definition on the base schema, but that's a
> reasonable thing to add anyway.
>
> The same applies to the "schemaBindings_at_map" attribute, except that this
> attribute is mentioned in the JSR explicitly.
> As an aside, I'd also recommend that this feature carry a
> warning - if you compile a schema A with xjc, then use this feature when
> compiling schema B (that references schema A), if schema B contains
> restrictions of types from A, the classes compiled from schema A are not
> sufficiently aware of the restrictions and your (un)marshalling might
> fail in baffling ways.
>
> I don't like the fact that we identify schema by file name rather than
> namespace URI. All other APIs use the namespace URI, and this allows us
> to decouple the concept of the schema infoset and it's representation.
> I could be demonstrating ignorance on this point, but from my reading of
> the JSR, I can't see why this choice was made. For most schema, the
> targetNamespace should be sufficient. Keeping the filename as an
> alternative method of identification might be necessary for those rare
> (?) schema that do not have a target namespace.
>
> The implementation of xs:any is cumbersome where it is subsequently
> restricted to include specific element definitions. It would not be
> especially onerous to add get/set implementations on the restriction
> type that transparently pass JAXBElement<?> instances to the underlying
> list.
>
> xjc is too finicky with argument order. If I define schema that include
> imports without a schemaLocation attribute, all the imported schema must
> be included on the command line before the schema that includes them, or
> else xjc has a fit.
> (Side note: using schemaLocation is, in general, a bad idea in many
> scenarios, e.g. standards documents. Since the actual location or file
> name isn't necessarily known a priori, any value specified for this
> attribute. There are always better ways to specify where to find
> schema, like the LSResourceResolver and the JAXP
> "http://java.sun.com/xml/jaxp/properties/schemaSource" property.)
> This argument order problem is especially bad when using the Ant task,
> because the Ant fileset isn't specifically ordered. This doesn't work:
> <schema dir="${schema}" include="xml.xsd my.xsd" />
> Instead, this is what you need to do:
> <schema file="${schema}/xml.xsd" />
> <schema file="${schema}/my.xsd" />
> (Side note: the Ant task consequently reports that it is compiling
> xml.xsd and others, which isn't very helpful, because all compilations I
> run now say exactly the same thing. In fact, the last one on the list
> is probably the most interesting one.)
> To address this problem, xjc would have to inspect the targetNamespace
> of each of the input schema and create an LSResourceResolver.
>
> The codegen creates code that generates a lot of warnings from stricter
> compilers. This isn't a big deal; after all, it IS valid, but it
> generates a great deal of warnings. My recommendations (which are
> subject to my personal preferences, of course, add your own slant):
> - Add @SuppressWarnings("nls") to the generated ObjectFactory class, or
> just the QName constants it declares.
> - Setters all take an argument named "value", which shadows the
> instance variable (particularly if you have elements in the form <x
> a="b">xx</x>). It would be less chancy to prefix an underscore to the
> field name: e.g. setX(String _x) {this.x = _x; }
> - A few empty blocks are created. Extending classes that represent
> restrictions are prime culprits.
> - A few places don't use the "this." qualifier on instance fields where
> they could.
> - Note: Run a few generated files through Eclipse with all the warnings
> turned on and witness the joy ;)
>
> Regards,
> Martin
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>