[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[buckminster-dev] How to improve mapping rules in the Aggregator

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