In another related note I found few places which has additional property
file types present in our trunk, some examples are,
tools/job-monitor/src/main/resources/gsissh.properties
tools/job-monitor/src/test/resources/monitor.properties
tools/phoebus-integration/src/main/resources/service.properties
modules/commons/gfac-schema/src/main/resources/datatype.properties
modules/commons/workflow-tracking/src/main/resources/log4j.properties
modules/orchestrator/airavata-orchestrator-service/src/test/resources/orchestrator.properties
modules/ws-messenger/messagebroker/src/test/resources/unit_tests.properties
modules/test-suite/src/test/resources/unit_test.properties
modules/xbaya-gui/src/main/resources/airavata-client.properties
modules/xbaya-gui/src/test/resources/airavata-server.properties
modules/gfac/gfac-core/src/main/resources/errors.properties
modules/gfac/gfac-core/src/main/resources/service.properties
modules/gfac/gfac-core/src/test/resources/logging.properties
modules/gfac/gfac-core/src/test/resources/airavata-client.properties
I remember we raised an issue relating to having component property files
but not coming to a conclusion regarding it. Any thoughts about it?
On Thu, Mar 27, 2014 at 9:23 PM, Saminda Wijeratne <samin...@gmail.com>wrote:
> 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 <samin...@gmail.com>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 <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?
>>>>
>>>
>>>
>>
>
