On 3/4/06, Jonathan Johnson <jonjohnson_at_mail.com> wrote:
>
>
>
> I used to put all of my XSD files under src/conf and distributed them
> > into the root of the jar. As such, PatternFilenameFilter and
> > GlobFilenameFilter would both work well.
> >
> > I noticed that the XJC jar had the binding.xsd under
> > /com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd inside the jar.
> > This is actually really good because it prevent classloader problems of
> > finding the wrong one by some other company. I started to modify the
> > resources section of my pom.xml, and realized there was a much easier
> > way.
> >
> > I have now moved all of my XSD files directly into the source
> > directory. In the IDE, they show up as a resource in that
> > package/namespace, and the resources part of the pom.xml automatically
> > can copy them into the correct directory without any sophisticated filename
> > mapping.
> > [jon] I agree that schemas should be placed in a package structure that
> > matches the source, but the schemas and bindings and any other resource file
> > should not live in the java tree. Instead the schemas and code should live
> > in the parallel packages at distinct source roots. For example
> >
> > \src\main\java\com\sun\foo\someclass.java
> > \src\main\schemas\com\foo\somecorresponding.xsd
> > When assembling a jar, yes the class files live in the same location as
> > the xsd, but the java and xsd sources should be kept separate as a best
> > practice.
> >
>
>
> I can see that. Maven's docs say that there should be a "resources"
> directory. Do you think we should use that, or do you think that the
> XSDs/XJBs need their own "schemas" directory. I ask, because, what if they
> are using DTD? That isn't technically schema, but should go in the same
> place.
>
> [jon] Resources are really meant for those items that are loaded by the
> classloader at runtime. Items in the resources tree are bundled into the
> distribution jar just as the *.classes are. Typical files are string
> bundles, and images directory, static property files, sound files, data
> files, etc. Schemas are used at compile time and not typically loaded at
> runtime from the classpath. *.xsd, *.dtd and *.xsb are compile time
> articfacts and should be kept separate from the runtime artifacts.
>
Interesting analogy, because they are loaded at runtime... In general they
are loaded for validation... In my case specifically, I copy the jar'd
resource into the local data directory....
As a side note, any open format should be including the schemas since they
define the format for interoperability... I don't see schemas as solely
compile-time artifacts. In fact, prior to JAXB, they were everything but.
As such, I do not see how they differ from any other resource, since you
still load it as something like this.getClass
().getResourceAsStream("/org/eoti/spec/mypackage/mypackage-1.0.xsd");
In fact, there would be a benefit to using the standard maven resource
directory... from their docs:
> and one for resources (the structure under which is copied to the target
> classpath given the default resource definition).
>
thus, by using it, we don't need to require the user to specify additional
resources configuration
> The choice of the term "schemas" for the directory name was intentional.
> Schema is a generic term and has been used longer than the invention of
> *.xsd files. Both *.xsd and *.dtd are based on the original concepts
> founded in database 'schemas'. The *.xsb files are also artifacts that
> define a schema. A DTD is a data schema. A *.xsd file is a data schema and
> a captial S, Schema. The schema directory name here is meant in a more
> general sense. The Jaxme folks opted to call their directory \src\main\jaxme,
> but I thought that was too specific since you may have other schemas that
> are not used for jaxme but want them in the same, consistent place.
>
> So, I see the src/main/schema directory makes sense.
>
I can agree with that.
And realistically, we are talking about the DEFAULT -- since they can always
override it.
Mal