RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences
Alexandre (Shura) Iline
alexandre.iline at oracle.com
Wed May 4 15:55:08 UTC 2016
This makes sense - I will move the tests into a subduer, put the dependencies into a TEST.properties file.
jdk.zipfs has the code needed for access jars - the tests are failing without that dependency.
Shura
> On May 4, 2016, at 8:30 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> On 4 May 2016, at 14:32, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 04/05/2016 11:24, Chris Hegarty wrote:
>>> :
>>> The tests cause compilation of test library classes, but only some tests
>>> actually use the methods that provoke compilation. Similar to above, tests
>>> that don’t actually compile anything could depend on just java.compiler.
>>>
>>> This is all to fragile and may cause problems with future refactoring. I
>>> think we should add the same set of @moduels to all these tests, rather
>>> than an individual set determined by intimate knowledge of the inner
>>> workings of the test.
>>>
>>> @modules java.compiler
>>> jdk.compiler
>>> jdk.zipfs
>>> jdk.jartool
>>>
>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.
>>>
>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server.
>
> I think that would be better.
>
> -Chris.
More information about the core-libs-dev
mailing list