Gary Keim wrote: > 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. > Gary, can you please remind me why we need to set these properties, especially when running tests and why this scenario should be different from the one described below? More over, when running tests from within /code/base dir you can get location of tc.base-dir simply by looking at there class or jar files came from. > 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. > Makes total sense. Though I have one important clarification.
By default these config modules should be using versions like 1.0.0-SNAPSHOT (we have another JIRA for that) and the same version should be specified in the manifest for config bundles. Here is it when it comes to the tricky part, because OSGi don't allow versions like 1.0.0-SNAPSHOT and it will need to be mapped to something like 1.0.0.SNAPSHOT, so jar file for that version will still look like excludes_config-1.0.0-SNAPSHOT.jar regards, Eugene _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
