> | >
> | > At ESUG when I said that I didn't like the split that I had ... The
> | > package spec is one of the areas that may or may not have some
> | > commonality ... I found quite a bit that could be moved from MC to
> | > Core for projects, but not being familiar with your needs for
> | > packages, I wasn't able to see much commonality ... off the bat
> | > ... looking at your implementation of packages may reveal some
> | > common code ...
> |
> | Ok, that means I have to bake this cake completely myself :-)
>
> Nope, I think that we can extract out big hunks of code that you can leverage.
>
> |
> | What I basically need is to "resolve" whole project spec into flat
> | (ideally topologically ordered) list of package thingies
> | (say MetacelloStXPackage) with all the properties.
>
> Yes, this bit can be extracted out ... I can take a stab at extracting out the code that you need ... it will be a combination of package code and some loader code ... you will be rolling your own loader, but I can certainly tease out the important bits ... I'm kinda busy this week tho.

>
> |
> | While I can imagine how and where to hook in my MetacelloStXPackage
> | and MetacelloStXPackageSpec, I've got lost how and where to get
> | the list (or something from which I can easily construct such a list)
> |
> | Maybe you can give me some pointers - classnames where to start
> | reading should be enough...
>
> Okay...I can do that ... I'll put together a method/class reading list with the important bits about producing the ordered list of packages ... should be able to have it for you tomorrow morning.