Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Request for Feedback for ModuleCore/Flex Project API


I just wanted to voice support for "hiding EMF" ... which if I understand it, is part of the goal of this effort ... clients should not have to understand details of how models are implemented ... just what its model interface is.

Obviously, the violation of base API is a "show stopper", in the sense we can't expose API that violate base APIs, but this effort deserves exploring with base team for appropriate long term, correctly architected solution.

David




Michael Elder/Cambridge/IBM@IBMUS
Sent by: wtp-dev-admin@xxxxxxxxxxx

03/23/2005 11:41 AM

Please respond to
wtp-dev

To
wtp-dev@xxxxxxxxxxx
cc
John Arthorne <John_Arthorne@xxxxxxxxxx>
Subject
RE: [wtp-dev] Request for Feedback for ModuleCore/Flex Project API





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
 
 
 
Wednesday, March 23, 2005 11:22 AM
To: <wtp-dev@xxxxxxxxxxx>
cc:
From: "Ed Burnette" <Ed.Burnette@xxxxxxx>
Subject: RE: [wtp-dev] Request for Feedback for ModuleCore/Flex Project API


CDT used to implement IResource and it caused them a lot of grief when Eclipse 3.0, I believe it was, changed IResource and broke their code at the binary level. The API restriction can't be lifted. According to jeem, Java interfaces should not be implemented by clients in different components, and this is the reason you see a lot of abstract classes in the Eclipse API now. Abstract classes can be extended and if a later release adds a new non-abstract method it won't break existing extenders. Of course you can only have single inheritance with classes. Adapters are often a good solution too.
 


From: wtp-dev-admin@xxxxxxxxxxx [mailto:wtp-dev-admin@xxxxxxxxxxx] On Behalf Of Michael Valenta
Sent:
Wednesday, March 23, 2005 11:04 AM
To:
wtp-dev@xxxxxxxxxxx
Subject:
Re: [wtp-dev] Request for Feedback for ModuleCore/Flex Project API



Michael,


From your description, it looks like you are proposing to provide alternate implementations of IResource and it's subclasses. Is this what you are intending to do? The javadoc of IResource clearly states that it cannot be implemented by clients. I think you will need to define your own interfaces and not make use of IResource. I guess another alternative would be to push to have the API restriction changed. I can't comment of the probablity of this happening at some point but I can say that it will not happen for 3.1 since the API freeze is next week.


Michael


Back to the top