Hi John,
Thanks for the hints. We will try this approach too.
Greetings,
kaloyan
From: pde-dev-bounces@xxxxxxxxxxx [mailto:pde-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: 02 март 2012 г. 23:37 ч.
To: Eclipse PDE general developers list.
Subject: 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
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
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
