> On Mar 15, 2018, at 7:14 PM, Martin Buchholz <marti...@google.com> 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.
That is indeed one of the options we are discussing. Shura > > > On Thu, Mar 15, 2018 at 5:12 PM Alexandre (Shura) Iline > <alexandre.il...@oracle.com <mailto:alexandre.il...@oracle.com>> wrote: > Martin, > > >> On Mar 15, 2018, at 4:30 PM, Martin Buchholz <marti...@google.com >> <mailto: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 <mailto: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 >> <http://cr.openjdk.java.net/~shurailine/8199616/webrev.00> >> >> Shura. >> >
