One way which so far seems to work is to define 2 maven modules airavata-server-configuration and airavata-client-configurations as jar artifacts where each will have the respective configuration files. Then use them as dependencies for the modules which require the relevant configurations. For the binary distributions we will have to use the assembly-plugin and/or the dependency-plugin to copy the configuration files in to the correct location in the distribution directory.
I'm still working on how this solution can be adhered when running unit tests. At the moment the the duplicated configuration files in src/test/resources only has a few changes compared to the distributed configurations. Any thoughts? On Wed, Mar 26, 2014 at 10:22 PM, Saminda Wijeratne <[email protected]>wrote: > 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 > <[email protected]>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 <[email protected]>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? >>> >> >> >
