I'm on the verge of making a change that will accomplish the following goals:
1) Remove from the test framework any usage of the tc.install-root system property. The tc.base-dir system property is required for the tests and an exception will be thrown if tc.install-root is set. 2) Cleans up the integration module resolver: * if tc.install-root is set, inject tc.install-root/modules as a default module repository * if the system property com.tc.l1.modules.repositories is set, inject the comma-separated list of URL's as repositories * inject default modules as specified by the OSGI bundle specifications from the system property com.tc.l1.modules.default * inject additional modules as specified by the OSGI bundle specifications from the system property com.tc.l1.modules.additional * Removes any usage of any other system property that was being used to add additional repositories/modules What this means for non-kit based usage of Terracotta is that you must find a way to specify a value for com.tc.l1.modules.repositories that will result in the required default bundles being resolved. For the TC Maven plugin this means seeing that it is set to the Maven repo of the user's choice. For Geronimo, this means setting it to GERONIMO_HOME/repository. Here is the pertinent section of tc.properties: ########################################################################################### # Section : L1 Integration Modules # Description : This section contains the defaults for the L1 integration modules # repositories - comma-separated list of additional module repositories URL's; # if the tc.install-root system property is set, a default repository # of (tc.install-root)/modules will be injected # default - comma-separated list of integration bundles that are implicitly loaded by the # L1 in the form specified by the Required-Bundles OSGI manifest header # additional - list of additional integration modules to be started, in the form specified by # the OSGI Required-Bundles manifest header ########################################################################################### l1.modules.repositories = l1.modules.default = org.terracotta.modules.excludes_config;bundle-version:="1.0.0",org.terracotta.modules.guimodels_config;bundle-version:="1.0.0",org.terracotta.modules.jdk15_preinst_config;bundle-version:="1.0.0",org.terracotta.modules.spring_config;bundle-version:="1.0.0",org.terracotta.modules.standard_config;bundle-version:="1.0.0" l1.modules.additional = Any questions or concerns? After this, CDV-435 will be dealt with. ----- Original Message ----- From: "Eugene Kuleshov" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, October 01, 2007 1:16 PM Subject: Re: [tc-dev] Resolver and other properties > > Are those system properties already been removed? If so, then maven > plugin will be broken until there will be some substitution for that > functionality. > > While it is a good idea to clean those system properties, I believe > that it is more critical to fix module versioning issues described in > CDV-435. > > Here are few random observations: > > - can you please elaborate what this mean: "Additional repository > locations should be configured by the test that needs them via code or > the test's config." > - we don't really need more then one repository for resolving modules > > - single l1.configbundles.default property is not enough. Generally, > list of default bundles loaded by the DSO should not be changed, but > additional modules need to be added to that list without changing > tc-config.xml (i.e. when running tc:test), so it is better to have a > separate property like l1.configbundles.additional that would list > additional modules without overwriting l1.configbundles.default > > - slightly related: the format of l1.configbundles.default need to be > unified and it should allow to specify groupId, artifactId as well as > the version ranges. Perhaps we could simple use the same format as the > one used in Required-Bundles > > - we may need to prioritize Terracotta usage in embedded mode over > kit-based install. > > - another important scenario to take into the account is the ability to > run Terracotta with config module that is not packaged as a jar, when > module is being developer and runned from within IDE. That will make it > much easier to debug config modules, especially those that have some code. > > regards, > Eugene > > > Juris Galang wrote: >> Gary and I have been working last Friday on cleaning up the Resolver >> class and our use of various System properties when using the config >> modules under test and live environment. >> >> What it boils down to is that we made the Resolver (and related >> classes) be ignorant that there is a test scenario at all. >> >> This means that references to System properties like >> tc.tests.configuration.modules and tc.tests.configuration.modules.url >> are no longer used. >> >> By default config-modules are expected to be found in the default >> modules repository, ie: the base directory + "/modules" --- In our >> kit, the base directory would be wherever Terracotta was installed >> ($TC_INSTALL_DIR), and during tests this is the 'build/' directory. >> >> Additional repository locations should be configured by the test that >> needs them via code or the test's config. >> >> With our Maven plugins there is no kit, and that it could execute in >> either the live or test scenario (as in the case of the Geronimo >> plugin) - so the $TC_INSTALL_DIR property may or may not exist and >> the Resolver can't correctly assume the location of the modules >> repository. >> >> Here's what we propose: >> We add a new TC property called l1.configbundles.repos (the name >> could change) - this is a comma-separated list of additional >> repository locations that will be tacked on the list of repositories >> used when locating config modules. >> >> This is no different than the l1.configbundles.default property - a >> list of config modules which gets loaded no matter what the current >> scenario is - so it should work across the board and for our Maven >> plugins scenario. >> >> Thoughts? >> >> > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
