users@jaxb.java.net

supressing class generation with xjc

From: Jerry Lacy <jlacy_at_ssglimited.com>
Date: Thu, 3 Feb 2005 07:41:44 -0600

Hello,

 

Is there any way to make the xjc compiler forgo the generation of JAXB
classes for elements defined in a particular namespace/package?

 

I am creating a framework which uses JAXB to process XML configuration
files. Within the framework, there is a schema and namespace defined to
support the basic configuration types used within the framework. Typically
the user of this framework will need to define additional configuration
elements specific to that project (although this is not always the case).
If the user defines a project specific schema and namespace, those
definitions will typically include or extend (using extension or
substitutionGroup) those in the framework schema/namespace.

 

The problem I am having has to do with packaging the framework for
distribution. Ideally, I would compile the framework schemas and include
the resulting JAXB classes into my framework.jar distribution. The user of
the framework would then define the project specific namespace and schema
(which would <include> the framework schema) and compile it into their
project using xjc without having xjc regenerate all of the framework JAXB
classes (since they already are present in framework.jar). I do not see a
way to accomplish this since, when the user executes xjc to compile the
project specific schema, xjc will regenerate the framework JAXB objects as
well.

 

I am really just trying to avoid multiple instances of the framework JAXB
class definitions within the user's project classpath. Currently, the only
option seems to be to distribute the JAXB classes in a separate
frameworkConfig.jar and instruct the user to not include that .jar if they
require customizations which necessitate the definition of a project
specific schema and subsequent xjc compilation. (This really isn't the best
solution because, in reality, the situation is somewhat more complex than I
have described.the framework actually consists of multiple "modules", each
with their own namespaces, which build upon each other and are versioned
somewhat independently of each other.)

 

Thanks in advance,

 

Jerry