Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-dev] Changes in API in Juno

A bundle fragment can contribute additional classes and even packages to some host bundle. At runtime those classes/packages will appear to be part of the host bundle (org.eclipse.pde.ui in this case). We have used this in a few cases in the platform to support deprecated or removed content for backwards compatibility. For example org.eclipse.core.runtime.compatibility adds some packages to org.eclipse.core.runtime to support some old API that was "removed" from the runtime bundle in Eclipse 3.0. I haven't looked at this particular PDE API in detail so I'm not sure how easy it will to do here.

John




"Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
Sent by: pde-dev-bounces@xxxxxxxxxxx

02/29/2012 12:19 PM

Please respond to
"Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>

To
"Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
cc
Subject
Re: [pde-dev] Changes in API in Juno





Hi John,
 
Thank you for discussing this. We are willing to try to solve this on our adopter’s side. Our product is an Add-On, therefore patching PDE is not the best approach. The other one “via a fragment on the PDE bundle” looks quite interesting. Could you give more details?
 
Thanks,
Kaloyan
 
From: pde-dev-bounces@xxxxxxxxxxx [mailto:pde-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent:
29 февруари 2012 г. 18:32 ч.
To:
Eclipse PDE general developers list.
Subject:
Re: [pde-dev] Changes in API in Juno

 
We had a discussion about this today in the Eclipse PMC call [1]. We have great sympathy for this use case, and in the past we have helped adopters by leaving some very targeted bridging code or other techniques to ease compatibility. However we agreed that in this case we should not do it. This is entire packages of code rather than an isolated change, and there is a lot of work to get this right and to ensure both copies of the code continue to function properly. PDE is currently *very* short on committer resources and can't take on this work without sacrificing other areas. There are other approaches you could try in your product such as patching yourself or possibly via a fragment on the PDE bundle.

John


[1]
http://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes



"Giormov, Dimitar" <dimitar.giormov@xxxxxxx>
Sent by:
pde-dev-bounces@xxxxxxxxxxx

02/28/2012 04:04 AM


Please respond to
"Eclipse PDE general developers list." <
pde-dev@xxxxxxxxxxx>


To
"Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
cc
Subject
Re: [pde-dev] Changes in API in Juno

 







We mostly use:

 
org.eclipse.pde.internal.core.target.LocalTargetHandle
;

org.eclipse.pde.internal.core.target.ProfileBundleContainer
;

org.eclipse.pde.internal.core.target.WorkspaceFileTargetHandle
;

org.eclipse.pde.internal.core.target.provisional.IBundleContainer
;

org.eclipse.pde.internal.core.target.provisional.ITargetDefinition
;

org.eclipse.pde.internal.core.target.provisional.ITargetHandle
;

org.eclipse.pde.internal.core.target.provisional.ITargetPlatformService
;

 
Let me clarify as well, I never mentioned that the classes are in the PDE API. I know that we cannot rely on the internal classes. But since the classes are frequently used by adopters, for me leaving them as deprecated for a year (if possible) is a logical thing to do.

 
Best regards,

Dimitar

From:
pde-dev-bounces@xxxxxxxxxxx [mailto:pde-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Megert
Sent:
Monday, February 27, 2012 18:26
To:
Eclipse PDE general developers list.
Subject:
Re: [pde-dev] Changes in API in Juno

 

Just to clarify: the PDE API did not change. Anything in internal packages can change at any day. For details see
http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html.

Dani

From: Curtis Windatt <Curtis_Windatt@xxxxxxxxxx>
To: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Date: 27.02.2012 17:20
Subject: Re: [pde-dev] Changes in API in Juno


 


 






Hi Dimitar,


What classes are you using from those packages? It is unlikely that we will replace the internal classes assuming the same tasks can be accomplished using the official API.


Curtis

From: "Giormov, Dimitar" <dimitar.giormov@xxxxxxx>
To: "pde-dev@xxxxxxxxxxx" <pde-dev@xxxxxxxxxxx>,
Date: 2012/02/27 10:09 AM
Subject: [pde-dev] Changes in API in Juno
Sent by: pde-dev-bounces@xxxxxxxxxxx


 


 






Hi,


We are trying to adopt Juno for our product so we can assure that everything works. Unfortunately we stumbled upon an change in the packages of the PDE that we use a lot.

These are:
org.eclipse.pde.internal.core.target packages.  Which have become an API so the “internal” from the package is now removed. However this puts us in a situation where we have to start maintain 2 separate versions of our product one for Indigo and one for Juno.  (and this is the only thing that we use and is different between the 2 versions).

So my question would be: Is it possible that we get the packages back and set them to deprecated for Juno release and remove them in the next release?


Best regards,

Dimitar

_______________________________________________
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
_______________________________________________
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


Back to the top