Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » Aggregator debate - take 2
Aggregator debate - take 2 [message #517341] Fri, 26 February 2010 20:14 Go to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
been thinking about this and wonder if the use case under debate is
achieved by the following:

- Repository R1 is mirrored to R2 and configured to only mirror
component A (and what it requires).
- In a second aggregation I use repository R2 and aggregate this with a
bunch of other repositories.

This way, my end result includes only the items I really wanted to get
from R1.

Will this handle the case Achim brought up?

If so, how can the above be supported using only one aggregation?
The extra repository creation step seems unnecessary to enable "cherry
picking" - a use case that I think is not too uncommon.

Regards
- henrik
Re: Aggregator debate - take 2 [message #517371 is a reply to message #517341] Sat, 27 February 2010 10:15 Go to previous messageGo to next message
Filip Hrbek is currently offline Filip Hrbek
Messages: 233
Registered: July 2009
Senior Member
This was almost possible in my experimental implementation. I must say "almost" because the whole repository R1 was available
to the final process for resolving dependencies. I guaranteed that the user got what explicitly selected, but
he could not control where the dependencies come from.

Example:

Repo A contains:

a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.1.0

Repo B contains:

d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.4.0
a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]


User A (in contribution A) requires
a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)

User B (in contribution B) requires
d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)


Algorithm 1)
The result of the aggregation AS IT STANDS TODAY is:

a.b.c/1.1.0.beta from B - since it is the best match for A's request for a.b.c/[1.0.0,MAX]
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX]
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request

I think that user A may be surprised where a.b.c/1.1.0.beta comes from.


Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:

a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX] from the repository where user B defined his request
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request, the scope for searching the dependencies is not limited


I think that with current model it should work like alg. 2).
If we say that alg. 1) is correct (I don't say it is incorrect!), then we should change the model and the UI.


In my view, both are correct! But then, we should change the model, the UI and add options to specify explicitly the scope of resolution. One of the algorithms becomes the default.


I would prefer to have a beer, a big table (not talking about software but real wooden table), a pen and a sheet of paper... and find the best solution :-)

Filip



Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>
> If so, how can the above be supported using only one aggregation?
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
> Regards
> - henrik
Re: Aggregator debate - take 2 - CORRECTION [message #517372 is a reply to message #517371] Sat, 27 February 2010 10:18 Go to previous messageGo to next message
Filip Hrbek is currently offline Filip Hrbek
Messages: 233
Registered: July 2009
Senior Member
Sorry, I made a little mistake that may confuse you. Here is a correction:

....
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:

a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
^
here is the mistake, should be a.b.c/1.0.0 from A (version 1.1.0 does not exist in A)
....


Filip

Filip Hrbek wrote:
> This was almost possible in my experimental implementation. I must say
> "almost" because the whole repository R1 was available
> to the final process for resolving dependencies. I guaranteed that the
> user got what explicitly selected, but
> he could not control where the dependencies come from.
>
> Example:
>
> Repo A contains:
>
> a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.1.0
>
> Repo B contains:
>
> d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.4.0
> a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
>
>
> User A (in contribution A) requires
> a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
> User B (in contribution B) requires
> d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
>
> Algorithm 1)
> The result of the aggregation AS IT STANDS TODAY is:
>
> a.b.c/1.1.0.beta from B - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX]
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX]
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request
>
> I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
>
>
> Algorithm 2)
> The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
>
> a.b.c/1.1.0 from A - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX] from the repository where user A defined his request
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX] from the repository where user B defined his request
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request, the scope for searching the dependencies is
> not limited
>
>
> I think that with current model it should work like alg. 2).
> If we say that alg. 1) is correct (I don't say it is incorrect!), then
> we should change the model and the UI.
>
>
> In my view, both are correct! But then, we should change the model, the
> UI and add options to specify explicitly the scope of resolution. One of
> the algorithms becomes the default.
>
>
> I would prefer to have a beer, a big table (not talking about software
> but real wooden table), a pen and a sheet of paper... and find the best
> solution :-)
>
> Filip
>
>
>
> Henrik Lindberg wrote:
>> Hi,
>> been thinking about this and wonder if the use case under debate is
>> achieved by the following:
>>
>> - Repository R1 is mirrored to R2 and configured to only mirror
>> component A (and what it requires).
>> - In a second aggregation I use repository R2 and aggregate this with
>> a bunch of other repositories.
>>
>> This way, my end result includes only the items I really wanted to get
>> from R1.
>>
>> Will this handle the case Achim brought up?
>>
>> If so, how can the above be supported using only one aggregation?
>> The extra repository creation step seems unnecessary to enable "cherry
>> picking" - a use case that I think is not too uncommon.
>>
>> Regards
>> - henrik
Re: Aggregator debate - take 2 [message #517381 is a reply to message #517341] Sat, 27 February 2010 10:36 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 02/27/2010 01:58 AM, Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>

That case is already handled since the planner prevents results that are inconsistent.

> If so, how can the above be supported using only one aggregation?

You use a version range that is restrictive enough to give you the A that you want.

> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
Using id + versionRange should give you all the cherry picking capabilities you need. That's of course unless you think
that the same IU found in different repositories really are different IU's (a view that in itself opens up a whole new
can of worms).

- thomas
Re: Aggregator debate - take 2 [message #517415 is a reply to message #517381] Sat, 27 February 2010 16:10 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Thomas Hallgren <thomas@tada.se> wrote:

> Using id + versionRange should give you all the cherry picking
> capabilities you need. That's of course unless you think that the same
> IU found in different repositories really are different IU's (a view
> that in itself opens up a whole new can of worms).
>
No, I expect same IU fo be the same across all repos - or something is
really wrong.


--
- henrik
Re: Aggregator debate - take 2 - CORRECTION [message #600230 is a reply to message #517371] Sat, 27 February 2010 10:18 Go to previous message
Filip Hrbek is currently offline Filip Hrbek
Messages: 233
Registered: July 2009
Senior Member
Sorry, I made a little mistake that may confuse you. Here is a correction:

....
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:

a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
^
here is the mistake, should be a.b.c/1.0.0 from A (version 1.1.0 does not exist in A)
....


Filip

Filip Hrbek wrote:
> This was almost possible in my experimental implementation. I must say
> "almost" because the whole repository R1 was available
> to the final process for resolving dependencies. I guaranteed that the
> user got what explicitly selected, but
> he could not control where the dependencies come from.
>
> Example:
>
> Repo A contains:
>
> a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.1.0
>
> Repo B contains:
>
> d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.4.0
> a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
>
>
> User A (in contribution A) requires
> a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
> User B (in contribution B) requires
> d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
>
> Algorithm 1)
> The result of the aggregation AS IT STANDS TODAY is:
>
> a.b.c/1.1.0.beta from B - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX]
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX]
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request
>
> I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
>
>
> Algorithm 2)
> The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
>
> a.b.c/1.1.0 from A - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX] from the repository where user A defined his request
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX] from the repository where user B defined his request
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request, the scope for searching the dependencies is
> not limited
>
>
> I think that with current model it should work like alg. 2).
> If we say that alg. 1) is correct (I don't say it is incorrect!), then
> we should change the model and the UI.
>
>
> In my view, both are correct! But then, we should change the model, the
> UI and add options to specify explicitly the scope of resolution. One of
> the algorithms becomes the default.
>
>
> I would prefer to have a beer, a big table (not talking about software
> but real wooden table), a pen and a sheet of paper... and find the best
> solution :-)
>
> Filip
>
>
>
> Henrik Lindberg wrote:
>> Hi,
>> been thinking about this and wonder if the use case under debate is
>> achieved by the following:
>>
>> - Repository R1 is mirrored to R2 and configured to only mirror
>> component A (and what it requires).
>> - In a second aggregation I use repository R2 and aggregate this with
>> a bunch of other repositories.
>>
>> This way, my end result includes only the items I really wanted to get
>> from R1.
>>
>> Will this handle the case Achim brought up?
>>
>> If so, how can the above be supported using only one aggregation?
>> The extra repository creation step seems unnecessary to enable "cherry
>> picking" - a use case that I think is not too uncommon.
>>
>> Regards
>> - henrik
Re: Aggregator debate - take 2 [message #600254 is a reply to message #517381] Sat, 27 February 2010 16:10 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Thomas Hallgren <thomas@tada.se> wrote:

> Using id + versionRange should give you all the cherry picking
> capabilities you need. That's of course unless you think that the same
> IU found in different repositories really are different IU's (a view
> that in itself opens up a whole new can of worms).
>
No, I expect same IU fo be the same across all repos - or something is
really wrong.


--
- henrik
Previous Topic:Aggregator debate - take 2
Next Topic:Aggregator with version range support
Goto Forum:
  


Current Time: Thu Sep 18 11:58:56 GMT 2014

Powered by FUDForum. Page generated in 0.36124 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software