Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Target 3.4 and 3.5 P2 APIs despite APi changes - fragments?
Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #48216] Wed, 25 February 2009 17:52 Go to next message
Chris Williams is currently offline Chris WilliamsFriend
Messages: 29
Registered: July 2009
Junior Member
We have our own alternate UI for installing features/plugins via P2. Under
the hood to achieve this we need to make use of provisional P2 APIs.
Between 3.4 and 3.5 these APIs have changed (for example moving to URIs
instead of URLs).

Is there a way to make our code compatible with both versions of the APIs
using fragments? Would we need our eclipse base for the build to contain
both 3.4 and 3.5 versions of the p2 plugins to do so?


Are there any examples out there of people using fragments to handle API
breakage like this?
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #48276 is a reply to message #48216] Wed, 25 February 2009 20:43 Go to previous messageGo to next message
Pascal Rapicault is currently offline Pascal RapicaultFriend
Messages: 333
Registered: July 2009
Location: Ottawa
Senior Member
> Is there a way to make our code compatible with both versions of the APIs
> using fragments? Would we need our eclipse base for the build to contain
> both 3.4 and 3.5 versions of the p2 plugins to do so?
Using the fragment idea, I think that what you are after should be
possible.
For example your UI bundle could have a fragment that encapsulates the
calls to p2 and is responsible for transforming the arguments accordingly
depending on the eclipse you are installed into. So you would have 3
bundles, your UI one and one fragment targeting p2 3.4 and one fragment
targeting p2 3.5.

As an aside I would be interested in understanding why you can't use
the p2 UI (3.4 or 3.5).

> Are there any examples out there of people using fragments to handle API
breakage like this?
The compatibility bundles you see in Eclipse are usually here for that,
except that they are fragments on the original bundles, whereas in your
case you want to adapt to different APIs based on your configuration.

PaScaL
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #48335 is a reply to message #48276] Wed, 25 February 2009 20:50 Go to previous messageGo to next message
Chris Williams is currently offline Chris WilliamsFriend
Messages: 29
Registered: July 2009
Junior Member
Pascal Rapicault wrote:

> As an aside I would be interested in understanding why you can't use
> the p2 UI (3.4 or 3.5).

It's basically just an ease of use feature. We pop up an install wizard
that is a tree of features we offer as well as common 3rd-party features
that are popular among our users. Users check off what they want,
oblivious to the need for the repo URI/URLs or what IU they need to check
off. We then add the necessary repos for that feature under the hood,
query for the specific feature group IU and then start the P2
InstallWizard with those IInstallableUnits.

This makes it much easier for users to plugin in our other features
quickly and painlessly. Obviously with 3.5 we could add touchpoints that
add the repositories for them, but even then, the P2 UI can be a bit
overwhelming for many people - all they know is "I want a Git plugin".
Particularly since we ship our own standalone and those users aren't
familiar with Eclipse.
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #49184 is a reply to message #48335] Wed, 04 March 2009 16:20 Go to previous message
Chris Williams is currently offline Chris WilliamsFriend
Messages: 29
Registered: July 2009
Junior Member
Chris Williams wrote:

> Pascal Rapicault wrote:

>> As an aside I would be interested in understanding why you can't use
>> the p2 UI (3.4 or 3.5).

> It's basically just an ease of use feature. We pop up an install wizard
> that is a tree of features we offer as well as common 3rd-party features
> that are popular among our users. Users check off what they want,
> oblivious to the need for the repo URI/URLs or what IU they need to check
> off. We then add the necessary repos for that feature under the hood,
> query for the specific feature group IU and then start the P2
> InstallWizard with those IInstallableUnits.

> This makes it much easier for users to plugin in our other features
> quickly and painlessly. Obviously with 3.5 we could add touchpoints that
> add the repositories for them, but even then, the P2 UI can be a bit
> overwhelming for many people - all they know is "I want a Git plugin".
> Particularly since we ship our own standalone and those users aren't
> familiar with Eclipse.

As an effort to be a bit more helpful, here's the concrete
enhancements/fixes we'd really need for the P2 UI to match what we have. I
know that some of these are/have been addressed for 3.5 ("Uncategorized",
and the addRepo touchpoint, I believe) but beyond that I'm not sure if
these could/should be entered as enhancement requests. At the very least
it gives you an idea of the UI and workflow we prefer users have to
install additional features into our product.
1. The addRepository touchpoint working so we can pre-populate with all
the repos we hide from the user in our UI.
2. Ability to filter the contents of the repo listing - i.e. no more
"Uncategorized". In most cases we just want to show one umbrella feature.
3. Ability to decorate the main IU with an icon, description, and an URL
link the user can click to see "more" about the feature/plugin.
4. The ability to hide/combine multiple actual repos into one logical
repo. The main genymede update site is nice because pretty much everything
is in one main repo/root. We build all our features separately and point
to third-party repos. but we really want the repos themselves to sort of
not be shown, and instead to compose multiple of them under one root
labelled with our product's name or something along those lines.

To describe our UI: it's a tree of features under categories (like SCM,
Languages, Mobile). The categories and features have sort weights that
correspond to where the show up vertically in the tree (so that we can
push the more common/popular ones to the top). Each feature has an 16x16
icon, a short description and a link to learn more about it. The repos
themselves are hidden and do not really play into the view at all, each
feature tree node contains the repo it can be found on in it's metadata.
The feature id is also hidden from the user but kept in the metadata.

The user clicks something like "SCM > Git integration" and under the hood
we grab the feature id (and append ".feature.group") and the repo URL and
then use the P2 APIs to query the repo for that feature group and then
begin the installation process.
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #592397 is a reply to message #48216] Wed, 25 February 2009 20:43 Go to previous message
Pascal Rapicault is currently offline Pascal RapicaultFriend
Messages: 440
Registered: July 2009
Senior Member
> Is there a way to make our code compatible with both versions of the APIs
> using fragments? Would we need our eclipse base for the build to contain
> both 3.4 and 3.5 versions of the p2 plugins to do so?
Using the fragment idea, I think that what you are after should be
possible.
For example your UI bundle could have a fragment that encapsulates the
calls to p2 and is responsible for transforming the arguments accordingly
depending on the eclipse you are installed into. So you would have 3
bundles, your UI one and one fragment targeting p2 3.4 and one fragment
targeting p2 3.5.

As an aside I would be interested in understanding why you can't use
the p2 UI (3.4 or 3.5).

> Are there any examples out there of people using fragments to handle API
breakage like this?
The compatibility bundles you see in Eclipse are usually here for that,
except that they are fragments on the original bundles, whereas in your
case you want to adapt to different APIs based on your configuration.

PaScaL
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #592420 is a reply to message #48276] Wed, 25 February 2009 20:50 Go to previous message
Chris Williams is currently offline Chris WilliamsFriend
Messages: 29
Registered: July 2009
Junior Member
Pascal Rapicault wrote:

> As an aside I would be interested in understanding why you can't use
> the p2 UI (3.4 or 3.5).

It's basically just an ease of use feature. We pop up an install wizard
that is a tree of features we offer as well as common 3rd-party features
that are popular among our users. Users check off what they want,
oblivious to the need for the repo URI/URLs or what IU they need to check
off. We then add the necessary repos for that feature under the hood,
query for the specific feature group IU and then start the P2
InstallWizard with those IInstallableUnits.

This makes it much easier for users to plugin in our other features
quickly and painlessly. Obviously with 3.5 we could add touchpoints that
add the repositories for them, but even then, the P2 UI can be a bit
overwhelming for many people - all they know is "I want a Git plugin".
Particularly since we ship our own standalone and those users aren't
familiar with Eclipse.
Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #592727 is a reply to message #48335] Wed, 04 March 2009 16:20 Go to previous message
Chris Williams is currently offline Chris WilliamsFriend
Messages: 29
Registered: July 2009
Junior Member
Chris Williams wrote:

> Pascal Rapicault wrote:

>> As an aside I would be interested in understanding why you can't use
>> the p2 UI (3.4 or 3.5).

> It's basically just an ease of use feature. We pop up an install wizard
> that is a tree of features we offer as well as common 3rd-party features
> that are popular among our users. Users check off what they want,
> oblivious to the need for the repo URI/URLs or what IU they need to check
> off. We then add the necessary repos for that feature under the hood,
> query for the specific feature group IU and then start the P2
> InstallWizard with those IInstallableUnits.

> This makes it much easier for users to plugin in our other features
> quickly and painlessly. Obviously with 3.5 we could add touchpoints that
> add the repositories for them, but even then, the P2 UI can be a bit
> overwhelming for many people - all they know is "I want a Git plugin".
> Particularly since we ship our own standalone and those users aren't
> familiar with Eclipse.

As an effort to be a bit more helpful, here's the concrete
enhancements/fixes we'd really need for the P2 UI to match what we have. I
know that some of these are/have been addressed for 3.5 ("Uncategorized",
and the addRepo touchpoint, I believe) but beyond that I'm not sure if
these could/should be entered as enhancement requests. At the very least
it gives you an idea of the UI and workflow we prefer users have to
install additional features into our product.
1. The addRepository touchpoint working so we can pre-populate with all
the repos we hide from the user in our UI.
2. Ability to filter the contents of the repo listing - i.e. no more
"Uncategorized". In most cases we just want to show one umbrella feature.
3. Ability to decorate the main IU with an icon, description, and an URL
link the user can click to see "more" about the feature/plugin.
4. The ability to hide/combine multiple actual repos into one logical
repo. The main genymede update site is nice because pretty much everything
is in one main repo/root. We build all our features separately and point
to third-party repos. but we really want the repos themselves to sort of
not be shown, and instead to compose multiple of them under one root
labelled with our product's name or something along those lines.

To describe our UI: it's a tree of features under categories (like SCM,
Languages, Mobile). The categories and features have sort weights that
correspond to where the show up vertically in the tree (so that we can
push the more common/popular ones to the top). Each feature has an 16x16
icon, a short description and a link to learn more about it. The repos
themselves are hidden and do not really play into the view at all, each
feature tree node contains the repo it can be found on in it's metadata.
The feature id is also hidden from the user but kept in the metadata.

The user clicks something like "SCM > Git integration" and under the hood
we grab the feature id (and append ".feature.group") and the repo URL and
then use the P2 APIs to query the repo for that feature group and then
begin the installation process.
Previous Topic:PDE Export and Debug Info
Next Topic:Blocking problems w/a p2 based RCP product-Updates locked/feature install breaks
Goto Forum:
  


Current Time: Thu Jun 17 23:38:02 GMT 2021

Powered by FUDForum. Page generated in 0.02573 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top