[kepler-dev] Configuration

[Chad Berkley]

David Welker wrote:
> None of these solutions are ideal, as refactoring is seriously hindered. 
> We should ultimately totally decouple namespaces from module names. All 
> of the configuration files could be read at start time.

Refactoring is refactoring.  If you want to refactor code, you have to 
change stuff.  That's kind of the point of it.  I think we can make 
systems more friendly to refactoring, but we don't have to make it 100% 
flexible.

> 
> Also, remember that it would be improper to write configuration files at 
> runtime. Modules are likely to be read-only, so user preferences should 
> be stored in .kepler or another writable location and NOT in any of the 
> modules.

I never said anything about this.  In fact, the configurationManager 
never writes back to the module directory.  It always serializes to 
.kepler.

> 
> In the short-term, if a more ideal solution would be challenging to 
> implement (I don't think it necessarily would be, but Chad would have a 
> better perspective) solution 3 makes sense as a temporary solution. 
> However, I think before the 2.0 release we should move to a system where 
> namespaces have absolutely nothing to do with module names and are 
> instead read from configuration files.
> 
I don't see how any of the three things I proposed fails to do this.  1 
and 2 both read names from configuration files simply using the module 
name as a default.  We designed the references to modules into the API 
so that one knows where a configuration property is set.  The way we 
were doing it before, you never knew what module was doing what to the 
configuration until you changed something any everything broke.  Using 
the classpath for overriding configuration was a nightmare to debug 
because there was nothing explicitly in the code showing that properties 
(or in fact, entire configuration files) were being overridden.  You can 
now tell exactly where the configuration property is stored and you can 
see it in the code if the property is being overridden.

> Think of it this way. Java Packages are a type of namespace. Yet, the 
> same package can appear in multiple modules and there need be no 
> relation between the package name and the module name. That is what we 
> should aim for with our configuration system.

Java does make some pretty stringent requirements about this.  You have 
to have your classes in the same directory structure as your package 
name.  Classes have to have the same filename as the classname.  If you 
refactor code, you have to change these.  I think what you're talking 
about here is searching the classpath for a class, which is similar to 1 
and 2.

If we truly want a virtualized module naming system, it should probably 
be implemented in the org.kepler.build.module package so that it can be 
used in other parts of the code.  The configuration manager uses that 
code to resolve modules now.

chad


> 
> David
> 
> 
> 
> On Nov 20, 2009, at 4:53 PM, Chad Berkley wrote:
> 
>> 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
> 
>