Re: modulepath and classpath mixture

lt;jigsaw-dev@openjdk.java.net> Envoyé: Jeudi 31 Mars 2016 03:29:55 Objet: Re: modulepath and classpath mixture I have been following this thread, and it strongly reminds me of Joe Darcy's parables of elephants and blind men. [1,2] In this context, the discussion has been about testing, and the un

Re: modulepath and classpath mixture

t; > À: "Remi Forax" <fo...@univ-mlv.fr>, "Alan Bateman" <alan.bate...@oracle.com> > Cc: "Russell Gold" <russell.g...@oracle.com>, "jigsaw-dev" > <jigsaw-dev@openjdk.java.net> > Envoyé: Jeudi 31 Mars 2016 03:29:55 > O

Re: modulepath and classpath mixture

n application and they have different >>> > dependencies. If we disagree that module = >>> > deployment-artifact-with-dependencies, then perhaps we have bigger >>> > problems to solve here. >>> > >>> > Stephen >>>

Re: modulepath and classpath mixture

t;alan.bate...@oracle.com>, "Jonathan Gibbons" <jonathan.gibb...@oracle.com>, "jigsaw-dev" <jigsaw-dev@openjdk.java.net> *Envoyé: *Mercredi 30 Mars 2016 17:12:22 *Objet: *Re: modulepath and classpath mixture So, do you suggest partial modules or m

Re: modulepath and classpath mixture

igsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 30 Mars 2016 17:12:22 > Objet: Re: modulepath and classpath mixture > So, do you suggest partial modules or module fragments? A kind of exploded module with sources available in more than one directory. Classes are st

Re: modulepath and classpath mixture

not acceptable, because tests should >>> > not be deployed with the main application and they have different >>> > dependencies. If we disagree that module = >>> > deployment-artifact-with-dependencies, then perhaps we have bigger >>> > problems to solve here. >>

Re: modulepath and classpath mixture

t is flawed IMO). >> > >> > >> >> So as Alan said, from the jigsaw point of view at runtime, the tests and >> >> the code should be in the same module. >> >> >> >> So the building tools have to come with a way to support to have 2 &

Re: modulepath and classpath mixture

g two modules is symmetric and will always succeed. > > Rémi > > - Mail original - > > De: "Alan Bateman" <alan.bate...@oracle.com> > > À: "Russell Gold" <russell.g...@oracle.com> > > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.ja

Re: modulepath and classpath mixture

> solution that uses that is flawed IMO). >> > >> > >> >> So as Alan said, from the jigsaw point of view at runtime, the tests >> and the code should be in the same module. >> >> >> >> So the building tools have to come with a way to support

Re: modulepath and classpath mixture

com> > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 30 Mars 2016 15:45:03 > Objet: Re: modulepath and classpath mixture > > On 30/03/2016 13:28, Russell Gold wrote: > > : > > > > > > So if the tests and main code are both in direc

Re: modulepath and classpath mixture

On 30 March 2016 at 14:45, Alan Bateman wrote: > The thread here has meandered a bit but I think the scenario under > discussion is tests for a module that need to nestmate with the module under > test. The tests are in their own test tree. The tests are compiled >

Re: modulepath and classpath mixture

On 30/03/2016 13:28, Russell Gold wrote: : So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. There shouldn't any issue there, it should just work

Re: modulepath and classpath mixture

tools have to come with a way to support to have 2 > >> different module-info.java in two different folders and package them as > >> one module, > >> maybe javac should help by providing a way to merge 2 module-info at > >> compile time. > >> > >> Rémi &

Re: modulepath and classpath mixture

On 30/03/2016 10:26, Stephen Colebourne wrote: The underlying message of Jigsaw is that the classpath is going away. There are no plans, at least not in this project, to remove the class path. There is of course a better world beyond the class path, it's just going to take a long time and

Re: modulepath and classpath mixture

d IMO). > >> > >> > >>> So as Alan said, from the jigsaw point of view at runtime, the tests > and the code should be in the same module. > >>> > >>> So the building tools have to come with a way to support to have 2 > different module-info.j

Re: modulepath and classpath mixture

and >>> the code should be in the same module. >>> >>> So the building tools have to come with a way to support to have 2 >>> different module-info.java in two different folders and package them as one >>> module, >>> maybe javac should help by providing a

Re: modulepath and classpath mixture

as one > module, > >> maybe javac should help by providing a way to merge 2 module-info at > compile time. > >> > >> Rémi > >> > >> - Mail original - > >>> De: "Alan Bateman" <alan.bate...@oracle.com> > >>&

Re: modulepath and classpath mixture

gt; module-info.java in two different folders and package them as one module, >> maybe javac should help by providing a way to merge 2 module-info at compile >> time. >> >> Rémi >> >> - Mail original - >>> De: "Alan Bateman" <alan.bate..

Re: modulepath and classpath mixture

v-mlv.fr> > Cc: "Stephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" > <jigsaw-dev@openjdk.java.net> > Envoyé: Mardi 29 Mars 2016 17:55:10 > Objet: Re: modulepath and classpath mixture > Remi, it's really untenable to give tests a different vers

Re: modulepath and classpath mixture

t; <jigsaw-dev@openjdk.java.net> > > Envoyé: Mardi 29 Mars 2016 15:24:15 > > Objet: Re: modulepath and classpath mixture > > > > On 28 March 2016 at 11:13, Remi Forax <fo...@univ-mlv.fr> wrote: > > > Hi Stephen, Hi all, > > > I think that deliver

Re: modulepath and classpath mixture

- Mail original - > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mardi 29 Mars 2016 15:24:15 > Objet: Re: modulepath and classpath mixture > > On 28 March 2016 at 11:13, Remi F

Re: modulepath and classpath mixture

inal - >> De: "Alan Bateman" <alan.bate...@oracle.com> >> À: "Stephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" >> <jigsaw-dev@openjdk.java.net> >> Envoyé: Mercredi 23 Mars 2016 16:18:50 >> Objet: Re:

Re: modulepath and classpath mixture

lar in Jigsaw (and OSGI > is a four-letter word). > > > > -Original Message- > From: Ali Ebrahimi [mailto:ali.ebrahimi1...@gmail.com] > Sent: Monday, March 28, 2016 8:56 AM > To: Remi Forax > Cc: jigsaw-dev > Subject: Re: modulepath and classpath mixture > &

RE: modulepath and classpath mixture

...@gmail.com] Sent: Monday, March 28, 2016 8:56 AM To: Remi Forax Cc: jigsaw-dev Subject: Re: modulepath and classpath mixture I think we can adapt OSGI fragment bundle here and introduce module fragments that is attached to a host module. So we would have test fragment that is embeded in main

Re: modulepath and classpath mixture

original - > > De: "Alan Bateman" <alan.bate...@oracle.com> > > À: "Stephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" < > jigsaw-dev@openjdk.java.net> > > Envoyé: Mercredi 23 Mars 2016 16:18:50 > > Objet: Re

Re: modulepath and classpath mixture

ephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" > <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 23 Mars 2016 16:18:50 > Objet: Re: modulepath and classpath mixture > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > : > > >

Re: modulepath and classpath mixture

> On Mar 23, 2016, at 11:42 AM, Alan Bateman wrote: > > > > On 23/03/2016 14:15, Russell Gold wrote: >> Here are my assumptions, which you can correct. >> >> 1. A jar or classes directory placed on a class path are treated as part of >> the unnamed module > Yes

Re: modulepath and classpath mixture

On 23 March 2016 at 12:51, Alan Bateman wrote: > If types T1 and T2 have the same defining loader and both types are in the > same package then they are in the same module. T1 can't be module M1 and T2 > in a different module M2. > (I shudder the thought of it being

Re: modulepath and classpath mixture

On 23/03/2016 13:02, Russell Gold wrote: : Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no? I'm not sure that I understand

Re: modulepath and classpath mixture

> On Mar 23, 2016, at 3:21 AM, Alan Bateman wrote: > > On 22/03/2016 22:20, Russell Gold wrote: >> I’d like to take a step back here. It may be that I have completely >> misunderstood what is going on, but this all seems to have gotten way more >> complicated than it

Re: modulepath and classpath mixture

On 23 March 2016 at 07:21, Alan Bateman wrote: > If they are in the same class loader and package as > the code they are testing (the norm in Maven) then they need to compiled as > if they are part of the module. I struggle with that idea. To me, tests are very

Upgrading EE modules (was Re: modulepath and classpath mixture)

On 22/03/2016 22:29, Richard Opalka wrote: Hi, I'm experiencing the same problem locally. When trying to build Oracle provided maven artifact from sources, namely http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar the build fails on JDK9 (with Jigsaw)

Re: modulepath and classpath mixture

On 22/03/2016 22:20, Russell Gold wrote: I’d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should. I am assuming: 1) the project has both module and class path compile

Re: modulepath and classpath mixture

On 22/03/2016 21:23, Robert Scholte wrote: maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] package exists in another module: maven.builder.support Just wondering, is this the expected behavior? DefaultProblemTest is on the *classpath* and I wouldn't

Re: modulepath and classpath mixture

Hi, I just solved it by adding -Xmodule option: javac -Xmodule:java.annotations.common -sourcepath src `find -type f -name *.java` Rio On 03/22/2016 11:29 PM, Richard Opalka wrote: Hi, I'm experiencing the same problem locally. When trying to build Oracle provided maven artifact

Re: modulepath and classpath mixture

On 03/22/2016 07:06 AM, Peter Levart wrote: On 02/24/2016 08:30 PM, Robert Scholte wrote: On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman wrote: On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has

Re: modulepath and classpath mixture

On 02/24/2016 08:30 PM, Robert Scholte wrote: On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman wrote: On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has there been any discussion around having the

Re: modulepath and classpath mixture

On Thu, 17 Mar 2016 21:23:25 +0100, Alan Bateman wrote: On 17/03/2016 19:51, Robert Scholte wrote: : To me it seems like the need for knowing the module name keeps returning. This increases the need for a proper implementation of the maven-compiler-plugin as

Re: modulepath and classpath mixture

On 17/03/2016 19:51, Robert Scholte wrote: : To me it seems like the need for knowing the module name keeps returning. This increases the need for a proper implementation of the maven-compiler-plugin as a multirelease JAR. The pattern as shown during FOSDEM showed that the idea works, but it

Re: modulepath and classpath mixture

I have an idea: What if the jar tool in JDK 9 was upgraded so that the Manifest had a new entry that contained the module name? This would allow access to it without requiring new API, and tools running JDK 8 or below would have an easy way to detect if the JAR is a module. And is there a

Re: modulepath and classpath mixture

On 08/03/2016 20:06, Paul Benedict wrote: Robert, it's sounds like a chicken-and-egg problem. You need the module name to compile but don't know it until you have compiled. I think the scenario is where the module has been compiled and the issue is the separate compilation of the tests "as

Re: modulepath and classpath mixture

On 08/03/2016 19:13, Robert Scholte wrote: This is how I thought that -Xpatch would work in short: the module-info in src/main/java and src/test/java have both the same modulename. The module-info in src/test/java specifies the extra required modules (like junit). With -Xpatch the

Re: modulepath and classpath mixture

Bikeshed: JDK 9 is supposed to be feature complete 5/26/16 and be RC by next January. Is this really enough time for EE Application Server projects and other tools like Maven to vet the capabilities? Cheers, Paul On Tue, Mar 8, 2016 at 4:08 PM, David M. Lloyd wrote: >

Re: modulepath and classpath mixture

The only rational solution to this problem is to completely forego the JDK's capabilities and generate the file exclusively from the build tooling. I expect that at some point we'll end up with a series of tools which construct the exports list from annotated package-infos, the requires list

Re: modulepath and classpath mixture

Robert, it's sounds like a chicken-and-egg problem. You need the module name to compile but don't know it until you have compiled. Too bad this file isn't XML so that any tool could read the module information outside of compiling. That's what I advocated for a long time but that battle has been

Re: modulepath and classpath mixture

On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak wrote: I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration.

Re: modulepath and classpath mixture

On Mon, 07 Mar 2016 13:13:38 +0100, Alan Bateman wrote: On 06/03/2016 14:01, Robert Scholte wrote: Hi, I've asked for some feedback and there seems to be concerns with split packages when there are two or more modules on the module path that export the same

Re: modulepath and classpath mixture

> I don't think I understand the issue here. Using -Xpatch doesn't change the > module declaration or export. It can be used to override or augment the > module content, it just can't override the module declaration. It can be used > in conjunction with -XaddReads and -XaddExports to read

Re: modulepath and classpath mixture

On 06/03/2016 14:01, Robert Scholte wrote: Hi, I've asked for some feedback and there seems to be concerns with split packages when there are two or more modules on the module path that export the same package. Unless I misunderstand the issue, I'd say you have the same problem with

Re: modulepath and classpath mixture

At the risk of opening bikesheds, if we go that way, I would suggest just -ALL- or just a new option -addallmods. -- Jon On 02/27/2016 03:25 AM, Robert Scholte wrote: Hi, I noticed[1] that -addmods already has a special option: ALL-SYSTEM What I'm looking for is something like ALL-MP or

Re: modulepath and classpath mixture

Hi, I noticed[1] that -addmods already has a special option: ALL-SYSTEM What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which simply exposes all modules on the modulepath to the classpath. The set of moduleEntries on the modulePath are already chosen with care and are in

Re: modulepath and classpath mixture

On 24/02/2016 19:12, Robert Scholte wrote: Hmm, would have been nice if I had known about these discussions, because I don't think that this is a valid assumption from a Maven perspective. Ideally developers simply add module-info.java files to the source-roots of their choice and Maven

Re: modulepath and classpath mixture

On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman wrote: On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has there been any discussion around having the module name in the POM? From the mails then it

Re: modulepath and classpath mixture

On Wed, 24 Feb 2016 00:15:26 +0100, Jonathan Gibbons wrote: On 02/23/2016 01:22 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons wrote: On 02/23/2016 01:06 PM, Jonathan Gibbons wrote: On

Re: modulepath and classpath mixture

On 23/02/2016 21:10, Robert Scholte wrote: : If I understand this correctly I need to know the module name. Has there been any discussion around having the module name in the POM? From the mails then it sounds like the project is mostly "unaware" that it is creating a module. The other thing

Re: modulepath and classpath mixture

On 02/23/2016 01:22 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons wrote: On 02/23/2016 01:06 PM, Jonathan Gibbons wrote: On 02/23/2016 12:48 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons wrote: On 02/23/2016 01:06 PM, Jonathan Gibbons wrote: On 02/23/2016 12:48 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons wrote: On

Re: modulepath and classpath mixture

On 02/23/2016 01:10 PM, Robert Scholte wrote: And maybe this is the key question: if src/main/java is a module, should we handle src/test/java as a module too or leave it as a classpath based project? thanks, Robert You list 2 choices, but there's 3 possible answers here. If you're

Re: modulepath and classpath mixture

On 02/23/2016 01:06 PM, Jonathan Gibbons wrote: On 02/23/2016 12:48 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons wrote: On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 01:30:16 +0100, Alex Buckley wrote: Hi Robert, On 2/22/2016 12:44 PM, Robert Scholte wrote: Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped dependencies to the module path, all compiles

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 13:59:13 +0100, Alan Bateman wrote: On 22/02/2016 20:44, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and

Re: modulepath and classpath mixture

On 02/23/2016 12:48 PM, Robert Scholte wrote: On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons wrote: On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better

Re: modulepath and classpath mixture

On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons wrote: On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work

Re: modulepath and classpath mixture

On 02/22/2016 12:44 PM, Robert Scholte wrote: Hi, first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and class-folders. Here's my use case: I noticed that if I add a module-info to

Re: modulepath and classpath mixture

Hi Robert, On 2/22/2016 12:44 PM, Robert Scholte wrote: Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped dependencies to the module path, all compiles fines. Sounds good. I assume that developers are less interested in adding a