On 2/25/2020 10:48 AM, Robert Scholte wrote:
For the test sources it is unclear.
One reason to not provide a module descriptor is because it will never
be a requirement for other modules.
And what about its name, as it is actually a required module and at the
same also the same module.
One re
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
On 2/25/2020 9:11 AM, Alex Buckley wrote:
And there are other ways, where the build tools (or their plugins) take
responsibility for arranging the test-time module graph. This may
require more work on the part of build tool/plugin maintainers than
simply telling their users to write JDK command
Hi Alan,
the issue with modules that are provided by the run-time
image and only required at test compile- and run-time is
that with Maven you need to have the GAV (Group Id,
Artifact Id, and Version) of a dependence in order to
declare a read-edge to it. Module "java.sql" for example
can't be exp
On 2/25/2020 8:16 AM, Remi Forax wrote:
no you can't because you can not reconstruct a module-info from the
flags --add-modules, --add-reads, etc.
Those flags has been created to patch (mostly the JDK) module
metadata so an application using the classpath can open/patch the JDK
modules metadata
- Mail original -
> De: "Alex Buckley"
> À: "jigsaw-dev"
> Envoyé: Mardi 18 Février 2020 18:42:10
> Objet: Re: RFE simplify usage of patched module [by Robert Scholte, from
> jdk-dev]
> On 2/14/2020 9:34 PM, Christian Stein wrote:
>> Assu
On 2/19/2020 3:46 AM, Christian Stein wrote:
On Tue, Feb 18, 2020 at 6:42 PM Alex Buckley
wrote:
Good description of how the main module
[...]
etc. Then, the build tool can enrich the main module by passing
--add-modules, --add-reads, and --add-opens to javac/java while in a
test scope. No nee
On Tue, Feb 18, 2020 at 6:42 PM Alex Buckley
wrote:
>
> Good description of how the main module
> [...]
> etc. Then, the build tool can enrich the main module by passing
> --add-modules, --add-reads, and --add-opens to javac/java while in a
> test scope. No need for --patch-module-descriptor in t
On 2/14/2020 9:34 PM, Christian Stein wrote:
Assuming `--patch-module-descriptor` was already available, the
org.astro test story would read:
- org.astro/main/module-info.java:
module org.astro {
exports org.astro;
requires java.logging;
}
- org.astro/test/module-info.java:
open /*test*
I extended the example project with some potential use-cases
for the `--patch-module-descriptor` option at [0]. Those use-cases
show which command line option usages can be replaced and
therefore simplified (as this RFE thread was coined) in the form
of the following example:
Today:
--add-modul
On 14/02/2020 08:02, Robert Scholte wrote:
:
With a tool like Maven it is already possible to compile and run patched
modules, but in case of requiring java.* modules it is very awkward that it
requires additional configuration in the pom instead of some dedicated module
descriptor, which fee
On Fri, Feb 14, 2020 at 10:31 PM Alex Buckley
wrote:
> On 2/14/2020 11:29 AM, Christian Stein wrote:
> >> A different way to address those use cases would be to ship the
> >> logic just described for `--patch-module-descriptor` in a launcher
> >> offered by the test framework itself.
> >
> > That
On 2/14/2020 11:29 AM, Christian Stein wrote:
A different way to address those use cases would be to ship the
logic just described for `--patch-module-descriptor` in a launcher
offered by the test framework itself.
That's too late in the build game. You already need this merged
descriptor at c
Hi Alex,
On Fri, Feb 14, 2020 at 7:06 PM Alex Buckley
wrote:
> [...]
Now, I am not "proposing" `--patch-module-descriptor` for a future JDK.
> I am recognizing that certain use cases involve changing a module's
> dependences and encapsulation in a tightly scoped way.
I can clearly envision th
Hi Alex,
thanks for your reply. Please find answers inlined below.
Note: I just realized that you already replied to Robert, and
from what I saw, the `--patch-module-descriptor` option idea would
indeed be a workable solution. Have to re-read your reply two or
three times to fully grasp that sugg
On 2/14/2020 12:02 AM, Robert Scholte wrote:
To me having the correct (main) module descriptor should be the ultimate
goal. People should not be tempted to apply workarounds on this
descriptor to make things work for tests (even though those module are
for sure part of the java runtime)
Especia
I am aware that the current patch concept is already complicating things.
Apart from the impact of the requested implementation, the information+options
should all be available already: the patch module descriptor should be
considered as an alias for some related commandline options.
With a too
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 "split modules" on the modulepath, which will cause just
as many maintenance headaches
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
Hi Christian,
On 2/7/2020 4:41 AM, Christian Stein wrote:
This time, I created a project at [0] with a detailed description on its
front page, i.e the README.md file.
[0]: https://github.com/sormuras/java-module-patching
To restate:
- You're saying that, today, it's brittle to copy directive
On Thu, Feb 6, 2020 at 8:35 AM Christian Stein wrote:
> I agree with you, that the user (the build tool in most of the cases)
> should
> stay in control which module descriptor is in effect for every module.
>
> As my domain is testing, and I guess the majority of uses-cases is within
> the realm
I agree with you, that the user (the build tool in most of the cases) should
stay in control which module descriptor is in effect for every module.
As my domain is testing, and I guess the majority of uses-cases is within
the realm of intra-module (white-box) testing, I'll expound on the topic
wit
Hi Simone,
to me the commandline doesn't change, so in your case the library.jar won't
patch jetty-client.jar.
It will only be patch as you already would do right now:
java --module-path jetty-client.jar:library.jar:app.jar --module
app/com.app.Main --patch-module jetty.client=/path/to/library.
Hi Robert,
On Wed, Feb 5, 2020 at 8:38 AM Robert Scholte wrote:
>
> 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 command
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
Hi,
> With the "patch modifier"-proposal applied as suggested by Robert,
> this manually constructed test module descriptor:
>
> open module foo {
> exports foo;
> requires org.junit.jupiter.api;
> }
>
> from [2] would shrink to:
>
> open patch module foo {
> requires org.junit.jupiter.api;
On Wed, Feb 5, 2020 at 4:47 AM Christian Stein wrote:
> // Hope this email will be technically associated as a reply for the
> // "RFE simplify usage of patched module" thread.
>
> I agree with Robert that a user-friendly and (build) tool-agnostic way
> to express additional module directives and
// Hope this email will be technically associated as a reply for the
// "RFE simplify usage of patched module" thread.
I agree with Robert that a user-friendly and (build) tool-agnostic way
to express additional module directives and modifiers for testing
purposes only is ... a good thing to have.
28 matches
Mail list logo
