les).
regards,
Rémi
- Mail original -
De: "Jonathan Gibbons"
À: "Remi Forax" , "Alan Bateman"
Cc: "Russell Gold" , "jigsaw-dev"
Envoyé: Jeudi 31 Mars 2016 03:29:55
Objet: Re: modulepath and classpath mixture
I have been follow
ax" , "Alan Bateman"
> Cc: "Russell Gold" , "jigsaw-dev"
>
> 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 ele
the module is just 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
>>> > pr
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
underlying presumption that one size fits all.
I venture to suggest that one size does /not/ fit all, and tha
*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 still in one modular jar with one module-in
- Mail original -
> De: "Ali Ebrahimi"
> À: "Remi Forax"
> Cc: "Alan Bateman" , "Jonathan Gibbons"
> , "jigsaw-dev"
> Envoyé: Mercredi 30 Mars 2016 17:12:22
> Objet: Re: modulepath and classpath mixture
> So,
end-like" access, which Jigsaw already has for other
> cases
> >>> > (the export...to clause).
> >>> >
> >>> > Put simply, I consider that module =
> >>> > deployment-artifact-with-dependencies. With that mental model,
> putting
> >>> &g
e that module =
>>> > deployment-artifact-with-dependencies, then perhaps we have bigger
>>> > problems to solve here.
>>> >
>>> > Stephen
>>> > (And to Paul Benedict, the classpath is going to die over time, so any
>>> > sol
> >
>> > Stephen
>> > (And to Paul Benedict, the classpath is going to die over time, so any
>> > solution that uses that is flawed IMO).
>> >
>> >
>> >> So as Alan said, from the jigsaw point of view at runtime, the tests and
>&
c and will always succeed.
>
> Rémi
>
> - Mail original -
> > De: "Alan Bateman"
> > À: "Russell Gold"
> > Cc: "jigsaw-dev"
> > Envoyé: Mercredi 30 Mars 2016 15:45:03
> > Objet: Re: modulepath and classpath mixture
>
aw 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.java in two different folders and package them as one
>> module,
>
restriction
- do the union of the uses.
- do the union of the provides.
so merging two modules is symmetric and will always succeed.
Rémi
- Mail original -
> De: "Alan Bateman"
> À: "Russell Gold"
> Cc: "jigsaw-dev"
> Envoyé: Mercredi 30 Mars
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
> separately from the module they
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 a
nd 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" >&
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 requ
igsaw 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.java in two different folders and package them as one
> 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 way to merge 2 module-info at
>>> comp
gsaw 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.java in two different folders and package them as one
> module,
> >> maybe ja
o.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"
>>> À: "Stephen Col
"jigsaw-dev"
>
> Envoyé: Mardi 29 Mars 2016 17:55:10
> Objet: Re: modulepath and classpath mixture
> Remi, it's really untenable to give tests a different version. Tests are
> currently built under the same version as the main project under one master
> parent p
be
against jigsaw canon but hopefully a compromise can be found.
Cheers,
Paul
On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax wrote:
>
>
> - Mail original -
> > De: "Stephen Colebourne"
> > À: "jigsaw-dev"
> > Envoyé: Mardi 29 Mars 2016
- Mail original -
> De: "Stephen Colebourne"
> À: "jigsaw-dev"
> Envoyé: Mardi 29 Mars 2016 15:24:15
> Objet: Re: modulepath and classpath mixture
>
> On 28 March 2016 at 11:13, Remi Forax wrote:
> > Hi Stephen, Hi all,
> > I think th
; De: "Alan Bateman"
>> À: "Stephen Colebourne" , "jigsaw-dev"
>>
>> Envoyé: Mercredi 23 Mars 2016 16:18:50
>> Objet: Re: modulepath and classpath mixture
>>
>>
>> On 23/03/2016 14:42, Stephen Colebourne wrote:
>> > :
&
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
>
> I think we can a
himi1...@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
"Alan Bateman"
> > À: "Stephen Colebourne" , "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 Co
saw-dev"
>
> Envoyé: Mercredi 23 Mars 2016 16:18:50
> Objet: Re: modulepath and classpath mixture
>
>
> On 23/03/2016 14:42, Stephen Colebourne wrote:
> > :
> >
> > I don't particularly care what the mechanism is for this, but at the
> > req
> 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
Then it seems to me that ther
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
2. A jar containing a module-info file is treated as a module when placed on a
module path, and restr
On 23/03/2016 14:42, Stephen Colebourne wrote:
:
I don't particularly care what the mechanism is for this, but at the
requirements level:
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted o
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 different or attempting to chan
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
2. A jar containing a module-info file is treated as a module when placed on a
module path, and restricts access to non-exported packages
3. A jmod file
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 yo
> 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 should.
>>
>> I am assumi
On 23/03/2016 11:01, Stephen Colebourne wrote:
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.
If types T1 a
On 3/23/16, 7:01 AM, Stephen Colebourne wrote:
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.
We have worked through this white/black
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 definitely not part of the module.
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)
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 dependencies
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
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 from
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) with message:
./src/javax/annotation/Priority.
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 dependencies, and
possibly has both module and class p
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 expect that these
entries would have any ef
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 there been any discussion aro
On Tue, 22 Mar 2016 13:06:05 +0100, 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 there been a
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 module name in the
POM? From
2016/2/27 3:25 -0800, rfscho...@apache.org:
> 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 modulePat
On 18/03/2016 07:56, Robert Scholte wrote:
I can do the former with QDox, for the latter I had JDK APIs in mind,
but if ASM is an option too, that's an interesting option. Need to
figure out how to do that.
It should only be a few lines with ASM. If you have an input stream to
the module-in
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 a multirelease JAR.
The pa
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
Hi,
it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.
Here's the compiler error:
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.
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 seconda
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 if
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 test-classe
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:
> The only rational solution
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 f
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 l
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. It
can be used in con
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 package.
Unless I misundersta
On 07/03/2016 13:53, Sander Mak wrote:
:
I was playing around with exactly this yesterday, and this is what I ended up
with:
javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
-XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \
-mp
> 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 addit
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 -addmods.
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
-addmods. If you add mod1 and mod2, which both exp
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 A
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
th
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 sho
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 sounds like the project is m
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 02/23/2016 12:48 PM, Robert Scholte wrote:
On Tue, 23 Feb 2016
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
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
wrote:
On 02/22/2016 12:44
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 02/22/2016 12:44 PM, Robert Scholte wrote:
Hi,
first of all I
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 wr
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 with the new -mp
options, th
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 fines.
Sounds good.
I assum
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 class-folders.
Here's my
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 with the way Apache Maven would
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 with jars and class-folders.
H
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 class-folders.
Here's my use case: I noticed that if I add a module-info to
src/main/j
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
src/ma
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
module-info
82 matches
Mail list logo
