[Glass] Another metacello loading puzzle: xml
Iwan Vosloo via Glass
glass at lists.gemtalksystems.com
Mon Jan 22 07:40:52 PST 2018
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 and the
> github project for Sport does not have this inconsistency. 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 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
with: [ spec repository: 'github://GsDevKit/Sport:master/src' ];
... instead of the package it currently pulls from
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 
More information about the Glass