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:
org.eclipse.wst.component
IComponent
IComponentType
IVirtualContainer, etc.
org.eclipse.wst.component.emf
WorkbenchComponent
ComponentType
VirtualContainer
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...
-Ted
-----Original Message----- From:
wtp-dev-bounces@xxxxxxxxxxx on behalf of Michael Elder
Sent: Tue 3/29/2005 6:53 AM To: wtp-dev@xxxxxxxxxxx
Cc: Konstantin Komissarchik; Ted.bashor@xxxxxxx Subject:
[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 (wst/components/org.eclipse.wst.common.modulecore/modulecore-src/org.eclipse.wst.common.modulecore.internal.resources).
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
getComponentName().
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 IBM RTP Lab Ext: (919) 543-8356 T/L: 441-8356
mdelder@xxxxxxxxxx
_______________________________________________
wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev
|