[wtp-dev] RE: Request for Feedback for ModuleCore/Flex Project API

["Todd Williams" <todd@xxxxxxxxxxxx>]

Michael,

First, I applaud you for thinking of the end users of the API and attempting 
to abstract them away from any knowledge of EMF.  EMF was chosen as an 
appropriate and expedient implementation technology for the framework at 
this point in time, however, the impacts of its selection should certainly 
not percolate upward into the API layer simply because it might prove 
beneficial to swap out the underlying implementation for a new one in the 
future.  Naturally, such a technology upgrade cannot be API-affecting.

So, I strongly believe an abstraction layer like the one you're proposing is 
certainly mandated.  From your description, I like the IResource-based 
implementation because it explains the problem domain well and is 
immediately understandable by all Eclipse developers.  My only initial 
concerns are these:  1) Does the IResource-based mapping truly cover all 
edge cases in the flexible project domain, and 2) Will the platform team 
support such an implementation.  However, you seem to have both of these 
concerns already identified and are working to address them so I'll simply 
give you my support, and encourage you to let us know what you determine.

Best regards,
Todd
________________________
Todd E. Williams
VP - Technology
Genuitec, LLC
Office: 972-691-5717
Cell: 817-247-2034
mailto:todd@xxxxxxxxxxxx
http://www.genuitec.com

----------------------------------------------------------------------------------------------
Hi guys,

  We've begun discussing with Platform/Core what options are available to 
provide an API to solve these concerns. We are aware of other situations 
where API was exposed explicitly for a specific team (like 
IResource#setTeamPrivate()), and are curious as to whether this could be 
applied at a broader level.


  We like the idea of using IResource, IContainer, IFile, and IFolder so 
that clients will be able to readily begin using flexible project structures 
within WTP. Any method which is not directly relevant to us (e.g. 
IResource.setTeamPrivate()), we would delegate the invocation to the 
underlying IResource. Remember we're really just interested in representing 
arbitrary structures in forms that J2EE-spec tooling will understand.

  If we choose to go this route -- with the proper discussions and caveats 
understood, then we would prefer to extend an abstract class provided by 
Platform/Core..

  Another advantage to keep in mind is that using the Platform Resource API 
directly allows compatibility among the objects -- so that a developer 
wouldn't need continually convert from one object type to another just to 
read or write the contents of a file in the workspace.

  Also, all of our structural model is highly generic, with no J2EE 
dependencies. If at some point in the future, it becomes advantages to push 
down the ability to maintain flexible structures to a lower level component 
so that other teams could take advantage of the framework, it would be 
easier if we didn't have to push down a whole new set of API to solve the 
same problem.

-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx