airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <>
Subject Re: Suggestions on maintaining the server/client configuration files?
Date Thu, 27 Mar 2014 02:22:43 GMT
A little update on the efforts on this...

   - Like Amila suggested, ServerSettings now by default supports
   - settings can be added/updated by passing the new settings via command
   line (and incidentally passing them to the static func.
      - $ ./ --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 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
   - 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 <>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 <>wrote:
>> There are several places which we need the and
>> files to be present in order to run tests and
>> standalone servers resulting in replication. Any idea how we should handle
>> this?

View raw message