[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-dev] Virtual API progress [Changes released -- full sync required]
|
The term "Module" was purged from the API and model. The plugin has not yet
been renamed (will be coordinated for this week's IB.
I've introduced a new interface for the Virtual Path API:
IVirtualComponent. Instead of an IComponentType, the metadata for a component is
exposed through methods in IVirtualComponent: getProperties(),
get/setComponentTypeId(), and get/setVersion(). JUnit tests for these methods
are on the way.
The "type" for resources hasn't been introduced yet, but will be soon.
Also, the URI-based paths for WorkbenchComponent.runtimePath,sourcePath and
ReferencedComponent.runtimePath have been converted to IPath.
For anyone that already has dependencies on the API, please exercise your
tests to confirm if there were unexpected defects introduced with the rename.
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools
Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Saturday, April 02, 2005 3:26 PM
To: "General discussion of
project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc:
From: Chuck Bridgham/Raleigh/IBM@IBMUS
Subject: 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