Skip to main content
[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 
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

Back to the top