Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Virtual API progress

Some comments on the comments ... most of all, thanks for providing these notes so we can all stay in the loop.

Am I reading this right ... "module" is becoming "component" .... guess everyone's discussed alternatives and could think of anything better, but 'component' is already heavily used in Eclipse, and we would then even be in the position of having a component named 'component'! ... I'm sure we'll get years of fun explaining that to people.  :)

And also,  my  opinion on the use of  'common' component. I think of that as the component for things that do not really have to do with webtools per se. I do not believe its for "commonly used UI things and emf utilities" ... for a few reasons. One, "commonly used" by itself isn't enough to make it a WTP API, it has to be good too. Neither should it be used to solve pre-req problems (in the past, there's a trend to move things further and further down to solve pre-req problems, so everyone wanted their favorite things in 'common' but in reality, this just make for more unrelated dependancies) So ... if it is commonly used, and good enough to be API in WTP, why isn't it an API in base UI packages, or EMF packages?  Are there road blocks in moving things to their rightful home? If so, perhaps Architecture Group could help resolve?
(Feel free to bring issues to us if we can help resolve questions/issues).

[I don't feel strong where 'module' ends up . but just wanted to dispel the notion of putting little utilities in common.]


"Ted Bashor" <tbashor@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/01/2005 04:51 PM

Please respond to
"General discussion of project-wide or architectural issues."

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>, <wtp-dev@xxxxxxxxxxx>
RE: [wtp-dev] Virtual API progress

Some suggestions (based on various offline discussions):
1) Purge "module" from the plugin.  I know it will require a bunch of repackaging and documentation update, but it's pretty confusing to transition from ModuleCore to the "Component" type heirarchy.
2) Remove "common" from the package name?  I don't feel strongly about this one, but while you're doing the big refactor, maybe the root package should be "org.eclipse.wst.component"?  I understand using "common" to qualify shared ui widgets or emf utilities, but it doesn't seem necessary for navigator and component.
3) Create IComponent and IComponentType interfaces.  Move methods in ModuleCore like getComponentType(IVirtualContainer) into IComponent.  IComponent would probably be a subtype of IVirtualContainer.
4) Move the EMF impl classes to an "emf" subpackage.  The following organization seems reasonable to me:
            IVirtualContainer, etc.
A client can restrict itself to the top-level interfaces if it doesn't want or need to take an EMF dependency, but the EMF classes are available if you are developing an editing feature.
5) Add a path type object.  For example, instead of ModuleCore/IComponent.getSourceContainers(), the api would be something like IComponent.getVirtualContainers(IPathType)
Potential path types:  Java Source, Java Resource, Web Resource, EAR Resource, etc.
I'm not sure how includes/excludes filtering is intended to be handled.  Something modeled after the way the JDT does it, I would assume...
-----Original Message-----
wtp-dev-bounces@xxxxxxxxxxx on behalf of Michael Elder
Tue 3/29/2005 6:53 AM
Konstantin Komissarchik; Ted.bashor@xxxxxxx
[wtp-dev] Virtual API progress

Extended Team:

      We have been making progress on the proposal to expose a "Virtual
Path API" to allow clients to browse flexible project structures without

dealing directly with the underlying EMF models. We are beginning to lean

towards making the models wholly internal to allow us the freedom to make

changes in the next release of WTP if necessary. Are there any opinions out

there about this?

      The initial cut of the API is already available in CVS under the
modelcore plugin


We are targeting this weeks Integration Build to have the API tests in

places and most if not all of the javadoc. The one thing that hasn't yet

been addressed is how we intend to expose the Referenced Components

(formerly Dependent Workbench Modules) through the Virtual Path API. We

started by coping the IResource, IContainer, IFolder, and IFile, and then

pruning those down to methods that deal with navigation. The javadoc is not

yet ready, so any docs that are there are left over from Eclipse Platform.

We also added methods that were more specific that we thought would be

helpful: getWorkspaceRelativePath(), getProjectRelativePath() [as in

Platform], getRuntimePath(), getRealFile(s)/Folder(s)(), and


      We are also considering changing our use of the EMF URI object to use
the more Eclipse-friendly IPath object to model path structures within the

model. By making the models internal, we allow ourselves the opportunity to

make this change at a later time (e.g. R1.1), but are considering making

this change as quickly as this Friday. Any thoughts?

Kind Regards,

Michael D. Elder
Rational Studio / J2EE Tools Development


Ext: (919) 543-8356

T/L:  441-8356


wtp-dev mailing list

wtp-dev@xxxxxxxxxxx _______________________________________________
wtp-dev mailing list

Back to the top