Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

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.

And we wouldn't even know why we are doing it.

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.

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.

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.

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.

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




Back to the top