[kepler-dev] Configuration

[David Welker]

On Mon, Nov 23, 2009 at 1:23 PM, Chad Berkley <berkley at nceas.ucsb.edu>wrote:

>
>
> 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.
>

That really does not justify making a system that is less flexible when it
really isn't much work to do it right. I do not think we should be referring
to module names in the code, and there really is no reason to.



>
>> 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.
>

Great. So, if you are never going to write to modules, then you don't need
to refer to them by name in the code...



>
>
>> 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.
>

Default rules are very powerful. The default tends to turn into the
practical reality. So, you should say that something is "just" a default.
You should recognize that if something is the default, then it will be the
most commonly chosen alternative in the overwhelming majority of cases.
Also, why allow exceptions at all if they unnecessarily hinder higher-level
architectural changes? It would be better to require every configuration
file to have a namespace. If the default is to use the module name as the
namespace, then the result will be code that is fragile. One should be able
to experiment with moving code into different modules without breaking the
code.

Requiring every configuration file to have a namespace would add practically
no additional work for configuration file writers. Alternatively, if you
want a default, make it something other than the module name, like "default"
or "common" (where "common" does not refer to the "common" module but
instead the "common" namespace.

I know this for a fact: We have not yet come with an ideal division of
Kepler into modules. Why would we decide to tightly couple the code with
module names? This whole problem could be easily solved by requiring every
configuration file to explicitly specify a namespace.

Also, the argument that most of the configuration will be in the common
module is more an argument against the utility of namespaces than it is an
argument that it doesn't matter if module names are hardcoded into .java
files.


>  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.
>

Yes. But package names do not have to correspond with module names. Just
because code is the common module, that does not mean that the package has
to be "org.kepler.common" or anything like that. Also, IDEs like eclipse and
Intellij IDEA  make refactoring very trivial. There will be no tools that
automatically do the refactoring you propose to cause to be necessary.


> 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.
>

I don't want a virtualized module naming system. I want namespaces that are
totally decoupled from module names so that module names do not end up being
hard coded into .java files.

Look, this is very easy to implement. The configuration manager does not
need to know what module particular configuration comes from. At startup,
the configuration manager could simply read all of the configuration files,
which can be stored in particular locations by convention.



> 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
>>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20091123/185b78a5/attachment.html>