[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-dev] Virtual API progress
|
Thanks Ted,
my responses are below...
- Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
"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." |
|
|
To
| "General discussion
of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>,
<wtp-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
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.
<cdb>Agreed - we can bite the bullet and do it 100%
now....</cdb>
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.
<cdb>I agree - BUT this breaks our naming guidelines
to always include the component name in the package. - If enough people
agree this is ok, we can go with it.</cdb>
3) Create IComponent and IComponentType interfaces.
Move methods in ModuleCore like getComponentType(IVirtualContainer)
into IComponent. IComponent would probably be a subtype of IVirtualContainer.
<cdb>Agreed - After talking to Michael,
it makes sense to have a more concrete "type" based container.</cdb>
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.
<cdb> - These interfaces already have
seperate packages - If you mean spliting plugins, I think that is overkill,
but we can create two runtime jars within the plugin that has this split.
</cdb>
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.
<cdb>This may be out of scope for this
release, but a useful feature to help scope file searches</cdb>
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...
<cdb> Api needs work here, I know we
suggested supporting regular expressions, and the model will currently
support this, but details are needed</cdb>
-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
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
