Martin,
I have been following this work that Shura is doing. The checks are
fairly expensive, and we would not want to perform them during routine
test execution.
However, one option would be to include a separate binary in the jtreg
family, that can be run separately.
There are no plans at this stage to make any significant changes to the
jtreg test execution model, such as executing each test in its own module.
-- Jon
On 3/15/18 7:14 PM, Martin Buchholz wrote:
Interesting.
Is the end goal to have jtreg itself validate the @modules tag or to
execute each test as its own module? It seems like the sort of checking
your tool is doing belongs in jtreg itself.
On Thu, Mar 15, 2018 at 5:12 PM Alexandre (Shura) Iline <
alexandre.il...@oracle.com> wrote:
Martin,
On Mar 15, 2018, at 4:30 PM, Martin Buchholz <marti...@google.com> wrote:
How did you find the missing module dependencies?
I have a tool which runs tests one by one like this (I am simplifying):
- run test with -javaoptions:”—limit-modules …” with only the modules
listed through @modules
- if fails, run test with no —limit-modules
- if passes, that is a potential problem.
We are thinking about making the tool open-source in code-tools project in
one form or another.
Tool aside, everybody is free to use —limit-modules on a newly created
test.
Why was it only noticed now?
It was not - I have just gotten around fixing it. There are more known
@module deficiencies right now.
Can we automatically prevent backsliding?
That would be a job for a continuous integration system, I imagine.
Shura
On Thu, Mar 15, 2018 at 3:40 PM Alexandre (Shura) Iline <
alexandre.il...@oracle.com> wrote:
Hi,
Please take a quick look on fix adding missing module dependencies to
tests in :tier1 jdk tests.
Webrev: http://cr.openjdk.java.net/~shurailine/8199616/webrev.00
Shura.
