[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] How to improve mapping rules in the Aggregator
|
Well, a P2 repo can be perceived as a set of IUs. In the aggregator, I
want to use some IUs from the original repo. In fact, I want to
transform the original set of IUs into a different set of IUs, that's
why I want to use tranformation rules.
I can see the following use cases:
- I want to use just a few IUs from the original repo - I'd add IUs one
by one (inclusion rules with definite ids)
- I want to add 30% IUs that have a common feature - I'd use an
inclusion rule
- I want to use the original repo without 30% IUs that have a common
feature - I'd use an exclusion rule
- I want to use the original repo but a few IUs - I'd add exclusion
rules with definite ids
So, if we refuse inclusion rules, we will limit the aggregator and it
might be painful for some users.
Agree, when we consider repos with just a few IUs, inclusion rules might
seem useless. However, number of IUs in the repos is growing - "Galileo
contains just above 3800 IUs. With Helios, we plan to retain old
releases and thus perhaps pass the 10.000 mark." (extracted from
http://thhal.blogspot.com/2009/12/maven-p2-dilemma-and-solution.html).
Karel
Stefan Daume napsal(a):
Hi guys,
there are two threads intertwined in this discussion: 1) How to deal
with rules in the UI and 2) How to handle rules in the model.
I will set the proposed class model aside and just spell out my view on
aggregation rules in general.
I am with Thomas when he says that rules could be much broader and hence
should be represented seperately. That was my point raised in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=295058.
Because rules may have to cover different aspects of the aggregation
process there should not be different classes of rules but the notion of
an aggregation rule that can specify sophisticated constraints (I don't
know if p2QL is the right language for this, but this is another
discussion).
So in light of this I would lean towards keeping the representation of a
rule seperate and not merging it with MappedUnit.
This has implications for the UI. If rules are not necessarily tied to
an IU or anything else, other than the aggregation, then it should be
possible to define them independently as well. I could imagine a "Rules"
node in the model, where I can define and/or view rules for the
aggregation. Furthermore, it should be shown for an invidual IU what
rules would apply if any.
This notion of a rule could also cope with cases such as unexpected
changes in a mapped repo, thus a rule may or may not be applied,
depending on its scope or context.
The discussion so far was more at the class level, but I am concerned
with usability given that I have been using the Aggregator quite a bit
recently.
Finally, whatever we choose we do not need to expose all details of it
in the UI. So even if p2QL turns out to be the right constraint
expression language, we don't have to turn the Aggregator editor into a
p2QL editor.
Stefan
Filip Hrbek wrote:
Hi Karel,
I see one immediate problem. That is the 'idPattern' in combination
with the 'versionRange'. It is a problem because there cannot be a
clear rule that selects the best fit. I would much rather see a
explicit 'id' then a 'pattern'. A MapRequest that replaces a
MappedUnit must always appoint exactly one IU (well, or zero if the
mapping cannot be resolved).
Yes, a resolution of a pattern in combination with a version range
does not make sense.
However, it depends on the presentation in the user interface. I think
we could consider
applying rules saying which combination is valid or not.
These all are valid for example:
ALL TYPES | ANY IU | LATEST VERSION
TYPE (e.g. FEATURE) | ANY IU | LATEST VERSION
TYPE (e.g. BUNDLE) | IU (e.g. org.eclipse.buckminster.core | VERSION
RANGE (e.g. >= 1.2.3.v20090101)
In addition to that, I think it would be more intuitive to add a
default request to each
newly added mapped repository:
ALL TYPES | ANY IU | LATEST VERSION
If user does not want to map verbatim, he would simply edit this
request (or possibly added other requests).
In my view, it is more intuitive than considering empty list of IUs as
"map verbatim" and a list of IUs as "map listed".
A repository without any map request would become invalid.
UI presentation of this:
+ Mapped Repository (http://xxx.yyy/updates)
|
+ Include ALL
or
+ Mapped Repository (http://xxx.yyy/updates)
|
+ Include feature org.eclipse.buckminster.core 1.2.3.v20090101
+ Include ....
or
+ Mapped Repository (http://xxx.yyy/updates)
|
+ Include ALL
+ Include feature SVN Native Libraries (win32/win32/x86,
win32/win32/x86_64)
I think the URI resolution in our ecore model could be rewritten to
actually resolve version ranges without too much effort.
We want to get rid of the URI in the map request (or mapped IU or
whatever it is called).
The repository URI is in the mapped repository and there is no reason
to double the reference
in its children (actually it causes implementation problems). So, even
if we only allow
to have mapping requests resolved into single IUs, we need to replace
the proxy reference
with a self-contained request mechanism.
A rule is somewhat different then a MapRequest in my view. A rule can
apply to zero or many mapped things, or even to a whole aggregation.
It all depends on what the rule describes. Ideally, I think rules
should be expressed as p2QL query expressions so that it's possible
to say things like "exclude all translation fragments" or "exclude
IU's that include this property". Using p2QL to define the scope for
the rule would also give us pattern matching for free.
To summarize, I think it's important to keep MapRequest and Rule
separate and that a MapRequest conceptually resovles to one single IU
(best fit) whereas rules are much more open.
This is a very technical point of view. From user perspective, I can't
see such
a difference between a rule and a mapping request.
An idea: If we want to fix a problem in the original repository (such
as SVN native libraries),
what about changing the metadata so that the unvalidated features
would not be visible for
platforms that were not validated?
Filip
- thomas
Karel Brezina napsal(a):
Hi,
lately, we've been discussing two aggregator issues. Some of us (I'd
even say most of us :-) ) think that:
1) MappedUnit should be replaced with a MapRequest (id and version
would be replaced by id pattern and version range)
2) MappedUnit and MapRule have much more in common than just
IUReference and should be merged together as a MapRequest
I'm proposing to replace MappedUnit and MapRule with the following
structure:
class MapRequest
{
IUType iuType;
String idPattern;
VersionRange versionRange;
boolean exclude;
List<Configuration> applyToConfigurations;
}
enum IUType
{
ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
}
This model is more general, but proper UI would make it easy to use.
It wouldn't be more complicated to use the aggregator. In some
aspects, it would be even easier. Anyway, it would be open for more
advanced features.
Major advantages:
- versions of mapped units don't have to be updated every time MDRs
are updated
- it's easier to add more complex exclusion/inclusion rules
- easier implementation (getting rid of proxy references to IU)
Some basic actions:
- d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
created. iuType, idPattern and min. version of the range would be
set according to the selected IU, max. version would be set to
infinity, exclude would be set to false, applyToConfigurations would
be empty
- d&d + Ctrl - it would create the same MapRequest, but exclude
would be set to true
The aggregator would have to provide some special actions (views) to
show how the request (or group of requests) would be resolved on the
first level.
Do you see any problems with the model I'm proposing? Do you have
any further improvements? Perhaps, do you thing that the current
solution is better?
There are several issue that would be affected by this change
(293774, 293083, 293073, 292324), so I'd like to figure out, if
there is a will to improve the aggregator this way.
Regards,
Karel