Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » Aggregator debate - take 2
Aggregator debate - take 2 [message #600209] Sat, 27 February 2010 00:58 Go to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
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 #600226 is a reply to message #600209] Sat, 27 February 2010 10:15 Go to previous messageGo to next message
Filip Hrbek is currently offline Filip HrbekFriend
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 [message #600238 is a reply to message #600209] Sat, 27 February 2010 10:36 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3230
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
Previous Topic:Aggregator with version range support
Next Topic:Aggregator debate - take 2
Goto Forum:
  


Current Time: Fri Nov 28 23:06:25 GMT 2014

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

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