>> If both configurations reference the same Grease version, there will not be 
>> a problem.
>> 
> Can you do that? I don’t have commit rights for those repos.

No, I am not an author of either projects.... I guess it's best if Magritte 
references Grease #stable. Though I concur with your remark regarding symbolic 
versions, it also becomes hell if different projects reference different 
versions of Grease, just because those were the stable versions when they were 
created (which is actually the problem here).

I'm on iPad only right now, so can't help you any further before tonight.

>> However, this is a more fundamental problem. Metacello first loads 1.1.5 and 
>> then loads 1.1.6, which has moved classes between packages, leading to a 
>> temporary (i.e. during load) dirty package, leading to the Monticello 
>> warning.
>> 
>> You can also try to change the metacello loadType to #atomic instead of 
>> #linear.
>> Finally, you can also wrap an exception handler around the load statement.
>> 
> Yeah, I wanted to do that. But then I changed my workflow to use zero conf 
> scripts and that whole problem handling you loose by using the „modern“ 
> workflow.

I also wonder if the Metacello scripting API has a handler for this situation 
(i.e. suppressing errors)


> 
> Norbert
> 
>> Johan
>> 
>> Sent from my iPad
>> 
>>> On 21 Mar 2014, at 09:20, Norbert Hartl <norb...@hartl.name> wrote:
>>> 
>>> What should be changed in order to solve it?
>>> 
>>> Norbert
>>> 
>>>> Am 20.03.2014 um 17:09 schrieb Johan Brichau <jo...@inceptive.be>:
>>>> 
>>>> Found it:
>>>> 
>>>> Magritte3 references Grease1.1.5 explicitly
>>>> MongoTalk references Grease #stable
>>>> 
>>>> Looks more like a Metacello bug to me... there clearly is a load conflict 
>>>> and Metacello should decide on a version rather than load them both 
>>>> sequentially.
>>>> But I have not looked any deeper....
>>>> 
>>>> Johan
>>>> 
>>>>> On 20 Mar 2014, at 17:02, Johan Brichau <jo...@inceptive.be> wrote:
>>>>> 
>>>>> I can reproduce the problem. 
>>>>> For some strange reason, first Grease 1.1.5 is loaded and then 1.1.6 is 
>>>>> loaded (in the same metacello load of VoyageMongo).
>>>>> 
>>>>> The package becomes dirty because some classes changed from the Pharo20 
>>>>> package in 1.1.5 to the Core package in 1.1.6.
>>>>> Because Metacello first loads the Core package, the Pharo20 package 
>>>>> becomes dirty. When the new version of the Pharo20 package is loaded, 
>>>>> Monticello raises the warning.
>>>>> 
>>>>> I have noticed a similar issue when upgrading versions of Zinc in 
>>>>> Pharo1.4 because significant package refactorings occurred.
>>>>> So, this is nothing specific to Grease / Magritte / Seaside / ...
>>>>> 
>>>>> I wonder if this can be simply fixed by changing the load type to 
>>>>> #atomic. At least, that is how I fix those issues when loading Yesplan in 
>>>>> Gemstone.
>>>>> But clean builds work perfectly. And I would want to know why first 
>>>>> version 1.1.5 is loaded in this load process.
>>>>> 
>>>>> Johan
>>>>> 
>>>>>> On 20 Mar 2014, at 16:39, Johan Brichau <jo...@inceptive.be> wrote:
>>>>>> 
>>>>>> Norbert,
>>>>>> 
>>>>>> From your screenshot, I see that the Grease package you have loaded in 
>>>>>> your image is dirty. It is also the package version that gets loaded 
>>>>>> with Grease 1.1.5.
>>>>>> My first question is: why is it dirty? Can you check that?
>>>>>> 
>>>>>> The package version you are loading is the one that is referenced by 
>>>>>> Grease 1.1.6
>>>>>> 
>>>>>> I just tagged Grease 1.1.6 as #stable yesterday. So that probably 
>>>>>> triggers this.
>>>>>> 
>>>>>> Though I cannot see any reason why this occurs and Seaside 3.1 is 
>>>>>> loading well here.
>>>>>> 
>>>>>> Johan
>>>>>> 
>>>>>>> On 20 Mar 2014, at 15:47, Norbert Hartl <norb...@hartl.name> wrote:
>>>>>>> 
>>>>>>> I encountered a strange problem while loading voyage. It seems the 
>>>>>>> configuration for magritte or grease is strange. If I load voyage from 
>>>>>>> the configuration browser I get the following screen
>>>>>>> 
>>>>>>> <Bildschirmfoto 2014-03-20 um 15.43.56.png>
>>>>>>> 
>>>>>>> Any ideas?
>>>>>>> 
>>>>>>> Norbert
>>> 
>>> 
>> 
> 
> 

Reply via email to