which version do you take in this case?

[Mariano Martinez Peck]

Hi dale, I have a question. Suppose a project   A  has dependencies on other two projects B and C.
B depends on the project OB version 1.1   and C depends on project OB version 1.2 (the same project but another version).

So...which OB version has A at the end?

Thanks!

Mariano

ps: sorry if it was explained in the tutorial

[Dale Henrichs]

Mariano,

This is a good question.

The answer depends upon how the OB project reference is defined. By default the project #operator is set #>=.

The #operator is used to compare the version loaded with the version to be loaded:

currentVersion perform: #>= with: targetVersion

If the target version is 1.1 and the current version is 1.2 (1.2 being #>= 1.1) nothing is loaded and version 1.2 wins.

If the target version is 1.2 and the current version is 1.1 (1.1 is not !>= 1.2) then version 1.2 is loaded.

So in your example OB 1.2 will end being loaded.

You specify the operator when you define the project reference:

spec
project: 'Seaside2.8' overrides: [
spec
className: 'ConfigurationOfGsSeaside28';
operator: #>=
projectPackage: [...]].

With the set of operators being:

#= #~= #> #< #>= #<= #~>

Note that #~> operator is "approximately greater than" stolen from Ruby Gems (http://docs.rubygems.org/read/chapter/16).

Dale

[Mariano Martinez Peck]

On Fri, Dec 18, 2009 at 9:33 PM, Dale Henrichs <dale.h...@gemstone.com> wrote:

Mariano,

This is a good question.

Yes, I ask because the "conflict manager" is something that we ALWAYS have in tools like these. I remember the strategies maven (in java world) used. I remember two:

1) The newer version
2) The version that was first in the tree of dependencies. Suppose that in my example A also depends in OB but version 0.9, then A will get 0.9 and NOT 1.2.

I just comment you this in case you find it useful to extend your operators to something more generic like ConflicResolverStrategy and then you create OperatorStrategy or N sublcasses per operator...I don't know, just an idea :)
 

The answer depends upon how the OB project reference is defined. By default the project #operator is set #>=.

The #operator is used to compare the version loaded with the version to be loaded:

 currentVersion perform: #>= with: targetVersion

If the target version is 1.1 and the current version is 1.2 (1.2 being #>= 1.1) nothing is loaded and version 1.2 wins.

If the target version is 1.2 and the current version is 1.1 (1.1 is not !>= 1.2) then version 1.2 is loaded.

So in your example OB 1.2 will end being loaded.

Ok...perfect. I didn't know about this operator:  
 

You specify the operator when you define the project reference:

 spec
   project: 'Seaside2.8' overrides: [
     spec
       className: 'ConfigurationOfGsSeaside28';
       operator: #>=
       projectPackage: [...]].

With the set of operators being:

 #= #~= #> #< #>= #<= #~>

Note that #~> operator is "approximately greater than" stolen from Ruby Gems (http://docs.rubygems.org/read/chapter/16).

Ok, thank you very much.

You have another mail to put in the F.A.Q maybe :)

Cheers,

Mariano

 

[Dale Henrichs]

I realize that there is _much_ more to do in the area of detecting and reasoning about conflicts, but I didn't want to tackle that problem with the first release ... the #>= operator covers the most common cases and when it doesn't I think humans will have to be involved to untanggle things ... at least in the beginning.

This mail is indeed earmarked for the FAQ!

Thanks,

[Mariano Martinez Peck]

On Fri, Dec 18, 2009 at 11:59 PM, Dale Henrichs <dale.h...@gemstone.com> wrote:

I realize that there is _much_ more to do in the area of detecting and reasoning about conflicts, but I didn't want to tackle that problem with the first release ... the #>= operator covers the most common cases and when it doesn't I think humans will have to be involved to untanggle things ... at least in the beginning.

+10000   I am totally agree with you. Let's go step by step. This is not necessary and as you said the operator covers 99% of the cases. I just didn't want to "loose" the subject of the thread to tell you how others solve the same problem.
 

This mail is indeed earmarked for the FAQ!

:)
 

[Mariano Martinez Peck]

Hi Dale:  I am having a problem with this.

In ConfigurationOfPharo >> version10rc105052:     I define:

project: 'OB Dev' with: '1.1';
project: 'OB Dev Tests' with: '1.1';

In baseline, they are:

project: 'OB Dev'
                    with:
                        [ spec
                                className: 'ConfigurationOfOmniBrowser';
                                loads: #('Dev');
                                file: 'ConfigurationOfOmniBrowser';
                                repository: 'http://www.squeaksource.com/MetacelloRepository' ];
                project: 'OB Dev Tests'
                    with:
                        [ spec
                                className: 'ConfigurationOfOmniBrowser';
                                loads: #('Dev Tests');
                                file: 'ConfigurationOfOmniBrowser';
                                repository: 'http://www.squeaksource.com/MetacelloRepository' ].


In the ConfiguratioOfOmniBrowser >> version11:

you can see I am loading: OmniBrowser-lr.458.


At the sametime, from ConfigurationOfPharo, I have dependencies to projects that has as dependency OB 1.0 (instead of 1.1). For example, ConfigurationOfAutomaticMethodCategorizer.

Now, as I understood and I can see in MetacelloProjectSpec >> operator
the default is >=

So...It should load all the stuff for OB 1.1. But it doesn't. If you evaluate:


((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-rc2.10505.2') load.

You will see that the version for OmniBrowser is OmniBrowser-DamienCassou.462
which is from 1.0.

Even more information: all the rest of the packages, seem to have the versions from 1.1. Only that package seem to have the version of 1.0

And finally, let me remark something that I think it is were the problem came from:  In ConfigurationOfOmniBrowser 1.0 I used the wiresong repo and in 1.1 Lukas's one.

And,  OmniBrowser-DamienCassou.462  is from wiresong repo.

Ok....I am sure if I change all my dependencies to use 1.1 it will work, but I wanted to ask.

Cheers

Mariano

[Dale]

I'll have to take a detailed look at this...could you tell me what
version of Metacello you are using?

I'll try to reproduce the problem and analyze what's going on...

Dale

On Jan 16, 4:23 pm, Mariano Martinez Peck <marianop...@gmail.com>
wrote:

> marianop...@gmail.com> wrote:
>
> > On Fri, Dec 18, 2009 at 11:59 PM, Dale Henrichs <
> > dale.henri...@gemstone.com> wrote:
>
> >> I realize that there is _much_ more to do in the area of detecting and
> >> reasoning about conflicts, but I didn't want to tackle that problem with the
> >> first release ... the #>= operator covers the most common cases and when it
> >> doesn't I think humans will have to be involved to untanggle things ... at
> >> least in the beginning.
>
> > +10000   I am totally agree with you. Let's go step by step. This is not
> > necessary and as you said the operator covers 99% of the cases. I just
> > didn't want to "loose" the subject of the thread to tell you how others
> > solve the same problem.
>
> >> This mail is indeed earmarked for the FAQ!
>
> > :)
>
> >> Thanks,
>
> >> Dale

> >> ----- "Mariano Martinez Peck" <marianop...@gmail.com> wrote:
>
> >> | On Fri, Dec 18, 2009 at 9:33 PM, Dale Henrichs

> >> | <dale.henri...@gemstone.com>wrote:

[Mariano Martinez Peck]

On Sun, Jan 17, 2010 at 2:00 AM, Dale <dale.h...@gemstone.com> wrote:

I'll have to take a detailed look at this...could you tell me what
version of Metacello you are using?

The last one 21
 

I'll try to reproduce the problem and analyze what's going on...

Thanks Dale. For the moment the solution is to commit all the rest with OB 1.1. So...at least I have a quick fix :)

Cheers

Mariano
 

[Dale]

I've been able to reproduce this problem see Issue 49

[Mariano Martinez Peck]

Cool.  I am not crazy then :)

Thanks

Mariano