Hi Dale,
I believe the original problem is that you do not know upfront about
where the actual files will be. In this case, perhaps the easiest
solution is to provide some scripting facility to provide a repository
mapping that should could be modified at loading time, and not be
stored in the actual configuration.
Suppose you have something like this:
ConfigurationOfXXX>>baselineX: spec
<version: 'X-baseline'>
spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ].
...
ConfigurationOfXXX>>versionX: spec
<version: 'X' imports: #('X-baseline')>
spec package: 'SomePackage' with: 'SomePackage.tg.1'.
...
Maybe a solution would be that when loading you could say:
(ConfigurationOfXXX project version: 'X')
withRepositoryMapping: 'SOME_URL' -> 'SOME_NEW_URL';
withRepositoryMapping: '...' -> '...';
load
What do you think?
In this way, the original configuration specifies everything, and the
URL works either as the actual URL or as an alias that can be mapped
to something else later on when you know the actual URL. Actually,
this can already be accomplished at engine level. I believe a simple
scripting like above would just make it practical. What do you think?
Cheers,
Doru
On 23 Feb 2010, at 21:18, Dale Henrichs wrote:
>
> ----- "Lukas Renggli" <[email protected]> wrote:
>
> | > Perhaps Gofer can be provided with a secondary repository location
> | in the case when the primary repository fails.
> |
> | Yes, it can. You just specify multiple repositories and it will use
> | them all. If you tell Gofer to #disableRepositoryErrors then it will
> | silently ignore repositories that are not available.
>
> Lukas,
>
> The only thing that worries about including such repository all of
> the time, is the cost of building the cache of repository when
> resolving repositories ... the secondary repository would get pretty
> large over time and most of the time (only in the case of errors)
> would it need to be scanned.
>
> I suppose Metacello could handle load errors in the code that calls
> Gofer and do a retry using the secondary repository...the secondary
> repository _could_ be specified as part of the configuration, so
> this probably isn't a bad idea...
>
> Thanks,
>
> Dale
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
