Therefore I was thinking that it may be interesting to add new
helper queries to do things like:
find an IU whose ID contains a string instead of being a full match.
find an IU that has a set of capability
Also we need to have a bunch of little example explaining what
they do in addition to a more descriptive guide of the syntax. Also
being able to relate the language to something known (e.g. OCL) could
Now from a code maintainer point of view, this language is part
of the API. So it brings 2 questions:
- how to we evolve it in a backward compatible way? not really
an urgent matter but still.
- do we leak any implementation detail? Are we too close to the
actual data structure. For example I see references to
IInstallableUnitPatch.class or such. Can't we avoid this?
On 2010-02-26, at 11:32 AM, Thomas Watson wrote:
I have a concern about how closely the syntax is tied to the
repository metadata syntax and the data structure of the IU. For
example, how you search for the latest versions of all the UIs that
provide the osgi.bundle capability goes something like this:
latest(x | x.providedCapabilities.exists(p | p.namespace ==
My understanding is that this will return all the latest versions of
the IUs that provide the capability with the namespace of osgi.bundle.
So there are a couple of concerns I can see if this QL is expected to
work for all future releases of p2.
- IUs must always have a way to get the list of provided capabilities
using the .providedCapabilities syntax. (probably pretty safe bet?)
- Capabilities must always have something called a namespace. Not sure
if this is always going to be true. I guess even OBR will have
resources (capabilities) that provide some kind of name space.
- The name space value becomes API. 'osgi.bundle' must always be the
namespace to represent a bundle. AFAICT there is no place in the p2 API
that lists the namespace values as API. The feel like they are an
internal detail to me.
I also don't see any documentation on the various fields that can be
used in a query (.providesCapabilities, .namespace etc.) and what their
corresponding types are.
Rapicault ---02/26/2010 09:55:33 AM---With the latest changes that
Thomas committed this week, we are now fully p2 QL enabled. Thank you.
Pascal Rapicault <pascal@xxxxxxxxxxxx>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
02/26/2010 09:55 AM
[p2-dev] p2 QL feedback / discussion
With the latest changes that Thomas committed this week, we are
now fully p2 QL enabled. Thank you.
Overall this is a good step forward and bring to p2 a really neat point
of flexibility. However before we wrap up on the API, I'm soliciting
feedback on it. What do you think of it, what are your worries, are
there any simple things we can do?
p2-dev mailing list
p2-dev mailing list