> Are those system properties already been removed? If so, then maven They have been removed. But the changes haven't been checked in yet. Not until have the substituted functionality.
> - 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 Ideally we don't need more than one repository. All of our modules goes under one repository following the Maven convention. But if there's a need for it, and it's very likely a special case (and very few), then the test will have to add that configuration. > - 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 Both sounds good. > - we may need to prioritize Terracotta usage in embedded mode over > kit-based install. Can you elaborate? > - 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. This also sounds good. I will have to check if KF could handle exploded jars. But first things first - let's implement/decide on our proposed solution. On Oct 1, 2007, at 1:16 PM, Eugene Kuleshov wrote: > > 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
