Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

2017-03-15 Thread Igor Ignatyev
Hi Serguei, 1s of all, thank you for your review. since these tests have dependencies on more modules than corresponding TEST.properties file declares, we have to specify @modules tag in them, and because @modules in a test overrides modules from TEST.properties, jdk.jdi module should be

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

2017-03-15 Thread serguei.spit...@oracle.com
Hi Igor, This looks good to me. A couple of questions below. http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html - * @modules jdk.jdi * @library /test/lib + * @modules java.management + * jdk.jdiShould the jdk.jdi be removed from

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

2017-03-15 Thread Igor Ignatyev
Shura, Thank you for your review. I have update test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked that there are no similar things in other TEST.properties files. Still looking for a review from a Reviewer. [1] > ---

Re: #VersionsInModuleNames

2017-03-15 Thread Stephen Colebourne
On 15 March 2017 at 17:47, Alan Bateman wrote: > This is the consumer choosing a module name for a library that they don't > maintain and renaming that library to match (you are writing the `requires > X` before X exists). All I'm saying is that the library maintainer

Re: #VersionsInModuleNames

2017-03-15 Thread Alan Bateman
On 15/03/2017 17:09, Stephen Colebourne wrote: : The proposal above only applies at runtime, not when authoring. Given a module: module foo { requires bar; } Then the proposal says the requires clause can be satisfied in one of three ways. 1) a real module on the module path named "bar" 2)

Re: RFR [9] 8176772: jar tool support to report automatic module names

2017-03-15 Thread Mandy Chung
> On Mar 15, 2017, at 10:12 AM, Chris Hegarty wrote: > >> >> Is there any reason why this option does not print the synthesized >> descriptor? I understand that the issue is specific to show the derived >> module name. But it’d be nice for this option to print the

Re: RFR [9] 8176772: jar tool support to report automatic module names

2017-03-15 Thread Chris Hegarty
> On 15 Mar 2017, at 16:54, Mandy Chung wrote: > >> >> On Mar 15, 2017, at 8:31 AM, Chris Hegarty wrote: >> >> >>> On 15 Mar 2017, at 14:42, Alan Bateman wrote: >>> >>> On 15/03/2017 14:21, Chris Hegarty wrote: >>>

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

2017-03-15 Thread Alexandre (Shura) Iline
Igor, I have looked through a bunch of tests where @modules is changed - that looks good. One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because “modules”

Re: RFR [9] 8176772: jar tool support to report automatic module names

2017-03-15 Thread Mandy Chung
> On Mar 15, 2017, at 8:31 AM, Chris Hegarty wrote: > > >> On 15 Mar 2017, at 14:42, Alan Bateman wrote: >> >> On 15/03/2017 14:21, Chris Hegarty wrote: >> >>> : >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~chegar/8176772.00/ >>>

Re: RFR [9] 8176772: jar tool support to report automatic module names

2017-03-15 Thread Chris Hegarty
> On 15 Mar 2017, at 14:42, Alan Bateman wrote: > > On 15/03/2017 14:21, Chris Hegarty wrote: > >> : >> >> Webrev: >> >> http://cr.openjdk.java.net/~chegar/8176772.00/ >> https://bugs.openjdk.java.net/browse/JDK-8176772 >> > If findAll returns an empty set then

Re: RFR [9] 8176772: jar tool support to report automatic module names

2017-03-15 Thread Alan Bateman
On 15/03/2017 14:21, Chris Hegarty wrote: : Webrev: http://cr.openjdk.java.net/~chegar/8176772.00/ https://bugs.openjdk.java.net/browse/JDK-8176772 If findAll returns an empty set then the error.unable.derive.automodule message might be more appropriate. Otherwise looks good to me.

Re: #VersionsInModuleNames

2017-03-15 Thread Alan Bateman
On 15/03/2017 10:13, Stephen Colebourne wrote: Automatic modules must either contain the Module-Name MANIFEST entry, or have a file name that exactly matches the desired module name. ie. the standard jar files downloaded from Maven Central, eg foo-bar-1.2 must be renamed to be used as an

Re: #VersionsInModuleNames

2017-03-15 Thread Peter Levart
+1 I have been planning to write a similar comment. I understand that the main desire is to discourage version numbers to creep into module names, but no rule can prevent that entirely. We can only advise against it, not police it. If one wants to do it otherwise, let him do it. He'll soon

#VersionsInModuleNames

2017-03-15 Thread Stephen Colebourne
Responding to the discussion on the EG list. I am now strongly of the opinion that using the language to restrict module names to not end in a number is a mistake. The two clear cases show two reasons why it is a mistake. commons-lang3 is the third version of commons-lang. It was named this way

hg: jigsaw/jake/langtools: Tempoarily exclude tools/javac/platform/PlatformProviderTest.java

2017-03-15 Thread alan . bateman
Changeset: fb9bb5851e88 Author:alanb Date: 2017-03-15 10:00 + URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fb9bb5851e88 Tempoarily exclude tools/javac/platform/PlatformProviderTest.java ! test/ProblemList.txt