I second Ted on point 1) and 3)
----------------------------------------------------
Usha Kuntamukkala
Technical Lead
Weblogic Integration IDE
BEA Systems Inc
ukuntamu@xxxxxxx
408 570 8564
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ted Bashor
Sent: Friday, April 01, 2005 1:52
PM
To: General discussion of
project-wide or architectural issues.; wtp-dev@xxxxxxxxxxx
Subject: 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:
org.eclipse.wst.component
org.eclipse.wst.component.emf
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-----
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
