A little update on the efforts on this...
- Like Amila suggested, ServerSettings now by default supports
parameterization
- settings can be added/updated by passing the new settings via command
line (and incidentally passing them to the static func.
ServerMain.main(...)).
- $ ./airavata-server.sh --myproxy.user=saminda --myproxy.pass=pass123
- Introduced ServerSettings.mergeSettings...(...) functions to help
add/update settings through Maps, command line args, additional prop files.
The issue that I'm still facing is the duplication of the
airavata-server.properties configuration file in the code base. Last time I
checked copies of it is spread out at 14 locations in the trunk (for
running junit tests, in standalone server dist, in integration tests, in
sample gateway).
- config files in a single location in the trunk and refer to them using
relative paths:
- done using the maven-builder-helper plugin.
- But it seems the IDEs doesn't recognize resources outside the
project folder.
- "git subtrees" (which allows two way code sharing) similar to "svn
externals":
- the limitations in it (configs needs to be in a different repo,
subtree will be merged on the root, cannot specifically select which code
to share?), it seems its not a viable option.
any ideas?
On Thu, Mar 6, 2014 at 1:55 PM, Amila Jayasekara <thejaka.am...@gmail.com>wrote:
> Hi Saminda,
>
> I guess the best thing is to create template configuration files in a
> central location and replace needed variables within the test
> initialization and place generated config files within the target directory
> of the test case.
>
> E.g :- registry.url = ${registry.url}
>
> ${registry.url} is replaced within the test case with appropriate value.
> Then we dont need to duplicate configuration files in everywhere. Also when
> a configuration is updated we only need to change in a single place.
> You may encapsulate template parameter replacing logic into a common util
> class so that each test case can just invoke the logic.
>
> Further we should have a single place to read all configurations and all
> subcomponents must go through this configuration component to get config
> values. Otherwise it will be hard to maintain the configuration reading
> code.
>
> Thanks
> Amila
>
>
> On Thu, Mar 6, 2014 at 1:38 PM, Saminda Wijeratne <samin...@gmail.com>wrote:
>
>> There are several places which we need the airavata-server.properties and
>> airavata-client.properties files to be present in order to run tests and
>> standalone servers resulting in replication. Any idea how we should handle
>> this?
>>
>
>
