[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [pde-dev] Extending the PDE
|
Hi Wassim,
-----Original Message-----
From: pde-dev-bounces@xxxxxxxxxxx [mailto:pde-dev-bounces@xxxxxxxxxxx]
On Behalf Of Wassim Melhem
Sent: Wednesday, August 01, 2007 9:23 AM
To: Eclipse PDE general developers list.
Subject: RE: [pde-dev] Extending the PDE
Hi Scott,
Requests that enumerate a generic and long list of things and asks for
them to be made public are typically scary.
I didn't really think this was a generic and long list of things
(although perhaps a long list of imports)...but sorry to scare you :)
Once you factor in the return types of methods in these classes and
internal types in the signatures of these methods, then the whole world
of PDE would have to become API and it would take years to do that.
I'm not asking for the whole world of PDE, rather just the ability to
have other plugins get access to and manipulate the target runtime
*model*.
And we wouldn't even know why we are doing it.
The main reason is that we would like to provide tooling that depends
upon a specific/other target runtime (OSGI-based server). Further, to
ease the burden on the developer/user we want to manipulate/set the
target platform programmatically rather than have them do it via UI.
This is for a specific, new product:
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/webl
ogic/event_server/
It is always better to provide context for what you are trying to
accomplish and let us figure out what we need to expose and how much.
I trust your judgment, but OTOH I do know what I need here and why, and
know enough about PDE to understand what it's not doing. What we need
is programmatic access to the model for the target platform. What we
*will likely need* is further access to PDE functions that are currently
only exposed via PDE UI, because we would like to explore creating
additional environment-specific tooling that the PDE cannot/will not
expose (not meant to scare, only to thrill ;).
For example, TPTP once asked for tens of classes or so to be made API,
and once we understood what they wanted, we exposed a single class
(PluginRegistry) which satisfied their request.
Great, something like that would be terrific. I can just restate the
API need here as: we need to get and set the target runtime
programmatically. It would be very cumbersome to do something like
manually create a .target file and then read it in.
For the target platform request, perhaps you could add your thoughts to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169340 and we will examine
it once 3.4 API work gets under way.
OK, will add these/some other comments to that bug, thanks.
In PDE, we do have a "no developer left behind" policy and we will look
forward to accomodating (reasonable) requests that would make your life
easier.
:-) Thanks. I like to think I'm typically a 'reasonable man'. RE: 'no
developer left behind'...my expectation is that your interpretation is
different from the govt policy of similar name ;-(.
Also, I will be at the Equinox provisioning workshop and we can talk
there in detail about this, if you like.
Thanks Wassim...looking forward to meeting you in person.
Scott
Thank you for choosing PDE,
Wassim
"Scott Lewis"
<slewis@xxxxxxx>
Sent by:
To
pde-dev-bounces@e "Eclipse PDE general developers
clipse.org list." <pde-dev@xxxxxxxxxxx>
cc
08/01/2007 12:00
Subject
PM RE: [pde-dev] Extending the PDE
Please respond to
"Eclipse PDE
general
developers list."
<pde-dev@eclipse.
org>
I have another request along this line...
We have a need to be able to manipulate the target platform
programmatically. I've been able to do this in eclipse 3.2 by using
these internal classes/interfaces:
org.eclipse.pde.internal.core.ExternalModelManager;
org.eclipse.pde.internal.core.ICoreConstants;
org.eclipse.pde.internal.core.PDECore;
org.eclipse.pde.internal.core.PDEState;
org.eclipse.pde.internal.core.itarget.IAdditionalLocation;
org.eclipse.pde.internal.core.itarget.ILocationInfo;
org.eclipse.pde.internal.core.itarget.ITarget;
org.eclipse.pde.internal.core.itarget.ITargetModel;
org.eclipse.pde.internal.core.target.TargetModel;
org.eclipse.pde.internal.core.ifeature.IFeature;
org.eclipse.pde.internal.core.ifeature.IFeatureChild;
org.eclipse.pde.internal.core.ifeature.IFeatureModel;
org.eclipse.pde.internal.core.ifeature.IFeaturePlugin;
org.eclipse.pde.internal.core.itarget.ITarget;
org.eclipse.pde.internal.core.itarget.ITargetFeature;
org.eclipse.pde.internal.core.itarget.ITargetPlugin;
This is not all of them, but rather a sampling. It's been necessary to
use these internal model interfaces and classes to get/set the target
platform.
Is there a chance that these interfaces and classes (everything having
to do with the actual model of the target platform) could/would be
exposed as API so that other plugins could get access to them without
using internal packages? I haven't had a chance to consult 3.3 APIs in
this respect so maybe it already has...I will look.
But assuming not in 3.3...any plans to expose some of this so other
tools can use the target platform?
Thanks,
Scott
-----Original Message-----
From: pde-dev-bounces@xxxxxxxxxxx [mailto:pde-dev-bounces@xxxxxxxxxxx]
On Behalf Of Fabio Mancinelli
Sent: Wednesday, August 01, 2007 5:46 AM
To: Eclipse PDE general developers list.
Subject: Re: [pde-dev] Extending the PDE
On Aug 1, 2007, at 2:08 PM, Fabio Mancinelli wrote:
>
> Could anyone give me some hints on where to look in the
> documentation/source code/etc. for starting to build my extension?
>
I reply to myself because I've probably found what I was looking for...
It's the PluginRegistry class in org.eclipse.pde.core.plugin
Maybe this could be useful to somebody else.
Cheers,
Fabio
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
