You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2018/09/01 22:16:00 UTC
[jira] [Comment Edited] (DERBY-6945) Re-package Derby as a
collection of jigsaw modules
[ https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16599815#comment-16599815 ]
Rick Hillegas edited comment on DERBY-6945 at 9/1/18 10:15 PM:
---------------------------------------------------------------
Attaching derby-6945-49-aa-runSomeTestsWithModulePath.diff. This patch makes it possible to run many tests using the module path. Sample tests I tried included sql and java tests which are run under the old harness and JUnit tests. With this patch, the regression tests ran cleanly when executed the old-fashioned (classpath-based) way.
This patch makes the following changes:
1) The engine module exports more internal api packages for use by query plans which are code-generated into the unnamed module. These packages popped up as I ran more tests with the module path.
2) The shared module exports org.apache.derby.shared.common.error for use by query plans.
3) The server module needs to expose another package to the engine module. One of the sample tests disclosed this need.
4) Formatting nit.
5) The test harnesses now build module-aware JVM boot commands when they themselves are started with a module path.
In order to run tests with a module path, first point the MODULE_PATH variable at all the jars in the jars/sane directory and in tools/java. That is, set MODULE_PATH to a colon-separated list of all those jars.
Then, to run old-harness tests with a module path, issue the following command, where $SINGLE_TEST is a test name like lang/aggregateOptimization.sql:
{noformat}
java -p $MODULEPATH \
--add-modules org.apache.derby.tests,junit \
-m org.apache.derby.tests/org.apache.derbyTesting.functionTests.harness.RunTest \
$SINGLE_TEST
{noformat}
To run a JUnit test with the module path, issue the following command, where $SINGLE_TEST is a test name like org.apache.derbyTesting.functionTests.tests.lang.AggBuiltinTest:
{noformat}
java -p $MODULEPATH \
--add-modules org.apache.derby.tests \
-m junit/junit.textui.TestRunner \
$SINGLE_TEST
{noformat}
In later patches, I will work toward the goal of running all tests cleanly both the old way (with classpaths) and the new way (with module paths).
Touches the following files:
{noformat}
--------------------------------
M java/org.apache.derby.engine/module-info.java
(1) Expose more packages for use by query plans which are code-generated
into the unnamed module.
--------------------------------
M java/org.apache.derby.commons/module-info.java
(2) Expose more packages for use by query plans which are code-generated
into the unnamed module.
--------------------------------
M java/org.apache.derby.server/module-info.java
3) Export another package to the engine module.
--------------------------------
M java/org.apache.derby.tools/org/apache/derby/impl/tools/sysinfo/Main.java
4) Formatting nit.
--------------------------------
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/FileCompare.java
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/RunTest.java
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jvm.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/BaseTestCase.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/DerbyConstants.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/SecurityManagerSetup.java
5) Start child processes with a module path when the harnesses themselves are
booted with a module path.
{noformat}
was (Author: rhillegas):
Attaching derby-6945-49-aa-runSomeTestsWithModulePath.diff. This patch makes it possible to run many tests using the module path. Sample tests I tried included sql and java tests which are run under the old harness and JUnit tests. With this patch, the regression tests ran cleanly when executed the old-fashioned (classpath-based) way.
This patch makes the following changes:
1) The engine module exports more internal api packages for use by query plans which are code-generated into the unnamed module. These packages popped up as I ran more tests with the module path.
2) The shared module exports org.apache.derby.shared.common.error for use by query plans.
3) The server module needs to expose another package to the engine module. One of the sample tests disclosed this need.
4) Formatting nit.
5) The test harnesses now build module-aware JVM boot commands when they themselves are started with a module path.
In order to run tests with a module path, first point the MODULE_PATH variable at all the jars in the jars/sane directory and in tools/java. That is, set MODULE_PATH to a colon-separated list of all those jars.
Then, to run old-harness tests with a module path, issue the following command, where $SINGLE_TEST is a test name like lang/aggregateOptimization.sql:
{format}
java -p $MODULEPATH \
--add-modules org.apache.derby.tests,junit \
-m org.apache.derby.tests/org.apache.derbyTesting.functionTests.harness.RunTest \
$SINGLE_TEST
{format}
To run a JUnit test with the module path, issue the following command, where $SINGLE_TEST is a test name like org.apache.derbyTesting.functionTests.tests.lang.AggBuiltinTest:
{noformat}
java -p $MODULEPATH \
--add-modules org.apache.derby.tests \
-m junit/junit.textui.TestRunner \
$SINGLE_TEST
{noformat}
In later patches, I will work toward the goal of running all tests cleanly both the old way (with classpaths) and the new way (with module paths).
Touches the following files:
{noformat}
--------------------------------
M java/org.apache.derby.engine/module-info.java
(1) Expose more packages for use by query plans which are code-generated
into the unnamed module.
--------------------------------
M java/org.apache.derby.commons/module-info.java
(2) Expose more packages for use by query plans which are code-generated
into the unnamed module.
--------------------------------
M java/org.apache.derby.server/module-info.java
3) Export another package to the engine module.
--------------------------------
M java/org.apache.derby.tools/org/apache/derby/impl/tools/sysinfo/Main.java
4) Formatting nit.
--------------------------------
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/FileCompare.java
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/RunTest.java
M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jvm.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/BaseTestCase.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/DerbyConstants.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
M java/org.apache.derby.tests/org/apache/derbyTesting/junit/SecurityManagerSetup.java
5) Start child processes with a module path when the harnesses themselves are
booted with a module path.
{noformat}
> Re-package Derby as a collection of jigsaw modules
> --------------------------------------------------
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.13.1.2
> Reporter: Rick Hillegas
> Priority: Major
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff, derby-6945-02-ab-newDerbySharedJar.diff, derby-6945-02-ac-newDerbySharedJar.diff, derby-6945-03-aa-partitionTest.diff, derby-6945-04-aa-moveRunClass.diff, derby-6945-05-aa-removeRedundant_Attribute_SQLState.diff, derby-6945-06-aa-removeOtherSharedDuplicates.diff, derby-6945-07-aa-net_client_overlap.diff, derby-6945-08-aa-move_shared_iapi_under_shared.diff, derby-6945-08-ab-move_shared_iapi_under_shared.diff, derby-6945-08-ad-move_shared_iapi_under_shared.diff, derby-6945-09-ab-moveInternalDriver.diff, derby-6945-10-aa-moveDriver42.diff, derby-6945-11-ab-moveAutoloadedDriver.diff, derby-6945-12-ab-moveClientDataSourceInterface.diff, derby-6945-13-aa-create-ClientAutoloadedDriver.diff, derby-6945-14-aa-moveMoreEmbeddedClassesOutOfPublicAPI.diff, derby-6945-15-aa-moveMoreClientClassesOutOfPublicAPI.diff, derby-6945-16-aa-consolidatePublicAPI.diff, derby-6945-17-aa-resealPackagesIn-derbyshared.diff, derby-6945-18-aa-resealLocalizationPackage.diff, derby-6945-19-ad-movePublicAPIintoToolsJar.diff, derby-6945-20-aa-removeClasslister.diff, derby-6945-21-aa-simplifyBuildScripts.diff, derby-6945-21-ab-simplifyBuildScripts.diff, derby-6945-22-ad-isolateClassesByArtifact.diff, derby-6945-22-ae-isolateClassesByArtifact.diff, derby-6945-22-af-isolateClassesByArtifact.diff, derby-6945-23-aa-upgradeToAnt_1.10.2.diff, derby-6945-24-aa-fixNativeAuthenticationServiceTest.diff, derby-6945-25-ab-moduleDescriptors.diff, derby-6945-26-aa-packagePrivateTests.diff, derby-6945-27-aa-adjustModulesForTests.diff, derby-6945-28-aa-testingModuleDescriptor.diff, derby-6945-29-aa-disable-SimpleApp-test.diff, derby-6945-30-ab-move-clientmessages-toolsmessages.diff, derby-6945-31-aa-clientmessages-ResourceBundleProvider.diff, derby-6945-32-aa-messageLookupCleanup.diff, derby-6945-33-ab-moveLocalizations.diff, derby-6945-34-aa-licenseHeaders.diff, derby-6945-35-aa-removeSpuriousCharacter.diff, derby-6945-36-aa-moduleDescriptorsForLocaleJars.diff, derby-6945-38-aa-javadocCleanup.diff, derby-6945-39-aa-javadocCleanup.diff, derby-6945-40-aa-generatedSource-dirNames.diff, derby-6945-41-ac-cleanupProductJavadoc.diff, derby-6945-42-aa-cleanupTestJavadoc.diff, derby-6945-43-aa-cleanupPublicAPIforJavadoc.diff, derby-6945-44-aa-moduleAwareJavadoc.diff, derby-6945-45-aa-fixWarnings.diff, derby-6945-46-aa-jacocoSourceRoots.diff, derby-6945-47-aa-runModulesWithLocalizations.diff, derby-6945-48-ac-serverWithSecurityPolicy.diff, derby-6945-49-aa-runSomeTestsWithModulePath.diff, derby-6945-XX-moveDataSourceFactories, jdeps.out.tar, weirdAnt.out
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider re-packaging Derby as a set of jigsaw modules. This would result in a different set of release artifacts. This might be a good opportunity to address the Tomcat artifactory issues raised by issue DERBY-6944.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)