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. >> >> >
