Hi Saminda, Ideally even at this point we should be able to remove all the configuration files from src/main/resources but for tests we might need the files in src/test/resources.
good thing about this is we have all the configuration in one place (airavata-server.properties) but bad thing is we have to keep it in each module's test configuration. Is this really a problem ? Regards Lahiru On Sun, Mar 30, 2014 at 9:59 PM, Saminda Wijeratne <[email protected]>wrote: > 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 <[email protected]>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 >> <[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? >>>>> >>>> >>>> >>> >> > -- System Analyst Programmer PTI Lab Indiana University
