I think the devil is definitely in the details. I see why Steve decided to use a Map now. Here's the next issue:
Both the system bootstrap repo and the application repo can have proxy settings associated with them and they may not be the same. Fine with me that's just 8 more properties 4 for each repo to parameterize: the host, port, username and password for both system and application repositories. I will add the extra properties. However when accessing these values within the KernelConfig bean I will use an application ProxyContext accessor and a system ProxyContext accessor rather than accessing each property of a ProxyContext individually. We need to devise defaulting behaviors that take into account property inheritance. To clarify consider the checkbox for setting the shipping address equal to the billing address on websites. We need this kind of defaulting behavior to minimize the property setup overhead. Now with these extra proxy properties I think it is fitting. For example in the absence of application repository properties we can presume the inheritance of system repository property values. We do not have to define the policy in this specific way but it's just an example. The use of macro expansion within the properties file will be a big benefit for things like: merlin.application.repository.proxy.host = ${merlin.system.repository.proxy.host} This way defaulting behavior can in many ways be specified within the always present baseline merlin.properties file packaged into the jar. Rather than hard code the logic we can express it via properties using macro expansion. This way some defaulting behavior changes for property values need not require a recompile and maintaining props is much easier. Alex P.S. For those on both lists please forgive the echo onto the LDAP list and the replication it causes - I just want LDAP people to have a record of the things we are doing to further both projects.