cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject cxf-codegen-plugin and directory scanning....
Date Mon, 02 Nov 2009 15:38:57 GMT

A while ago, a feature was added to the cxf-codegen-plugin to automatically 
scan the directory and run wsdl2java on all the wsdl's there instead of 
explicitly having to configure wsdlOptions for every wsdl .    This was  a 
feature request and certainly helped us.   The pom for our testutils shrunk a 
LOT as we were able to autoscan all 40+  test wsdls and not configure each of 
them.   It also is designed to more "mimic" the standard Maven plugins that 
run over everything they find in directories.   (like resources, compiler, 
javadoc, etc....)    Convention over configuration.   

The PROBLEM is that this is causing issues for users.   Several times in the 
last couple months, we've hit issues with JAXB or wsdl2java or similar that 
are caused by the plugin running wsdl2java on wsdl's that they shouldn't be 
and overwriting stuff generated from the wsdls that it SHOULD run on.

Thus, I think something needs to be done about this, just not sure what.

The easiest is to just add an "autoScanDirectory" option to the plugin to turn 
on/off the behavior.   I'm just not sure what the default should be.   "true" 
to match current behavior, or "false" to reduce issues?

The other thing I think we should do is if there are wsdlOptions configured, 
process those WITHOUT configuration first, then those with configuration.  
Thus, the configured stuff would overwrite any non-configured things.   

The OTHER way to do it, which would require a LOT more work, would be to 
process the configured stuff first, but add hooks into the wsdl loading to 
record any wsdl's that are included from those and then remove those from the 
auto scan.   That's quite a bit more complex, and I don't really think 
completely solves the problem.  Other wsdl's NOT included could also use the 
same namespaces or similar and overwrite ObjectFactories and such.

Thoughts?  Other ideas?

Daniel Kulp

View raw message