[Glass] Another metacello loading puzzle: xml

[Iwan Vosloo via Glass]

Hi Dale,

Thank you. I could spend more time on this today.

On 17/01/2018 17:43, Dale Henrichs via Glass wrote:
> I see that you are using a filetree cache now, which is clever, but 
> because .mcz files does not have a consistent file/package naming 
> convention, when the Sport package is converted to filtree, which _does_ 
> have an enforced package naming convention it runs into the consistency 
> check error for filetree:( Between the "corrupt" .mcz files and 
> improperly named .mcz files you are caught between a rock and a hard place.

Yes, you're right - I sit on the one hand with the character encoding in 
some mcz's that won't be supported on gemstone, and then the naming of 
Sport which is not allowed by filetree.

> 
> Now it turns out I've already moved Sport to a github project[1] and the 
> github project for Sport does not have this inconsistency[2]. It looks 
> like I renamed the Sport3.010.v3 package to Sport.v3 and you might be 
> able to pull off the same trick by renaming the package in the hyper 
> project[1] and whatever ConfigurationOf that references it - but this is 
> wandering into complicated territory that is only becoming a problem 
> because you are trying to use a filetree cache ... If this is the very 
> last problem, then it might be worth it ...

I suspect this is indeed the last remaining issue, so I tried using your 
Sport from github. The only thing I am aware of that relies on Sport is 
GLASS itself. Since we have a local clone of the master branch of the 
github glassdb/glass repository, I edited its baseline to include a 
baseline:

   baseline: 'Sport'
      with: [ spec repository: 'github://GsDevKit/Sport:master/src'  ];

... instead of the package it currently pulls from 
http://seaside.gemtalksystems.com/ss/hyper

In its #gs3.x section, I commented out the package it defined:

"  package: 'Sport' with: [ spec file: 'Sport3.010.v3-jupiter.33' ];"

Having done this, on my extracted version on GitHub, I have managed to 
get it to load overNetwork and NOT overNetwork.

I wasn't sure that commenting out the package above was the right thing 
to do. Perhaps you can advise?

I suppose I could also use GsDevKit/GsDevkit, but am a little wary of 
doing that just yet, because (a) according to its readme it is 
experimental and (b) I don't know how using it will work when I load it 
into a stone that has an older version loaded from glassdb/glass. If you 
think I should rather switch, and have solutions to my worries here, I'd 
love to know.

Anyways, I am still having trouble when I put all this stuff back into 
our project... a problem I had before also. If the above solution solves 
the basic loading issues, and I can get it to load in our project I 
would prefer to stick to this route for now and wait to see how your 
future plans turn out.

That decision depends on whether I can get it to load when everything is 
copied back into our project. Something that is supposed to work, but 
for some reason just does not. I would appreciate it if you have any 
insights in to this issue....just maybe its not a big deal??? The 
transcript and stack for this is on pastbin [1]


[1] https://pastebin.com/Jp3kxUAR


Thank you
- Iwan


--