You might want to have a look at the b3.aggregator [1] that we use to
put Helios together. It will give you a lot of this functionality. It
will not modify its sources though, instead it creates new meta-data.
The b3 aggregator features things like detailed view of meta-data,
category management, exclusions, and a lot of other "repository
management stuff".
[1] http://wiki.eclipse.org/Eclipse_b3/aggregator/manual
Regards,
Thomas Hallgren
On 05/26/2010 11:13 PM, Pascal Rapicault wrote:
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)).
[...]
Some of its features include
- Adding IU
+1
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.
- 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
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.
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?
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
|
