pde-dev

Re: [pde-dev] DS annotation builder plug-in for the PDE

gerd@xxxxxxx (Gerd Wütherich) — Tue, 17 Apr 2012 11:05:43 GMT

Hi Curtis, hi John,

I entered a bug against PDE (https://bugs.eclipse.org/bugs/show_bug.cgi?id=376950). The source is available at GitHub (https://github.com/wuetherich/ds-annotation-builder).

Becoming a PDE committer to help maintain the code would be fine.

Regards,
Gerd

2012/4/13 John Arthorne <John_Arthorne@xxxxxxxxxx>

Gerd, so it doesn't get lost, I suggest entering a bug report against PDE and supplying the source code as an attachment. Would you be interested in becoming a PDE committer to help maintain the code after it is contributed?

John

Curtis Windatt/Ottawa/IBM@IBMCA
Sent by: pde-dev-bounces@xxxxxxxxxxx
04/13/2012 11:55 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] DS annotation builder plug-in for the PDE

Hi Gerd,

The plug-in does look like a valuable extension for PDE. The only issue is the limited amount of committer time available to review the fix and maintain it in future releases.

The feasibility of this should be discussed after 4.2 is released.

Curtis Windatt

From: Gerd Wütherich <gerd@xxxxxxxxxxxxxxxxxx>
To: pde-dev@xxxxxxxxxxx,
Date: 2012/04/13 04:33 AM
Subject: [pde-dev] DS annotation builder plug-in for the PDE
Sent by: pde-dev-bounces@xxxxxxxxxxx

Hi,

as you may know, the upcoming OSGi R5 specification (http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf) contains a set of Declarative Services Annotations that can be used to generate the component description at build time. This approach significantly simplifies the development of service components. To support this approach in the PDE, I recently implemented a PDE annotation builder plugin (see http://drupal.gerd-wuetherich.de/pde-annotation-builder-en.html), based on some work Nils Hartmann and Frank Schlüter did before. This plugin provides a custom builder that generates component descriptions by traversing the ASTs of all source files that are contained in a PDE project.

The plugin works quit nice, and from my POV it would be a valuable extension for the PDE. So my question is if there is any interest/possibility to contibute the plugin the PDE project? It already is open source and licensed under the EPL (Git-Repository: https://github.com/wuetherich/ds-annotation-builder).

Regards,
Gerd Wütherich _______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev

_______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/pde-dev

_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev

Re: [pde-dev] DS annotation builder plug-in for the PDE

John_Arthorne@xxxxxxx (John Arthorne) — Fri, 13 Apr 2012 17:49:51 GMT

Gerd, so it doesn't get lost, I suggest entering a bug report against PDE and supplying the source code as an attachment. Would you be interested in becoming a PDE committer to help maintain the code after it is contributed?

John

Curtis Windatt/Ottawa/IBM@IBMCA
Sent by: pde-dev-bounces@xxxxxxxxxxx

04/13/2012 11:55 AM

Please respond to
"Eclipse PDE general developers list."

To	"Eclipse PDE general developers list."
cc
Subject	Re: [pde-dev] DS annotation builder plug-in for the PDE

Hi Gerd,

The plug-in does look like a valuable extension for PDE. The only issue is the limited amount of committer time available to review the fix and maintain it in future releases.

The feasibility of this should be discussed after 4.2 is released.

Curtis Windatt

From:	Gerd Wütherich
To:	pde-dev@xxxxxxxxxxx,
Date:	2012/04/13 04:33 AM
Subject:	[pde-dev] DS annotation builder plug-in for the PDE
Sent by:	pde-dev-bounces@xxxxxxxxxxx

Hi,

as you may know, the upcoming OSGi R5 specification (http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf) contains a set of Declarative Services Annotations that can be used to generate the component description at build time. This approach significantly simplifies the development of service components. To support this approach in the PDE, I recently implemented a PDE annotation builder plugin (see http://drupal.gerd-wuetherich.de/pde-annotation-builder-en.html), based on some work Nils Hartmann and Frank Schlüter did before. This plugin provides a custom builder that generates component descriptions by traversing the ASTs of all source files that are contained in a PDE project.

The plugin works quit nice, and from my POV it would be a valuable extension for the PDE. So my question is if there is any interest/possibility to contibute the plugin the PDE project? It already is open source and licensed under the EPL (Git-Repository: https://github.com/wuetherich/ds-annotation-builder).

Regards,
Gerd Wütherich _______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev

_______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/pde-dev

Re: [pde-dev] DS annotation builder plug-in for the PDE

Curtis_Windatt@xxxxxxx (Curtis Windatt) — Fri, 13 Apr 2012 15:56:06 GMT

From:	Gerd Wütherich
To:	pde-dev@xxxxxxxxxxx,
Date:	2012/04/13 04:33 AM
Subject:	[pde-dev] DS annotation builder plug-in for the PDE
Sent by:	pde-dev-bounces@xxxxxxxxxxx

Hi,

as you may know, the upcoming OSGi R5 specification (http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf) contains a set of Declarative Services Annotations that can be used to generate the component description at build time. This approach significantly simplifies the development of service components. To support this approach in the PDE, I recently implemented a PDE annotation builder plugin (see http://drupal.gerd-wuetherich.de/pde-annotation-builder-en.html), based on some work Nils Hartmann and Frank Schlüter did before. This plugin provides a custom builder that generates component descriptions by traversing the ASTs of all source files that are contained in a PDE project.

The plugin works quit nice, and from my POV it would be a valuable extension for the PDE. So my question is if there is any interest/possibility to contibute the plugin the PDE project? It already is open source and licensed under the EPL (Git-Repository: https://github.com/wuetherich/ds-annotation-builder).

Regards,
Gerd Wütherich
_______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/pde-dev

[pde-dev] DS annotation builder plug-in for the PDE

gerd@xxxxxxx (Gerd Wütherich) — Fri, 13 Apr 2012 09:32:44 GMT

Hi,

as you may know, the upcoming OSGi R5 specification (http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf) contains a set of Declarative Services Annotations that can be used to generate the component description at build time. This approach significantly simplifies the development of service components. To support this approach in the PDE, I recently implemented a PDE annotation builder plugin (see http://drupal.gerd-wuetherich.de/pde-annotation-builder-en.html), based on some work Nils Hartmann and Frank Schlüter did before. This plugin provides a custom builder that generates component descriptions by traversing the ASTs of all source files that are contained in a PDE project.

The plugin works quit nice, and from my POV it would be a valuable extension for the PDE. So my question is if there is any interest/possibility to contibute the plugin the PDE project? It already is open source and licensed under the EPL (Git-Repository: https://github.com/wuetherich/ds-annotation-builder).

Regards,

Gerd Wütherich

[pde-dev] Running JUnit tests remotely

yonadav@xxxxxxx (Yonadav Leitersdorf) — Tue, 27 Mar 2012 17:03:58 GMT

Hi All,

I've been looking for a way to run JUnit tests remotely, but keeping the same experience in Eclipse (the JUnit View, the support for debugging, breakpoints, etc.). My search led me to believe no such solution exists. So, I'm taking up the desire to add support for this type of behavior to the existing JUnit plug-in. Generally, the idea would be to allow a user to provide the details of a remote server on which the JUnit tests should be run. The plug-in will:

1. rsync the required files to the remote server.

2. Run the required java process on the remote server to have the tests run.

3. Connect the local Eclipse to the remote java process.

This poses some requirements on the remote server (what's installed, etc.) but I believe it could be quite useful.

If you guys agree, I'd appreciate pointers on where to start with this.

Thanks!

Yoni

[pde-dev] RFC: Supporting PDE/Equinox bundles in Eclipse IDE

miles.parker@xxxxxxx (Miles Parker) — Mon, 12 Mar 2012 20:42:45 GMT

Hi everyone,

I'm asking for comments/feedback on different approaches to providing decent support for PDE in Virgo tooling. Please see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198#c11
Sorry for the length, I think my final proposal is actually pretty straightforward, but I wanted to try and cover all of the major options so as not to leave any ideas off the table.

[I'm cc'ing PDE because I'm really interested in your feedback re: best approaches based on experience with developing tooling for that.)

Please followup in the bug.

cheers,

Miles
______________________________
Miles T. Parker
Senior Engineer and Product Manager, Tasktop
http://tasktop.com
Committer, Eclipse Mylyn and Virgo
Project Lead, Model Focussing Tools and AMP
http://milesparker.blogspot.com

Re: [pde-dev] Changes in API in Juno

kaloyan.raev@xxxxxxx (Raev, Kaloyan) — Tue, 06 Mar 2012 10:42:47 GMT

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

"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
To:	"Eclipse PDE general developers list." ,
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"
To:	"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

Re: [pde-dev] Changes in API in Juno

John_Arthorne@xxxxxxx (John Arthorne) — Fri, 02 Mar 2012 21:38:06 GMT

"Raev, Kaloyan"
Sent by: pde-dev-bounces@xxxxxxxxxxx

02/29/2012 12:19 PM

Please respond to
"Eclipse PDE general developers list."

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

"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

From:	Curtis Windatt
To:	"Eclipse PDE general developers list." ,
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"
To:	"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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/pde-dev

Re: [pde-dev] Changes in API in Juno

igor@xxxxxxx (Igor Fedorenko) — Thu, 01 Mar 2012 14:26:35 GMT

We had a similar problem with one of our products when P2 changed
all/most of their package names in 3.6. Our solution was to introduce
p2-frontend interfaces which completely hid p2 interactions from the
rest of our codebase and then we provided two separate implementation of
the p2 frontend, one for 3.5 and another for 3.6. This was the time when
I really wished PDE had per-project target platform ;-).

--
Regards,
Igor

On 12-02-29 12:19 PM, Raev, Kaloyan wrote:

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" mailto:dimitar.giormov@xxxxxxx>>*
Sent by: pde-dev-bounces@xxxxxxxxxxx <mailto:pde-dev-bounces@xxxxxxxxxxx>

02/28/2012 04:04 AM

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

To

"Eclipse PDE general developers list." mailto: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>
[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

To:

"Eclipse PDE general developers list." ,

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"

To:

"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 <mailto:pde-dev@xxxxxxxxxxx>_
_https://dev.eclipse.org/mailman/listinfo/pde-dev

_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx <mailto:pde-dev@xxxxxxxxxxx>_
_https://dev.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx <mailto: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

Re: [pde-dev] Changes in API in Juno

kaloyan.raev@xxxxxxx (Raev, Kaloyan) — Wed, 29 Feb 2012 17:20:02 GMT

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

From:	Curtis Windatt
To:	"Eclipse PDE general developers list." ,
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"
To:	"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

From:	Gerd Wütherich <gerd@xxxxxxxxxxxxxxxxxx>
To:	pde-dev@xxxxxxxxxxx,
Date:	2012/04/13 04:33 AM
Subject:	[pde-dev] DS annotation builder plug-in for the PDE
Sent by:	pde-dev-bounces@xxxxxxxxxxx