[
https://issues.apache.org/jira/browse/DERBY-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16707969#comment-16707969
]
Rick Hillegas commented on DERBY-7011:
--------------------------------------
I ran the two modulepath test targets on an Ubuntu 14.04.03 guest operating
system on VirtualBox on a Windows 10 host:
{noformat}
test-derbyall-with-modulepath
test-junit-all-with-modulepath
{noformat}
The test-derbyall-with-modulepath target ran fine right away. However, it took
me a while to get test-junit-all-with-modulepath to run to completion. It kept
exhausting swap space. Eventually, I cleared up 8GB on the disk and then
test-junit-all-with-modulepath ran fine.
One significant difference between the classpath and modulepath JUnit tests is
that the classpath version is split across several targets, each of which
spawns its own JVM. In contrast, the modulepath target runs the entire All
suite in one invocation of JUnit.
It's possible that we are running out of swap space when Jenkins runs the JUnit
tests with the modulepath. Maybe we could improve the stability of these tests
by splitting them into several targets as we do with the classpath JUnit tests.
> Set up a new Jenkins job to run the JUnit tests with a module path
> ------------------------------------------------------------------
>
> Key: DERBY-7011
> URL: https://issues.apache.org/jira/browse/DERBY-7011
> Project: Derby
> Issue Type: Task
> Components: Build tools
> Affects Versions: 10.15.0.0
> Reporter: Rick Hillegas
> Priority: Major
> Attachments: derby-7011-01-aa-shortCircuitAfterDerbyNetSuite.diff,
> derby-7011-02-aa-shortCircuitAfterLangSuite.diff
>
>
> I have set up a new Jenkins job (Derby-trunk-test-junit-all-with-modulepath)
> to run the JUnit tests with a module path. This issue is a place to collect
> feedback on how to finish setting up this job.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
