Home » Eclipse Projects » Buckminster dev » How to improve mapping rules in the Aggregator
| How to improve mapping rules in the Aggregator [message #502250] |
Mon, 07 December 2009 13:19  |
 Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
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
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502256 is a reply to message #502250] |
Mon, 07 December 2009 13:35  |
Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
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).
I think the URI resolution in our ecore model could be rewritten to
actually resolve version ranges without too much effort.
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.
- 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
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502262 is a reply to message #502256] |
Mon, 07 December 2009 13:50 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
> 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
|
|
| |
| Re: How to improve mapping rules in the Aggregator [message #502270 is a reply to message #502262] |
Mon, 07 December 2009 14:46 |
Stefan Daume
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
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
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502276 is a reply to message #502262] |
Mon, 07 December 2009 15:05 |
|
On 2009-12-07 14:50, Filip Hrbek wrote:
>> 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.
>
Not sure I follow. Please consider that one very important use-case is to be able to provide configurations in separate
files, just like we do with Galileo. Proxy references are crucial. Without them, everything sits together in one huge
file and there's no way of splitting it up.
>> 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.
>
On the contrary. I can see how a technical solution can merge rules and mappings into the same thing. I don't believe
it's very intuitive though. Appointing things in the source repositories (either by drag-n-drop or by selecting in a
list) is one thing. Describing rules that controls configurations, properties, and what not, is completely different
altogether. I fail to see how merging them would bring anything but confusion to the end user.
> 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?
>
Changing meta-data is very problematic. Everything in p2 works on the notion that an IU is immutable. So if you change
an IU, you need to give it another name or another version. That in turn, potentially breaks the meta-data that is
dependent on the IU since the version ranges used there doesn't include your new version. So the effect ripples up. Not
to mention that suddenly, you have gained responsibility for maintaining the IU in question.
I think the approach has to be to not change IU's (with the exception of categories. They don't have proper versions and
are not really used as IU's). Whatever rules or other functionality that we provide, it must be to make it easy to
aggregate what's out there. Not to change it.
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502288 is a reply to message #502276] |
Mon, 07 December 2009 15:42 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Thomas Hallgren wrote:
> On 2009-12-07 14:50, Filip Hrbek wrote:
>>> 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.
>>
> Not sure I follow. Please consider that one very important use-case is
> to be able to provide configurations in separate files, just like we do
> with Galileo. Proxy references are crucial. Without them, everything
> sits together in one huge file and there's no way of splitting it up.
>
We are mixing several things here - contributions, mapped repositories and mapped IUs.
Of course we keep supporting EMF proxy references in general (e.g. for contributions).
What we need to get rid of is using proxy references for mapped IUs. The URIs in there
are just partially duplicating the URIs in their containers (i.e. mapped repositories).
That's wrong because we need to take care of these URIs when changing the repo locations.
Converting a mapped IU from a proxy reference to a concrete IU in the repo into a mapping request
which is resolved (on the first level) before it is passed to the aggregation processing does
not break anything and helps to keep the code clean.
To avoid misunderstanding, here is an example:
CURRENT SOLUTION:
<repositories location="http://download.eclipse.org/releases/galileo">
<metadataRepository href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
<features>
<installableUnit href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository/@installableUnits [id='org.eclipse.acceleo.examples.feature.group',version='0. 8.1.v200909161003'] "/>
</features>
</repositories>
you can see the duplicated "p2:http://download.eclipse.org/releases/galileo", if the repo location is changed, the IU reference breaks without implementing special event handlers.
PROPOSED SOLUTION:
<repositories location="http://download.eclipse.org/releases/galileo">
<metadataRepository href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
<mapRequest type="feature" id="org.eclipse.acceleo.examples.feature.group" versionRange="[0.8.1.v200909161003,0.8.1.v200909161003]"/>
</repositories>
you can see how transparent this is - the request keeps valid even if the repo location is changed to something else.
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502297 is a reply to message #502270] |
Mon, 07 December 2009 15:57 |
Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
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-solut ion.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
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502298 is a reply to message #502288] |
Mon, 07 December 2009 15:58 |
|
Hi Filip,
I think I understand what you mean. What I meant was that we can gain full control over the URI. It doesn't need to
contain the redundant/problematic parts. Instead, it could contain just the id and the version range of the appointed
IU. It's still a URI though and still a Proxy.
- thomas
On 2009-12-07 16:42, Filip Hrbek wrote:
> Thomas Hallgren wrote:
>> On 2009-12-07 14:50, Filip Hrbek wrote:
>>>> 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.
>>>
>> Not sure I follow. Please consider that one very important use-case is
>> to be able to provide configurations in separate files, just like we
>> do with Galileo. Proxy references are crucial. Without them,
>> everything sits together in one huge file and there's no way of
>> splitting it up.
>>
>
>
> We are mixing several things here - contributions, mapped repositories
> and mapped IUs.
>
> Of course we keep supporting EMF proxy references in general (e.g. for
> contributions).
> What we need to get rid of is using proxy references for mapped IUs. The
> URIs in there
> are just partially duplicating the URIs in their containers (i.e. mapped
> repositories).
> That's wrong because we need to take care of these URIs when changing
> the repo locations.
> Converting a mapped IU from a proxy reference to a concrete IU in the
> repo into a mapping request
> which is resolved (on the first level) before it is passed to the
> aggregation processing does
> not break anything and helps to keep the code clean.
>
> To avoid misunderstanding, here is an example:
>
>
> CURRENT SOLUTION:
>
> <repositories location="http://download.eclipse.org/releases/galileo">
> <metadataRepository
> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
>
> <features>
> <installableUnit
> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository/@installableUnits [id='org.eclipse.acceleo.examples.feature.group',version='0. 8.1.v200909161003'] "/>
>
> </features>
> </repositories>
>
> you can see the duplicated
> "p2:http://download.eclipse.org/releases/galileo", if the repo location
> is changed, the IU reference breaks without implementing special event
> handlers.
>
> PROPOSED SOLUTION:
>
> <repositories location="http://download.eclipse.org/releases/galileo">
> <metadataRepository
> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
>
> <mapRequest type="feature"
> id="org.eclipse.acceleo.examples.feature.group"
> versionRange="[0.8.1.v200909161003,0.8.1.v200909161003]"/>
> </repositories>
>
> you can see how transparent this is - the request keeps valid even if
> the repo location is changed to something else.
>
> Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502305 is a reply to message #502298] |
Mon, 07 December 2009 16:15 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
I happy that we are both talking about the same thing :-)
However, what is the advantage of overriding the proxy resolution mechanism? Isn't it really cleaner
to keep the request parameters in attributes and run the resolution on demand when needed?
Filip
Thomas Hallgren wrote:
> Hi Filip,
> I think I understand what you mean. What I meant was that we can gain
> full control over the URI. It doesn't need to contain the
> redundant/problematic parts. Instead, it could contain just the id and
> the version range of the appointed IU. It's still a URI though and still
> a Proxy.
>
> - thomas
>
>
> On 2009-12-07 16:42, Filip Hrbek wrote:
>> Thomas Hallgren wrote:
>>> On 2009-12-07 14:50, Filip Hrbek wrote:
>>>>> 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.
>>>>
>>> Not sure I follow. Please consider that one very important use-case is
>>> to be able to provide configurations in separate files, just like we
>>> do with Galileo. Proxy references are crucial. Without them,
>>> everything sits together in one huge file and there's no way of
>>> splitting it up.
>>>
>>
>>
>> We are mixing several things here - contributions, mapped repositories
>> and mapped IUs.
>>
>> Of course we keep supporting EMF proxy references in general (e.g. for
>> contributions).
>> What we need to get rid of is using proxy references for mapped IUs. The
>> URIs in there
>> are just partially duplicating the URIs in their containers (i.e. mapped
>> repositories).
>> That's wrong because we need to take care of these URIs when changing
>> the repo locations.
>> Converting a mapped IU from a proxy reference to a concrete IU in the
>> repo into a mapping request
>> which is resolved (on the first level) before it is passed to the
>> aggregation processing does
>> not break anything and helps to keep the code clean.
>>
>> To avoid misunderstanding, here is an example:
>>
>>
>> CURRENT SOLUTION:
>>
>> <repositories location="http://download.eclipse.org/releases/galileo">
>> <metadataRepository
>> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
>>
>>
>> <features>
>> <installableUnit
>> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository/@installableUnits [id='org.eclipse.acceleo.examples.feature.group',version='0. 8.1.v200909161003'] "/>
>>
>>
>> </features>
>> </repositories>
>>
>> you can see the duplicated
>> "p2:http://download.eclipse.org/releases/galileo", if the repo location
>> is changed, the IU reference breaks without implementing special event
>> handlers.
>>
>> PROPOSED SOLUTION:
>>
>> <repositories location="http://download.eclipse.org/releases/galileo">
>> <metadataRepository
>> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
>>
>>
>> <mapRequest type="feature"
>> id="org.eclipse.acceleo.examples.feature.group"
>> versionRange="[0.8.1.v200909161003,0.8.1.v200909161003]"/>
>> </repositories>
>>
>> you can see how transparent this is - the request keeps valid even if
>> the repo location is changed to something else.
>>
>> Filip
>
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502320 is a reply to message #502305] |
Mon, 07 December 2009 16:55 |
|
On 2009-12-07 17:15, Filip Hrbek wrote:
> Hi Thomas,
>
> I happy that we are both talking about the same thing :-)
>
> However, what is the advantage of overriding the proxy resolution
> mechanism? Isn't it really cleaner
> to keep the request parameters in attributes and run the resolution on
> demand when needed?
>
Sure, but isn't that exactly what the proxy resolution is there for?
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502368 is a reply to message #502320] |
Mon, 07 December 2009 21:00 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Thomas Hallgren wrote:
> On 2009-12-07 17:15, Filip Hrbek wrote:
>> Hi Thomas,
>>
>> I happy that we are both talking about the same thing :-)
>>
>> However, what is the advantage of overriding the proxy resolution
>> mechanism? Isn't it really cleaner
>> to keep the request parameters in attributes and run the resolution on
>> demand when needed?
>>
> Sure, but isn't that exactly what the proxy resolution is there for?
>
I think that a proxy is expected to be resolved into a uniquely defined object.
Upon a request to one of object's properties, if the object is an unresolved proxy reference,
it is lazily resolved and the properties are initialized upon successful resolution.
If the resolution is not successful, the properties are not initialized. However,
we need them for the presentation layer. Currently we cheat in that case - we parse the
proxy URI using regexp and create fake properties from it. That's something I don't
like at all.
Instead, I would prefer specifying all the request properties in the request instance
(i.e. current MappedUnit). The presentation of the request would not have to analyze whether
the request is resolvable or not until we want to show status or mapping hints to the user.
When the aggregation build is run, the mapping requests can be easily converted into the
"all.contributed.content" feature's required capabilities (possibly with version ranges,
not only concrete versions), without resolving the requests one by one.
I still can't see any advantage of using EMF proxy mechanism here.
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502384 is a reply to message #502368] |
Mon, 07 December 2009 22:34 |
|
On 2009-12-07 22:00, Filip Hrbek wrote:
> I think that a proxy is expected to be resolved into a uniquely defined
> object.
> Upon a request to one of object's properties, if the object is an
> unresolved proxy reference,
> it is lazily resolved and the properties are initialized upon successful
> resolution.
>
Yes. That sounds like more or less exactly what we want.
> If the resolution is not successful, the properties are not initialized.
> However,
> we need them for the presentation layer. Currently we cheat in that case
> - we parse the
> proxy URI using regexp and create fake properties from it. That's
> something I don't
> like at all.
>
Because?
> Instead, I would prefer specifying all the request properties in the
> request instance (i.e. current MappedUnit).
You wanted to avoid redundancy. This sounds just like that.
> The presentation of the request would not
> have to analyze whether
> the request is resolvable or not until we want to show status or mapping
> hints to the user.
>
Is that a good thing? I would prefer if all markers etc. were in place from the start so that I can click through my
problem view and perhaps execute suggested fixes.
> When the aggregation build is run, the mapping requests can be easily
> converted into the
> "all.contributed.content" feature's required capabilities (possibly with
> version ranges,
> not only concrete versions), without resolving the requests one by one.
>
> I still can't see any advantage of using EMF proxy mechanism here.
>
The advantage is that normal model navigation applies. The engine could do exactly what it does today with no changes.
I suspect that we will run into a whole slew of problems if we remove the EMF dependency. A simple change in how the
proxy is resolved sounds a lot simpler and safer.
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502387 is a reply to message #502384] |
Mon, 07 December 2009 23:08 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Thomas Hallgren wrote:
> On 2009-12-07 22:00, Filip Hrbek wrote:
> > I think that a proxy is expected to be resolved into a uniquely defined
> > object.
> > Upon a request to one of object's properties, if the object is an
> > unresolved proxy reference,
> > it is lazily resolved and the properties are initialized upon successful
> > resolution.
> >
> Yes. That sounds like more or less exactly what we want.
Not if we use version ranges - in that case, the IU is resolved to something
which may be in conflict with other contributions even though the aggregation
as a whole is still resolvable (see below).
>
> > If the resolution is not successful, the properties are not initialized.
> > However,
> > we need them for the presentation layer. Currently we cheat in that case
> > - we parse the
> > proxy URI using regexp and create fake properties from it. That's
> > something I don't
> > like at all.
> >
> Because?
Because we need to branch the code for cases the proxy is resolvable or not.
In addition to that, parsing an URI sounds like a hack compared to using
clear attributes.
>
> > Instead, I would prefer specifying all the request properties in the
> > request instance (i.e. current MappedUnit).
>
> You wanted to avoid redundancy. This sounds just like that.
Where is the redundancy? I can't see any there. The request is persistent.
The resolution is transient, perhaps it is only an operation (no redundancy is stored).
>
> > The presentation of the request would not
> > have to analyze whether
> > the request is resolvable or not until we want to show status or mapping
> > hints to the user.
> >
> Is that a good thing? I would prefer if all markers etc. were in place
> from the start so that I can click through my problem view and perhaps
> execute suggested fixes.
Nothing prevents you from doing this. I suppose that very little will change
from the user perspective.
>
>
> > When the aggregation build is run, the mapping requests can be easily
> > converted into the
> > "all.contributed.content" feature's required capabilities (possibly with
> > version ranges,
> > not only concrete versions), without resolving the requests one by one.
> >
> > I still can't see any advantage of using EMF proxy mechanism here.
> >
> The advantage is that normal model navigation applies. The engine could
> do exactly what it does today with no changes.
>
> I suspect that we will run into a whole slew of problems if we remove
> the EMF dependency. A simple change in how the proxy is resolved sounds
> a lot simpler and safer.
I don't agree here. First, I can't think of a single problem that could arise with
proposed solution. Second, I don't think current model is capable to handle version
ranges.
An example:
Contribution 1
|
+ Mapped Repo 1 (http://x.y.z)
|
+ Feature a.b.c [1.0.0,2.0.0]
Contribution 2
|
+ Mapped Repo 2 (http://x.y.z)
|
+ Feature a.b.c [1.0.0,1.5.0]
If we let EMF resolve the IUs behind the feature "a.b.c", we will get
a.b.c#2.0.0 for Repo 1 and a.b.c#1.5.0 for Repo 2. Assembling this into
the all.contributed.content will end up with a resolution conflict.
If we assemble the all.contributed.content from the partial requests,
it will be resolvable (both contributions will agree on contributing
a.b.c#1.5.0)
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502392 is a reply to message #502387] |
Mon, 07 December 2009 23:40 |
|
On 2009-12-08 00:08, Filip Hrbek wrote:
> Thomas Hallgren wrote:
>> Yes. That sounds like more or less exactly what we want.
>
> Not if we use version ranges - in that case, the IU is resolved to
> something which may be in conflict with other contributions even though
> the aggregation as a whole is still resolvable (see below).
>
Uh, that sounds like a completely different problem (see below).
>> > The presentation of the request would not have to analyze whether
>> > the request is resolvable or not until we want to show status or
>> > mapping hints to the user.
>> >
>> Is that a good thing? I would prefer if all markers etc. were in place
>> from the start so that I can click through my problem view and perhaps
>> execute suggested fixes.
>
> Nothing prevents you from doing this. I suppose that very little will
> change from the user perspective.
>
Sure, but the advantage you just brought up (deferring the analyze) is gone.
>> The advantage is that normal model navigation applies. The engine
>> could do exactly what it does today with no changes.
>>
>> I suspect that we will run into a whole slew of problems if we remove
>> the EMF dependency. A simple change in how the proxy is resolved
>> sounds a lot simpler and safer.
>
> I don't agree here. First, I can't think of a single problem that could
> arise with proposed solution.
>
Problem number one:
Backward compatibility. My suggested approach would have a proxy resolver that acts on a URI. This resolver can easily
detect if the URI is the old style or a new style. The model is essentially unchanged. If we instead change the model
and remove the dependency, the backward compatibility layer becomes more complex.
Problem number two:
The EMF model is built on dependencies, containment, reverse dependencies, etc. If we simply remove the dependency, all
of that is gone and we need to maintain notifications etc. ourselves. All future code (b3 for instance) that wants to
use the model must cater for our special "almost a dependency but in fact not" solution.
> Second, I don't think current model is capable to handle version ranges.
>
> An example:
>
> Contribution 1
> |
> + Mapped Repo 1 (http://x.y.z)
> |
> + Feature a.b.c [1.0.0,2.0.0]
> Contribution 2
> |
> + Mapped Repo 2 (http://x.y.z)
> |
> + Feature a.b.c [1.0.0,1.5.0]
>
> If we let EMF resolve the IUs behind the feature "a.b.c", we will get
> a.b.c#2.0.0 for Repo 1 and a.b.c#1.5.0 for Repo 2. Assembling this into
> the all.contributed.content will end up with a resolution conflict.
>
> If we assemble the all.contributed.content from the partial requests,
> it will be resolvable (both contributions will agree on contributing
> a.b.c#1.5.0)
>
That assumes that you don't give the user feedback of what will actually be mapped before you run the aggregation so
that's a non-starter IMO.
I think a better solution would be to analyze the features that are mapped and make a best effort to come up with a set
of unique features. If that's not possible, then the planner will not be able to do it either. If we do it that way, we
stand a chance to give the user early and relevant feedback about potential conflicts as soon as the version ranges are
entered.
We will also address another problem. If feature 'a' includes feature 'b' and 'c', then there is very little reason for
the user to map 'b' and 'c' once 'a' has been mapped. It would be great if the user could be made aware of situations
like that (see thread 'lacking features and some small problems' on the buckminster newsgroup).
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502395 is a reply to message #502392] |
Tue, 08 December 2009 00:30 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
> Problem number one:
> Backward compatibility. My suggested approach would have a proxy
> resolver that acts on a URI. This resolver can easily detect if the URI
> is the old style or a new style. The model is essentially unchanged. If
> we instead change the model and remove the dependency, the backward
> compatibility layer becomes more complex.
Does it mean that we must keep the original model forever? No!
We have two options:
a) provide a conversion tool
b) implement automatic conversion attempt on unsuccessful opening
It's always better to clean up the model than to keep backward capability together
with problems. Using option b), current users won't notice that anything
has changed.
>
> Problem number two:
> The EMF model is built on dependencies, containment, reverse
> dependencies, etc. If we simply remove the dependency, all of that is
> gone and we need to maintain notifications etc. ourselves. All future
> code (b3 for instance) that wants to use the model must cater for our
> special "almost a dependency but in fact not" solution.
>
Not sure I follow - could you provide a concrete example of what we
are breaking and what problems you can see there?
We are talking about requests what to map, not about concrete IUs to map.
So I think that the proposed solution is much much cleaner and I would expect
much less problems than now.
> > Second, I don't think current model is capable to handle version
> ranges.
> >
> > An example:
> >
> > Contribution 1
> > |
> > + Mapped Repo 1 (http://x.y.z)
> > |
> > + Feature a.b.c [1.0.0,2.0.0]
> > Contribution 2
> > |
> > + Mapped Repo 2 (http://x.y.z)
> > |
> > + Feature a.b.c [1.0.0,1.5.0]
> >
> > If we let EMF resolve the IUs behind the feature "a.b.c", we will get
> > a.b.c#2.0.0 for Repo 1 and a.b.c#1.5.0 for Repo 2. Assembling this into
> > the all.contributed.content will end up with a resolution conflict.
> >
> > If we assemble the all.contributed.content from the partial requests,
> > it will be resolvable (both contributions will agree on contributing
> > a.b.c#1.5.0)
> >
> That assumes that you don't give the user feedback of what will actually
> be mapped before you run the aggregation so that's a non-starter IMO.
>
> I think a better solution would be to analyze the features that are
> mapped and make a best effort to come up with a set of unique features.
> If that's not possible, then the planner will not be able to do it
> either. If we do it that way, we stand a chance to give the user early
> and relevant feedback about potential conflicts as soon as the version
> ranges are entered.
I have this in mind too. It is not a better solution, it is yet another
addition to that solution. I can imagine running this analysis if we
don't use EMF URI resolution for mapped IUs.
>
> We will also address another problem. If feature 'a' includes feature
> 'b' and 'c', then there is very little reason for the user to map 'b'
> and 'c' once 'a' has been mapped. It would be great if the user could be
> made aware of situations like that (see thread 'lacking features and
> some small problems' on the buckminster newsgroup).
>
Yes - the same as the paragraph above. However, if contributors are people
from different companies for example, it makes sense that each of them
specifies his own requirements that may overlay someone else's requirements.
If the result is resolvable, then this approach is still ok even though
there are unnecessary duplicities in the requirements.
It's too late, I need some sleep :-)
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502416 is a reply to message #502395] |
Tue, 08 December 2009 05:24 |
|
On 2009-12-08 01:30, Filip Hrbek wrote:
>> Problem number one:
>> Backward compatibility. My suggested approach would have a proxy
>> resolver that acts on a URI. This resolver can easily detect if the
>> URI is the old style or a new style. The model is essentially
>> unchanged. If we instead change the model and remove the dependency,
>> the backward compatibility layer becomes more complex.
>
> Does it mean that we must keep the original model forever? No!
Do we want breaking changes in the model that are not really justified? No!
> We have two options:
> a) provide a conversion tool
> b) implement automatic conversion attempt on unsuccessful opening
>
c) use an improved proxy resolution scheme
> It's always better to clean up the model than to keep backward capability
> together with problems.
I would agree to that if I saw the problems. As it stands now, I don't. So can you please show me what the problem is?
> Using option b), current users won't notice that anything has changed.
>
>>
>> Problem number two:
>> The EMF model is built on dependencies, containment, reverse
>> dependencies, etc. If we simply remove the dependency, all of that is
>> gone and we need to maintain notifications etc. ourselves. All future
>> code (b3 for instance) that wants to use the model must cater for our
>> special "almost a dependency but in fact not" solution.
>>
>
> Not sure I follow - could you provide a concrete example of what we
> are breaking and what problems you can see there?
What if someone would like to use dynamic EMF to navigate the model? I know for sure that b3 for instance, will do just
that.
> We are talking about requests what to map, not about concrete IUs to map.
>
I think this is where our view differ. I see the link between the MappedUnit and the actual IU as something fairly
concrete. You either have a problem of some kind, or a resolved proxy.
> So I think that the proposed solution is much much cleaner and I would
> expect much less problems than now.
>
What problems would that be? The only thing you've mentioned so far is that there's a problem since the URI contains
redundant data. We agree that the redundant part should be removed. So what's left?
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502443 is a reply to message #502416] |
Tue, 08 December 2009 09:45 |
Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
Do we agree that version ranges are needed in the model? I think, it's
very annoying to update versions every time MDR is updated.
Thomas, how would you add version ranges to the current model without
breaking it too much?
Karel
Thomas Hallgren napsal(a):
> On 2009-12-08 01:30, Filip Hrbek wrote:
> >> Problem number one:
> >> Backward compatibility. My suggested approach would have a proxy
> >> resolver that acts on a URI. This resolver can easily detect if the
> >> URI is the old style or a new style. The model is essentially
> >> unchanged. If we instead change the model and remove the dependency,
> >> the backward compatibility layer becomes more complex.
> >
> > Does it mean that we must keep the original model forever? No!
>
> Do we want breaking changes in the model that are not really justified? No!
>
> > We have two options:
> > a) provide a conversion tool
> > b) implement automatic conversion attempt on unsuccessful opening
> >
>
> c) use an improved proxy resolution scheme
>
> > It's always better to clean up the model than to keep backward
> capability
> > together with problems.
>
> I would agree to that if I saw the problems. As it stands now, I don't.
> So can you please show me what the problem is?
>
> > Using option b), current users won't notice that anything has changed.
> >
> >>
> >> Problem number two:
> >> The EMF model is built on dependencies, containment, reverse
> >> dependencies, etc. If we simply remove the dependency, all of that is
> >> gone and we need to maintain notifications etc. ourselves. All future
> >> code (b3 for instance) that wants to use the model must cater for our
> >> special "almost a dependency but in fact not" solution.
> >>
> >
> > Not sure I follow - could you provide a concrete example of what we
> > are breaking and what problems you can see there?
>
> What if someone would like to use dynamic EMF to navigate the model? I
> know for sure that b3 for instance, will do just that.
>
> > We are talking about requests what to map, not about concrete IUs to
> map.
> >
>
> I think this is where our view differ. I see the link between the
> MappedUnit and the actual IU as something fairly concrete. You either
> have a problem of some kind, or a resolved proxy.
>
> > So I think that the proposed solution is much much cleaner and I would
> > expect much less problems than now.
> >
>
> What problems would that be? The only thing you've mentioned so far is
> that there's a problem since the URI contains redundant data. We agree
> that the redundant part should be removed. So what's left?
>
> - thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502447 is a reply to message #502443] |
Tue, 08 December 2009 10:12 |
|
On 2009-12-08 10:45, Karel Brezina wrote:
> Do we agree that version ranges are needed in the model? I think, it's
> very annoying to update versions every time MDR is updated.
>
I agree. Version ranges are needed.
> Thomas, how would you add version ranges to the current model without
> breaking it too much?
>
As a first step, I would replace the code that resolves the proxy reference from the InstallableUnitReference to the
InstallableUnit with one that understands both the current URI and one using id + version range.
Second, I would make sure that when a reference is established (by user selecting a mapped IU, either by drag-n-drop or
by selecting in a list), proxy URI using a range is created. Initially, this range would be open ended.
Third, I would provide the GUI necessary to alter the range boundaries (i.e. tweak the proxy). This is probably just a
matter of adding a custom derived property to the model (or perhaps more then one to bring clarity).
Fourth, I would add the validation that verifies that selected features don't overlap and doesn't create conflicts.
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502454 is a reply to message #502447] |
Tue, 08 December 2009 10:44 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Thomas Hallgren wrote:
> On 2009-12-08 10:45, Karel Brezina wrote:
>> Do we agree that version ranges are needed in the model? I think, it's
>> very annoying to update versions every time MDR is updated.
>>
> I agree. Version ranges are needed.
Great. We have a common thought :-)
>
>> Thomas, how would you add version ranges to the current model without
>> breaking it too much?
>>
> As a first step, I would replace the code that resolves the proxy
> reference from the InstallableUnitReference to the InstallableUnit with
> one that understands both the current URI and one using id + version range.
>
I can imagine this.
> Second, I would make sure that when a reference is established (by user
> selecting a mapped IU, either by drag-n-drop or by selecting in a list),
> proxy URI using a range is created. Initially, this range would be open
> ended.
>
When the reference to the IU is established, it refers to a resolved IU instance
and its proxy URI is undefined at that time.
The proxy URI is generated by the EMF resource implementation at the time
the model is being saved. It is unclear to me how we are going to hack this.
Even if we do, is that a proper usage of EMF?
> Third, I would provide the GUI necessary to alter the range boundaries
> (i.e. tweak the proxy). This is probably just a matter of adding a
> custom derived property to the model (or perhaps more then one to bring
> clarity).
>
This is also unclear to me - where do we add the properties? Are they
persistent/transient? How do we edit them?
> Fourth, I would add the validation that verifies that selected features
> don't overlap and doesn't create conflicts.
Sure, good thing. Although I think that feature overlap is not an error,
especially if the overlap comes from different contributions.
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502494 is a reply to message #502454] |
Tue, 08 December 2009 14:23 |
|
On 2009-12-08 11:44, Filip Hrbek wrote:
> When the reference to the IU is established, it refers to a resolved IU
> instance
> and its proxy URI is undefined at that time.
> The proxy URI is generated by the EMF resource implementation at the time
> the model is being saved. It is unclear to me how we are going to hack
> this.
> Even if we do, is that a proper usage of EMF?
>
The advice to rewrite the URI resolution comes from Ed Merks. I'm not an expert, but he is.
>> Third, I would provide the GUI necessary to alter the range boundaries
>> (i.e. tweak the proxy). This is probably just a matter of adding a
>> custom derived property to the model (or perhaps more then one to
>> bring clarity).
>>
>
> This is also unclear to me - where do we add the properties? Are they
> persistent/transient? How do we edit them?
>
They are transient. There are some examples in the book on how to do this.
>> Fourth, I would add the validation that verifies that selected
>> features don't overlap and doesn't create conflicts.
>
> Sure, good thing. Although I think that feature overlap is not an error,
> especially if the overlap comes from different contributions.
>
Right, overlaps are not errors. But the information is useful anyway.
- thomas
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502674 is a reply to message #502494] |
Wed, 09 December 2009 10:56 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Thomas Hallgren wrote:
> On 2009-12-08 11:44, Filip Hrbek wrote:
>> When the reference to the IU is established, it refers to a resolved IU
>> instance
>> and its proxy URI is undefined at that time.
>> The proxy URI is generated by the EMF resource implementation at the time
>> the model is being saved. It is unclear to me how we are going to hack
>> this.
>> Even if we do, is that a proper usage of EMF?
>>
> The advice to rewrite the URI resolution comes from Ed Merks. I'm not an
> expert, but he is.
>
OK, I'll talk to Ed about this to learn more.
Before I do, I'd like to ensure that I understand your thought:
If the proxy URI is resolved according to its version range, then mapping
the same IU twice (at different places) with different upper version range
bounds makes the whole model unresolvable - even though a solution exists
in fact. Is that assumption correct? If so, is it acceptable for users?
Example:
Mapping 1: a.b.c#[1.0.0,2.0.0] resolves to a.b.c#2.0.0
Mapping 2: a.b.c#[1.0.0,1.5.0] resolves to a.b.c#1.5.0
In addition to this, there may be a transitive request to include
a.b.c#[0.0.2,1.2.0] (from a dependency of something else).
If we resolve each of the two mappings using EMF proxy URI resolution
one by one (before we run the resolution of all contributed content),
we'll get a conflict.
>>> Third, I would provide the GUI necessary to alter the range boundaries
>>> (i.e. tweak the proxy). This is probably just a matter of adding a
>>> custom derived property to the model (or perhaps more then one to
>>> bring clarity).
>>>
>>
>> This is also unclear to me - where do we add the properties? Are they
>> persistent/transient? How do we edit them?
>>
> They are transient. There are some examples in the book on how to do this.
>
And where are they? On the InstallableUnitReference which refers to the actual IU?
Or anywhere else?
Filip
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502689 is a reply to message #502674] |
Wed, 09 December 2009 12:15 |
|
On 2009-12-09 11:56, Filip Hrbek wrote:
> Thomas Hallgren wrote:
>> The advice to rewrite the URI resolution comes from Ed Merks. I'm not
>> an expert, but he is.
>>
>
> OK, I'll talk to Ed about this to learn more.
> Before I do, I'd like to ensure that I understand your thought:
>
> If the proxy URI is resolved according to its version range, then mapping
> the same IU twice (at different places) with different upper version range
> bounds makes the whole model unresolvable - even though a solution exists
> in fact. Is that assumption correct? If so, is it acceptable for users?
>
> Example:
>
> Mapping 1: a.b.c#[1.0.0,2.0.0] resolves to a.b.c#2.0.0
> Mapping 2: a.b.c#[1.0.0,1.5.0] resolves to a.b.c#1.5.0
>
No, that assumption is wrong. The aggregator should use the intersection of the ranges. There must be a way to advice
the proxy rewrite when situations like this occur. I.e. the proxy rewrite must have access to other mappings using the
same id.
> In addition to this, there may be a transitive request to include
> a.b.c#[0.0.2,1.2.0] (from a dependency of something else).
>
> If we resolve each of the two mappings using EMF proxy URI resolution
> one by one (before we run the resolution of all contributed content),
> we'll get a conflict.
>
If two different features cause a transitive conflict, then we cannot solve that automatically unless we do a full plan
of everything at all times. That takes too long for us to do it everytime a mapping is added or modified.
What we could do, is to let the engine make a renewed attempt in case it fails, using the ranges instead of the
appointed features and if it succeeds, give some feedback to the user about the changes that were made. I.e. the
differences between what he sees in the aggregator and the actual selected feature. Perhaps that could also generate
some advice that would be applied when refreshing the current view of the model.
>> They are transient. There are some examples in the book on how to do
>> this.
>>
>
> And where are they? On the InstallableUnitReference which refers to the
> actual IU?
> Or anywhere else?
>
That seems like the natural place for it, yes.
- thomas
|
|
|
Goto Forum:
Current Time: Tue Apr 16 10:56:56 GMT 2024
Powered by FUDForum. Page generated in 1.23282 seconds |
] 
Search
Help
Register
Login
Home
