[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [p2-dev] How to query feature's plugins/IUs from p2 metadata?

Hi,

 

Does somebody have any suggestions how this IU deletion issue should be done?

 

Is there already some functionality in P2 engine that would inform me, before the actual delete operation, that you cannot do this because it would break plugin X?

 

Or am I looking this repository management issue from the wrong angle? How have you planned that these kinds of “obsolete” features should be removed from

the repositories without braking other features?

 

 

 

 

 

         >Deleting IU ( including deleting obsolete IUs from the repositories safely, e.g. taking care of dependencies etc.)

>Definitely interesting. Though again this will have to be used with big "warnings" around it since you don't want to pull out things that are no longer used.

This functionality became an issue when we thought that how one is supposed to delete such features (IUs) from the repository that are no longer used. Simple

deleting the binaries is not sufficient enough because some features or feature versions could use same plugins from plugins folder.

 

For example:

Feature A:

   Plugin_A_1.jar

   Plugin_A_1_help.jar

Feature B:

  Plugin_B_1.jar

  Plugin_A_1_help.jar

 

If I now remove feature A, it will also remove Plugin_A_1.jar and Plugin_A_1_help.jar files, and this obviously breaks Feature B.

 

Now I am not sure what is the best approach to handle this issue with P2 API.

 

 

Best Regards, Mika Immonen

 

From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Mika.Immonen@xxxxxxxxx
Sent: 28. toukokuuta 2010 13:50
To: p2-dev@xxxxxxxxxxx
Subject: RE: [p2-dev] How to query feature's plugins/IUs from p2 metadata?

 

Hi,

 

Thanks for the responses.

 

>[1] Admin ui - http://www.eclipse.org/downloads/download.php?file=/equinox/drops/S-3.6RC2-201005201744/equinox-p2-agent-3.6RC2-macosx.tar.gz

This seems interesting tool. I will look it more closely next week.

 

> Modifying IU

>Since IUs are meant to be immutable, I'm not a big fan of this idea unless the IU version is being changed. What do you have in mind there?

We are not actually modifying the IU but its behavior in repository, in the beginning we are simply planning to allow user to change IUs categories in the

selected repository e.g. with details view or by drag&drop functionality. Future shows what else might be provided with this functionality.

 

-          >Deleting IU ( including deleting obsolete IUs from the repositories safely, e.g. taking care of dependencies etc.)

>Definitely interesting. Though again this will have to be used with big "warnings" around it since you don't want to pull out things that are no longer used.

This functionality became an issue when we thought that how one is supposed to delete such features (IUs) from the repository that are no longer used. Simple

deleting the binaries is not sufficient enough because some features or feature versions could use same plugins from plugins folder.

 

For example:

Feature A:

   Plugin_A_1.jar

   Plugin_A_1_help.jar

Feature B:

  Plugin_B_1.jar

  Plugin_A_1_help.jar

 

If I now remove feature A, it will also remove Plugin_A_1.jar and Plugin_A_1_help.jar files, and this obviously breaks Feature B.

 

Now I am not sure what is the best approach to handle this issue with P2 API. Is there already some functionality in P2 engine that would inform me, before

the actual delete operation, that you cannot do this because it would break plugin X?

 

Or am I looking this repository management issue from the wrong angle? How have you planned that these kinds of “obsolete” features should

be removed from the repositories without braking other features?

 

>Which sort of doc would you like to see being added?

Basically, it has been very tedious to find out any information about how P2 APIs are meant to be used (Obviously, because P2 API has not been ready / frozen).

In the past I’ve found previous Eclipse Articles (that contains some description, use cases and examples) very useful. I recall some article that showed

how one can add P2 update feature to the RCP Mail application. These sorts of example articles are quite useful to figure out real life use cases.

 

Best Regards, Mika Immonen

 

 

From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: 27. toukokuuta 2010 0:14
To: P2 developer discussions
Subject: Re: [p2-dev] How to query feature's plugins/IUs from p2 metadata?

 

Thanks for sharing these details. These are very interesting functionalities, a few of which overlap with what the agent [1] (aka admin UI) does today or use to do in the now defunct (but hopefully soon to be resurrected analysis bundle (org.eclipse.equinox.internal.p2.ui.analysis)). 

 

 

 

On 2010-05-26, at 2:01 AM, <Mika.Immonen@xxxxxxxxx> <Mika.Immonen@xxxxxxxxx> wrote:

 

[...]

Some of its features include

-          Adding IU

                      +1

 

-          Modifying IU

                      Since IUs are meant to be immutable, I'm not a big fan of this idea unless the IU version is being changed. What do you have in mind there?

 

-          Deleting IU ( including deleting obsolete IUs from the repositories safely, e.g. taking care of dependencies etc.)

                      Definitely interesting. Though again this will have to be used with big "warnings" around it since you don't want to pull out things that are no longer used.

 

 

-          Category management

                      +1

 

-          Other repository management stuff

 

At the moment I would like to show to the users detailed information about different IUs that they have selected from the GUI.

Currently we are showing the basic stuff like repository name, IU name, IU version etc.

                      We have some code that shows some of this in the admin UI (see attached screenshot)

 

 

 

Now I would like to show which IUs from the repository actually belongs to (are part of) the selected IU (or feature) .

Just like they were previously listed in the feature.xml file, when feature’s plugins were listed inside <plugins> -tag.

                      The p2.ui bundle contains some logic for this. You should be able to reuse or copy the composite or viewer that we are using there. It can be tweaked by the Policy class.

                      I think we use to have that in the analysis bundle but I'm not sure.

 

 

>Relying on the shape of the metadata can only get you so far since the mapping between features and metadata is not API and could be changed in the future.

We are quite familiar with the P2 API. I have been following its progress closely since early 2009 and tested its functionality quite much. The lack of decent

documentation / use cases has been a bit of concern to our development team. Fortunately it has been improved over these Eclipse 3.6 M? and RC? releases.

                      Which sort of doc would you like to see being added?

 

I agree that it is not reasonable to rely on structure of the p2 metadata file. The QueryUtil (from import org.eclipse.equinox.p2.query.QueryUtil package)

and its functionality seems a good starting point to retrieve different information from the metadata but I have not quite figured it out yet, thus

my question here.

 

Can we use QueryUtil or what is your opinion how this information should be retrieved?

                      QueryUtil will definitely help you gather all the IUs that are groups. >From there you can get each requirement and run a query with them (e.g. QueryUtil.createMatchQuery(req.getMatches())). This is more or less what the PermissiveSlicer and the Slicer are doing.

 

Hope this help, 

 

PaScaL




 

Best Regards, Mika Immonen

 

 

From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: 25. toukokuuta 2010 21:14
To: P2 developer discussions
Subject: Re: [p2-dev] How to query feature's plugins/IUs from p2 metadata?

 

Could you please tell more about what is the final goal?

 

Relying on the shape of the metadata can only get you so far since the mapping between features and metadata is not API and could be changed in the future.

 

 

On 2010-05-25, at 6:53 AM, <Mika.Immonen@xxxxxxxxx> <Mika.Immonen@xxxxxxxxx> wrote:



Hi,

 

I'd need to query plugins that belong to a certain feature (defined with <plugin>-elements on feature.xml).

 

My current functionality gets the requirements with org.eclipse.equinox.p2.metadata.getRequirements() method and then removes those requirements that are not found as installable units on repository.

Drawback of this approach is it lists even those requirements that are not listed as <plugin> in the feature.xml.

 

The query also lists feature itself not just the plugins. Features seem to have (org.eclipse.update.install.features=true) filter defined on metadata, but can I trust that all features have it and no plugin will have it?

 

So in short: is it possible to get a listing of <plugin> elements defined for a feature?

 

Best regards,

 

Mika Immonen, Senior Software Developer
Tieto Finland Oy, R&D Services

 

 

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

 

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

 

PNG image