Fluent API plugin misses some methods when building with JAXB episodes

[UnasZole]

Use case is the following :

• An XSD type, let's call it Type1, is defined.
• Another type, Type2, is defined as en extension of Type1.
• Type1 is built by itself, first, using fluent API, and with JAXB episode generation enabled.
• Then we try to build Type2 in another step, still using fluent API, and providing the episode file generated before.

When doing this, Type2 will be missing all the with___ methods related to the setters of Type1; which it gets correctly if everything is generated in a single step.

[UnasZole]

My understanding is the following :

In FluentApiPlugin.java, line 140, we navigate to the super class to be able to handle its setters as well.
However, the javadoc for xjc ClassOutline specifies that the getSuperClass method, used by this plugin, may return null if the super class is not JAXB-bound.
I'm not sure what "JAXB-bound" specifically means in this context, but I guess that if the parent class was resolved by episode, it probably isn't opened in XJC's context and we get null.

Does this analysis seem correct ?
And if so, any idea about fixing the issue ?

[UnasZole]

Looking more specifically at the XJC implementation, it looks like the issue is slightly different from my previous analysis.

When fetching the ClassOutline of a super class which is not in the compilation yet, it is generated using the following method :
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.xml.bind/jaxb-xjc/2.0/com/sun/tools/xjc/generator/bean/BeanGenerator.java#370

This shows that when a type is bound to a user-specified class (as is the case when building with episodes), a new dummy, empty, hidden JDefinedClass is instantiated to represent that type.

So getSuperClass is not returning null; it's returning a dummy empty class, hence why we don't read any setter from it.

I don't think it's actually fixable from inside this plugin's code though : any solution to that issue would probably require :

• Passing the pre-compiled .java or .class files to XJC, along with the episode
• Implement in XJC the ability to create a detailed JDefinedClass from these files, rather than a dummy empty one.

So I guess you could close this ticket as wontfix... I'm still open to any suggestion for this issue though.