[kepler-dev] Configuration

[Chad Berkley]

Hi,

After looking at this a bit more, there are a few options for how to do 
it.  There are tradeoffs for each.

1) store a module's alias(es) in module-info/aliases.txt
    - pro: a module can have one or more aliases and define them itself
    - con: conflicts may occur between modules because a module might be 
unaware of another module's alias
    - con (or pro): developer is responsible for setting an alias
2) have an alias list in the build-area/settings
    - pro: centralized location for alias information
    - con: devs would have to alter the build-area to add an alias
3) use a naming scheme to determine an alias.  For instance, "common" 
would be a default alias for a module named "common-1.0.0rc1"
    -pro: no list is kept or parsed.
    -con: only one alias is allowed per module (might be a pro too)
    -con: incorrectly named modules will need to be renamed or won't work

These are the three schemes I cam up with.  If you have any other ideas, 
let me know.  I'm leaning toward #3 because I think it's simple and does 
what we need without having to add more configuration information.  I'll 
hold off on implementation until we resolve this.

chad


Chad Berkley wrote:
> Yeah, I'm working on it.  Hopefully I'll get it going today or tomorrow. 
>  I'll let you know asap.
> 
> chad
> 
> 
> David Welker wrote:
>> Hi Chad,
>>
>> Sean Riddle mentioned that you were planning on changing the 
>> configuration system so it does not refer to specific modules. Do you 
>> know when this will be done? The kepler-1.1 branch does not currently 
>> work, because the module "common" is referred to, when what is 
>> available is "common-1.0."
>>
>> Is there anything I can do to help? I am pretty much stuck in terms of 
>> publishing something that works until we get this to work, because I 
>> am loathe to change the actual source code that refers to specific 
>> module names in the kepler-1.1 branch unless it is absolutely 
>> necessary, because this will continually complicate any attempt to 
>> merge branches with the trunk, as will be periodically necessary for 
>> patches.
>>
>> Thanks!
>>
>> David
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev