Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] p2 QL feedback / discussion

Another concern:
Most new code that has been added since we changed the IQueryResult interface tend to use the expensive toSet() method instead of the unmodifiableSet() method. Example:

 someCollection.addAll(queryResult.toSet());

instead of the much cheaper:

 someCollection.addAll(queryResult.unmodifiableSet());

The toSet() creates a full copy of the result while the unmodifiableSet() doesn't. This is stated in the javadoc but perhaps it needs to be more clear? Or should we change the method names?

- thomas


On 02/26/2010 09:02 PM, Pascal Rapicault wrote:
Personally I'm worried about the learning curve to new comers (and old comers as well :)) because I now have to learn a language to do something simple that I use to be able to do with a bit of code.
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 help.

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?

PaScaL

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 == 'osgi.bundle'))

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.

Tom



<graycol.gif>Pascal 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.

<ecblank.gif>
From:
<ecblank.gif>
Pascal Rapicault <pascal@xxxxxxxxxxxx>
<ecblank.gif>
To:
<ecblank.gif>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
<ecblank.gif>
Date:
<ecblank.gif>
02/26/2010 09:55 AM
<ecblank.gif>
Subject:
<ecblank.gif>
[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?

PaScaL_______________________________________________
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

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


Back to the top