Thanks for the explanation, it makes sense:
Patch acts more like an override than an append.
best,
Robert
On 3-4-2020 12:56:10, Alan Bateman wrote:
On 03/04/2020 10:17, Robert Scholte wrote:
> This issue was registered as SUREFIRE-1768[1]
> It contains a very small Maven project to demon
This issue was registered as SUREFIRE-1768[1]
It contains a very small Maven project to demonstrate the issue.
That project contains one method executing the following:
Demo.class.getClassLoader().getResources("demo").asIterator().forEachRemaining(url
-> {
System.out.println(url.getFile()); //
Since my request is only about required modules, I'll solely focus on that.
The responsibility of a build tool is to provide the right set of modules as
described in the module descriptor.
But this module descriptor doesn't specify where these modules are coming from,
so the build tool should pr
e adjusted.
thanks,
Robert
On 13-2-2020 00:12:02, Alex Buckley wrote:
On 2/12/2020 1:08 PM, Robert Scholte wrote:
> To prevent these workarounds and to provide an easier way to patch a
> module via a dedicated descriptor will help keeping the module
> system cleaner.
It will lead to &qu
It is kind of unfortunate that this topic has been hijacked for something I
don't see as an issue.
I've been able to build up the right set of commandline arguments for this case
for both javac and java
With *just* the dependencies(respecting compile + test scope) from the pom, and
the module d
hence maybe the
packager shouldn't allow to add it, nor other tools to use it.
But these are details open for discussion.
Robert
On 5-2-2020 08:57:53, Simone Bordet wrote:
Hi Robert,
On Wed, Feb 5, 2020 at 8:38 AM Robert Scholte wrote:
>
> Hi Simone,
>
> I understand your
Hi Simone,
I understand your concern, but the patched module descriptor doesn't have to
(or should not) replace the --patch-module option. This proposal is about the
additional options you now need to put on the commandline, but which already
fit in the module descriptor.
thanks,
Robert
On 5-2
24 May 2018 12:29:33 +0200, Alan Bateman
wrote:
On 23/05/2018 21:28, Peter Levart wrote:
:
It's not an official plugin. And it seems that the Maven container is
to blame, not the plugin.
Robert Scholte is on this mailing list and may be able to comment on
this.
The nonstandard Class
On Fri, 05 May 2017 12:36:38 +0200, Stephen Colebourne
wrote:
I think this design addresses some of Roberts's concern too. With this
plan, Maven Central would contain modules depending on automatic
modules, but the dependency names would be sufficiently stable for
this not to be the major iss
Yes, this option has been mentioned in some form.
The good thing about this part is that exports and requires use the same
structure, i.e. the package is the unit shared between 2 modules.
However, this will probably lead to a long list of requirements, so I
understand the choice the name of
ary he cannot use this, nor can he
refer to automodule, because he doesn't control the combinations of jars
used by the application developer.
thanks,
Robert
On Thu, 04 May 2017 19:39:06 +0200, wrote:
Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
R
The returning question is: how can I as a *library builder* participate in
adopting Jigsaw?
The first thing you need to ensure is that there are no split package
issues.
The next steps can be conflicting:
- I want to name my module, so my customers can refer to it
- I do not want to refer to
e of javac changes the way a synthetic
class is named (you will have the two versions with the compiler plugin).
cheers,
Rémi
- Mail original -----
De: "Robert Scholte"
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 25 Mars 2017 18:56:50
Objet: Re: Progress report on SLF4J project modu
On Sat, 25 Mar 2017 15:38:27 +0100, Ceki Gulcu wrote:
Following the recipe at [2], it all seems to work.
Good to read that the recipe works. If we need to add things to this
recipe to improve it, just let me know.
Although in general I don't think we'll be helping developers if we show
th
On Wed, 15 Mar 2017 11:13:25 +0100, Stephen Colebourne
wrote:
I'm sure there are plenty of other examples on Maven Central. But it
doesn't really matter. Both of these are valid reasons to name a
project with a number at the end. As such, the #VersionsInModuleNames
proposal cannot stand.
Ev
On Fri, 17 Feb 2017 00:19:43 +0100, Stephen Colebourne
wrote:
On 16 February 2017 at 16:48, wrote:
This can be done very simply, with a single new JAR-file manifest
`Module-Name` attribute
I welcome this.
The reversed domain-name approach was sensible in the early days of
Java,
befo
On Tue, 07 Feb 2017 14:20:07 +0100, Brian Fox wrote:
On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman
wrote:
As regards the example naming clash then these two projects might
already
get complaints over their poor choice of artifacts, esp. when artifacts
for
both projects are in same directo
On Fri, 27 Jan 2017 16:54:59 +0100, Robert Scholte
wrote:
On Fri, 27 Jan 2017 15:11:14 +0100, Stephen Colebourne
wrote:
Back in October, I raised the issue of modules names generally and for
automatic modules specifically [1]. The short thread came to no
conclusion, but recent threads
Hi Nicolai,
let's consider that my project depends on the following dependencies:
com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
I somehow want to have them both as requirements:
module M.N {
requires static library; // com.foo.bar:library
requires library; // com.acme:lib
On Fri, 27 Jan 2017 15:11:14 +0100, Stephen Colebourne
wrote:
Back in October, I raised the issue of modules names generally and for
automatic modules specifically [1]. The short thread came to no
conclusion, but recent threads have again raised similar problems. The
problem is that automatic
On Sat, 21 Jan 2017 19:35:28 +0100, Stephan Herrmann
wrote:
On 01/21/2017 06:52 PM, fo...@univ-mlv.fr wrote:
Robert,
How do you compile these 2 modules with Maven ?
module foo {
exports foo to bar;
}
module bar {
requires foo;
}
when compiling 'foo' javac needs to see if 'bar' exists
On Sat, 21 Jan 2017 14:55:50 +0100, Nicolai Parlog wrote:
Hi!
Ah, i see why you have a problem, a jigsaw module != a sub project
A sub project with your layout will contain several modules if you
prefer. A jigsaw module is more lightweight that the other kind of
''modules'' you usually find
The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.6.1
Most important change is the support for test-compile when using JDK 9
build b148+
https://maven.apache.org/plugins/maven-compiler-plugin/
You should specify the version in your proj
On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax wrote:
setting command line arguments or using a build tool to fiddle them for
you is exactly what we do not want here! We want fidelity between the
compile time configuration and the runtime configuration. Having to play
with -Xpatch at runti
Hi,
The following topics have been created for this issue:
http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs
http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs
Once resolved we should improve the maven-shade-plugin according the new
specifications
The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.6.0
The Compiler Plugin is used to compile the sources of your project.
This version introduces support of several new features of Java 9, such as:
JEP 247: Compile for Older Platform Vers
On Mon, 17 Oct 2016 12:59:25 +0200, Alan Bateman
wrote:
On 17/10/2016 08:32, Peter Levart wrote:
:
Do we need an --exclude-modules (in addition to --add-modules) option
on javac, java and jlink commands?
--exclude-modules would be different to --limit-modules. If some module
requires
T+02:00, Andrew Haley
wrote:
On 16/10/16 19:52, Robert Scholte wrote:
To enforce the discipline, the java compiler should IMHO at least
check if all required modules are indeed required and if the
transitive required modules are indeed transitive.
How can the compiler possibly know this? Th
Hi,
with the introduction of the module-info something interesting is
happening. Up until now the scope of a Java project was limited to the
compilation of the classes. In case of Maven the end-user was in full
control regarding the classpath and the order of entries. With the order
of th
One thing that is missing here is that you can only control the direct
dependencies, you cannot control the transitive dependencies.
To complete the example:
module com.mycompany:foo-utils {
requires guava; // automodule from google
}
but we also have
module com.acme:bar-utils {
requires
Hi,
I've written a page[1] about the problem related to projects which need to
be compatible with pre Java9 versions, but also want to provide a
module-info file in case it is used in a Java 9 project. This is mainly an
issue for library builders, end-application builders can simply push
Confirmed there's an issue; jar should have been recognized as a
multirelease jar.
https://bugs.openjdk.java.net/browse/JDK-8165723
thanks,
Robert
On Mon, 05 Sep 2016 09:10:56 +0200, Alan Bateman
wrote:
On 04/09/2016 21:56, Robert Scholte wrote:
:
Also if you "unzip
On Sun, 04 Sep 2016 22:50:00 +0200, Alan Bateman
wrote:
On 04/09/2016 18:01, Robert Scholte wrote:
Hi,
we have this demo application[1] to show how you can generate a
multirelease JAR right now with Maven.
However, in my case the result for Java9 is very unstable. Most of the
time I
INF/maven/multirelease/multirelease-base/pom.xml
mr/A.class
META-INF/maven/multirelease/multirelease-base/
META-INF/maven/
AFAIK the JEP238 doesn't mention something about order.
This is an issue on both Windows and Mac.
Anyone who has an explanation?
regards,
Robert Scholte
[1] https://gi
I've been working on the implementation of this in the
maven-compiler-plugin, but I'm not really pleased with the result.
The problem is that in the worst case scenario we have to work with 3
different versions of Java:
- The Maven Runtime (set as JAVA_HOME)
- JDK for the module-info.java
- JD
On Fri, 26 Aug 2016 13:31:47 +0200, Alan Bateman
wrote:
On 26/08/2016 11:49, Robert Scholte wrote:
Hi,
I'm struggling with this issue too.
I would have liked to see all the files under src/main/java, but since
module-info cannot be compiled at the same time as the other files we
Hi,
I'm struggling with this issue too.
I would have liked to see all the files under src/main/java, but since
module-info cannot be compiled at the same time as the other files we need
to do some extra things:
Possible solutions:
- Keep them all in the same folder but let Maven do 2 javac
odule maven.core
etc.
this way users have a relative simple way to get a complete overview of
all the modules used.
I might tweak the output, but the info is there.
Robert
On Thu, 25 Aug 2016 12:26:48 +0200, Robert Scholte
wrote:
Hi,
In an old thread I asked this before and got the foll
Hi,
In an old thread I asked this before and got the following answer:
"One way is `jar --file foo.jar -p`. That will print the module descriptor
when the JAR file is a modular JAR. There is API support for reading the
binary form of the module declaration too."
With the renaming of the arg
I noticed that the path is still META-INF/*versions*/ even though the JEP
has been renamed from Multi Version jar to Multi Release jar. Is that
intended or should/will that be changed as well?
thanks,
Robert
Hi,
in preparation of the DevoxxFr talk about Maven and Java9 by Hervé Boutemy
and Arnaud Héritier I noticed some issues with custom taglets when
generation Javadoc reports.
For the developers of Maven plugins we have a set of Annotations or
DocletTags[1] to generate the plugin descriptor
irectory is not a
module, which makes it extra confusing.
thanks,
Robert
On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte
wrote:
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
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
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
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.
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.
Unl
16:56:22 +0100, Jonathan Gibbons
wrote:
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-SYSTE
re in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
thanks,
Robert
[1] http://openjdk.java.net/jeps/261
On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons
wrote:
On 02/22/2016 12:44 PM, R
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
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 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
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
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
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 cla
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/java
and put all compile-scoped dependencie
.openjdk.java.net/jigsaw/jake/langtools/rev/719a1da641c7
-- Jon
On 02/03/2016 09:38 AM, Robert Scholte wrote:
Hi Jonathan,
it seems like this change is not enough, see:
Locations.ModulePathLocationHandler::setPaths
910
@Override
911
void setPaths(Iterable paths)
Hi Jonathan,
it seems like this change is not enough, see:
Locations.ModulePathLocationHandler::setPaths
910
@Override
911
void setPaths(Iterable paths) {
912
if (paths != null) {
913
for (Path p: paths) {
914
if (!Files.isDirect
20:33:32 +0100 schreef Paul Benedict
:
Robert, in the SOTM document, it explicitly calls out that Module systems
are not required to support multiple versions of a module. Correct me if
wrong, but I think you're hinting at that?
Cheers,
Paul
On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte
Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons
:
On 01/14/2016 12:25 PM, e...@zusammenkunft.net wrote:
Hello,
If I understood it correctly the modules on the MP must be unique and
are not merged, thats why the order inside the directory does not
matter for the named module
ment. For those who
want to use the commandline, the can still refer to module folders. As for
Maven (I cannot speak for other tools), we use the CompilerAPI, so
commandline-length is not the issue.
thanks,
Robert Scholte
[1] https://docs.oracle.com/javase/7/docs/api/java/io/File.html#list()
Op Tue, 05 Jan 2016 22:55:03 +0100 schreef Jochen Wiedmann
:
On Thu, Dec 31, 2015 at 1:01 PM, Robert Scholte
wrote:
The next blocking issue requires some work by the Apache Maven team
and/or
at the QDox project[2].
QDox is a Java Parser which is used to read javadoc and/or annotations
.
Once this component has been released, you don't have to wait for the
effected plugins to be released too: just add the new plexus-archiver as a
dependency to the plugin in your pom.xml
best wishes for 2016,
Robert Scholte
[1] https://bugs.openjdk.java.net/browse/JDK-8144879
[2] https://git
Op Wed, 30 Dec 2015 23:30:30 +0100 schreef Remi Forax :
- Mail original -
De: "Robert Scholte"
À: jigsaw-dev@openjdk.java.net
Envoyé: Mercredi 30 Décembre 2015 23:11:52
Objet: Draft of The Java Language Specification Java SE 9 Edition
Hi,
Hi Robert,
for QDox (Java Pars
plete. It would be great if the missing parts could be added before
releasing the official documents for Java 9.
Thanks,
Robert Scholte
Hi Mark,
I wasn't aware of this request, simply because I assumed that classpath
and modulepath would allow similar arguments. Main difference: in case of
a modulepath the module-info is used if available otherwise it is
considered a auto module. When using classpath arguments, the module-i
me.
To ensure that exactly the dependencies as specified in the pom.xml are
used (not more or less) without the need to copy files it would be my wish
to have -mp also support (jar)-files.
thanks,
Robert Scholte
[1] https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
[2] https://
So why this change? And is there another way to detect the usage of
non-accessible classes?
The maven-plugin has a parameter called failOnWarning (default:true) which
should break the build in order to help developers to change their code
when they rely on internal classes.
regards,
Robert Scholte
Ah, I see. Adding usage of java.awt.peer.ComponentPeer did indeed expose
an offending package again.
Just out of interest: will jdeps only detect violations of JDK internal
APIs or will it also detect violations on modules? In case I switch from
executable jar to executable module it could
Op Fri, 18 Sep 2015 10:26:46 +0200 schreef Alan Bateman
:
On 17/09/2015 22:07, Robert Scholte wrote:
I can confirm the fix.
thanks!
Robert
Thanks for the confirmation. Just to double check, this is with the
ToolProvider fix rather than the patch to the compiler plugin that one
of
I can confirm the fix.
thanks!
Robert
Op Wed, 16 Sep 2015 12:27:11 +0200 schreef Alan Bateman
:
On 14/09/2015 20:21, Stuart McCulloch wrote:
Yes, the issue is that ToolProvider.getSystemJavaCompiler() is
returning null when using the Jigsaw EA with Maven.
AFAICT this is because it’s n
Op Mon, 14 Sep 2015 20:27:39 +0200 schreef Alan Bateman
:
On 14/09/2015 17:40, Robert Scholte wrote:
Hi,
On behalf of the Apache Maven team I'd like to ask for advice for
changing the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with Maven
other ways to compile, e.g. use the fork-parameter[2] or with
toolchains[3], but what I'd like to know is whether it is still
possible/valid to use javax.tools.JavaCompiler and is so: how should we
rewrite this code?
regards,
Robert Scholte
[1]
https://github.com/codehaus-plexus/plexu
*:*
com.foo.bar:*
dot.foo.bar:utilities
With dependenciesToAnalyzeExcludes you can exclude a subset of
dependenciesToAnalyzeIncludes.
org.foo.test:*
This should match your requirements.
Regards,
Robert Scholte
Op Wed, 18 Feb 2015 05:46:37 +0100 schreef Mandy Chung
:
Hi Robert,
Indeed th
Hi Tibor,
the plugin is just a thin wrapper around the jdeps executable to make it
easier to integrate it with your Maven project. So for the Apache Maven
JDeps plugin it is out of scope. However, you could share your idea with
the jigsaw project[1]
thanks,
Robert
[1] http://mail.openjdk
kinternals
true
false
This should match your requirements.
Robert
Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
:
On 16/02/2015 18:28, Robert Scholte wrote:
Hi Alan,
if you are referring to the -R /
76 matches
Mail list logo
