JBossDeveloper

Right, I think you might be reading too much into my post.  It's not "wow, xjc does a great job" it's "wow, this is a pretty fluent API with a couple of caveats"  It fixes a few issues I have with the code.  First, I don't need a factory if I'm creating a new one; I can simply do Foo x = new Foo().  I can easily navigate the object structure.  I also don't end up with that inverse XML syntax with the generics.

I would be interested in seeing a hierarchical relationship between descriptor types.

E.g. WebAppDescriptor_3_0 extends WebAppDescriptor_2_5

Already done

Nice idea but I am not sure what this should solve. I see unpredictable behavour and a nightmare for testing.

What I would propose is something like a top level descriptor that returns a version based instance:

   final WebAppDescriptor descr = Descriptor.getInstance(DescriptorType.WebAppDescriptor, Version.7)

or

  final WebAppDescriptor descr = WebAppCreator.getInstance, Version.7)

Is that what you want to simplify? The several versions per descriptor type?

What I really want to simplify is use of the Descriptor for features that are backwards compatible. For instance... all Servlet specs allow addition of a filter. You shouldn't have to re-program that functionality for each spec version, but without inheritance (or shared interfaces) there is no way to effectively use OO polymorphism and re-use the code (without reflection, and that would be narsty)

I think it's the trade off between the code gen'd approach that the current descriptors take, and actually putting some code behind the descriptor implementations.

Personally, I'd much rather a simple pojo based approach for making these things, easier to understand conceptually.

Maybe a simple 'toplevel version less Marker interface' pr Descriptor could work, with a option to 'swap' between the different versions..

package org.shrinkwrap.descriptors.webapp;


public interface WebAppDescriptor { }


package org.shrinkwrap.descriptors.webapp.ee5;


public interface EE5WebAppDescriptor implements WebAppDescriptor { }


package org.shrinkwrap.descriptors.webapp.ee6;


public interface EE6WebAppDescriptor implements WebAppDescriptor { }




package org.someother.project;


/*
This method defines it require 'some' WebAppDescriptor to limit
it from just 'some' Descriptor, but the interface doesn't have to
define if it's a EE5 or EE6 descriptor.
*/
public void doDescriptorWork(Descriptor<WebAppDescriptor> desc) {


   /*
   we currently only support EE5, or we know (programmer knowlegde)
   that the EE5 methods we use will work on EE6 and EE7 as well.
   Lowest common denominator, even tho not enforced by API.
   
   Following similar rules as ShrinkWrap Archives. There is a underlying model
   and there is a View on top. I view this as a EE5 descriptor.
   */
   desc.as(EE5WebAppDescriptor.class).addServlet(...)

}

Inheritance, interfaces, whatever You know what I meant.

Something like this would probably be OK. But having a shared *interface* hierarchy would probably be ideal.

I assume that the that the 'extend' approach will lead to a growing descriptor instance, right?. The latest one will allow to set for example in case of a WebAppDescriptor filters for EE5, EE6 and EE7 correct?

Or do you intend somehow to 'merge' the potentially different class definition, e.g Filter class?

What I want to point out is that to discuss this on the top level Descriptor interface is too simplyfied (for me). Could you give an example how to deal with the nested classes referenced by the descriptors? Currently, we have a distinct version for each class and XSD version. This is actually the same issue we had with the mutual / non mutual view in SHRINKDESC-21, I believe.