Knopflerfish does NOT support exploded archives yet. http://sourceforge.net/tracker/index.php?func=detail&aid=1703244&group_id=82798&atid=567241
----- Original Message ----- From: "Juris Galang" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, October 01, 2007 1:48 PM Subject: Re: [tc-dev] Resolver and other properties >> 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 > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
