[wtp-dev] ArtifactEdits, Java EE 5, old code, and new code

[Carl Anderson <ccc@xxxxxxxxxx>]

Folks,

      I am hesitant to write this note, but since Chuck is not available,
and since there is quite a clamor about this, I thought I had better
explain the state of things for Java EE support in WTP 2.0.  (But I will
leave Chuck the ability and right to clarify and or expound upon what I say
here, when he returns.)
      First, we have always said that we would not be extending the
previous J2EE 1.2 to 1.4 models and infrastructure to support Java EE 5 -
there are just too many changes between J2EE 1.4 and Java EE 5, and there
are quite a few drawbacks to our current models and infrastructure that we
are hoping to overcome by providing some new layers to the Java EE code in
WTP.
      Now, a brief review of our changes over the last few weeks:

      We added in the ability to create the various Java EE 5
projects/modules/components, and there was much rejoicing in the land.
      We added in the ability to run a Servlet 2.5 module on a server (such
as Tomcat 6), and there was much rejoicing in the land.
      We added in the Java EE 5 models, and there was much rejoicing in the
land.
      We added in a check in ArtifactEdit to see if it is being created on
a validProjectVersion(), which throws an IllegalArgumentException
(especially for ArtifactEdits created on Java EE 5 modules).  This
exception is caught (and ignored) in almost every
getXXXArtifactEditForRead/Write() method, which then returns NULL.  So,
just when a lot of coders (improperly) thought that they could now get
WebArtifactEdits for Dynamic Web Projects with a facet version of 2.5, they
suddenly get NULL back (and open a Bugzilla about a NullPointerException in
their code).  Also note that this change should only effect the J2EE-type
ArtifactEdits... other ArtifactEdits such as WSDDArtifactEdit should work
on Java EE 5 modules as well as J2EE modules.
      And now, we added in org.eclipse.jst.j2ee.model.ModelProviderManager.
If a coder passes in an IProject, he will get back an IModelProvider.  In
the case of J2EE 1.2-1.4 projects, the IModelProvider is the appropriate
ArtifactEdit.  (If you want, you can cast it to the appropriate
ArtifactEdit subclass and utilize it as before.)  In the case of Java EE 5,
new IModelProviders are being fleshed out (only a basic skeleton is there
at the moment).
      For our next trick, we hope to flesh out the new IModelProviders, add
some helper classes, and perhaps even adding another layer to ease access
to the stuff harbored within a Java EE 5 project.  (But I am extremely
leery of making any such announcement.... watch this space for details.)
      Then we will declare that that is as much Java EE 5 support as we can
put into WTP 2.0.

      Now, please note (esp. David Williams) that we are NOT changing any
of the current API.  Any code that is written to use ArtifactEdits and
their getXXXArtifactEditForRead/Write() methods (or any other
public/protected method) will still work as before.  No adopters should be
broken by any of these changes, since the current API is not changing and
still works the same.  However, if you want your code to work for both J2EE
1.2-1.4 and Java EE 5, you should change your code over to ask the
ModelProviderManager for the IModelProvider, and access the model from it.
(Since trying to create a new ArtifactEdit will throw an exception, and
asking for one for read or write will return NULL.)

Questions? Comments? Send them this way.  (Or bring them up at the JEE 5
call.)

Sincerely,

- Carl Anderson
WTP programmer