On Thu, 19 May 2022 06:21:40 GMT, Christian Stein wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
>> line 387:
>>
>>> 385:
>>> 386: javac.description=Read Java declarations and compile them into class
>>
On Wed, 18 May 2022 21:47:25 GMT, Jonathan Gibbons wrote:
>> This PR adds an optional description accessor on `ToolProvider` interface.
>>
>> This PR also adds short description for each of the listed tool:
>> - `jar`
>> - `javac`
>> - `javadoc`
>> - `javap` and `jdeps`
>> - `jlink` and `jmod`
On Wed, 18 May 2022 21:47:25 GMT, Jonathan Gibbons wrote:
>> This PR adds an optional description accessor on `ToolProvider` interface.
>>
>> This PR also adds short description for each of the listed tool:
>> - `jar`
>> - `javac`
>> - `javadoc`
>> - `javap` and `jdeps`
>> - `jlink` and `jmod`
This PR adds an optional description accessor on `ToolProvider` interface.
This PR also adds short description for each of the listed tool:
- `jar`
- `javac`
- `javadoc`
- `javap` and `jdeps`
- `jlink` and `jmod`
- `jpackage`
-
Commit messages:
- Add localized description for
This PR adds an optional description accessor on `ToolProvider` interface.
This PR also adds short description for each of the listed tool:
- `jar`
- `javac`
- `javadoc`
- `javap` and `jdeps`
- `jlink` and `jmod`
- `jpackage`
-
Commit messages:
- Add localized description for
+1
Upgrading all Maven-based sample projects from Surefire 2.22.0 to 3.0.0-M6
seems to work fine.
https://github.com/junit-team/junit5-samples/pull/168
Cheers,
Christian
On Thu, Mar 31, 2022 at 2:35 PM Tibor Digana wrote:
> Hi,
>
> We solved 111 issues:
>
>
On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote:
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provide
On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote:
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provide
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
C
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
C
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
C
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
C
On Thu, 10 Feb 2022 17:24:17 GMT, Jonathan Gibbons wrote:
>>> Perhaps like this?
>>>
>>> ```java
>>> /**
>>> * ...
>>> * @provides java.util.spi.ToolProvider
>>> * Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>> * Invoke {@link
On Thu, 10 Feb 2022 17:24:17 GMT, Jonathan Gibbons wrote:
>>> Perhaps like this?
>>>
>>> ```java
>>> /**
>>> * ...
>>> * @provides java.util.spi.ToolProvider
>>> * Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>> * Invoke {@link
On Thu, 10 Feb 2022 02:19:36 GMT, Jonathan Gibbons wrote:
>> src/jdk.jartool/share/classes/module-info.java line 45:
>>
>>> 43: * Pass {@code "jar"} as the name to
>>> 44: * {@link java.util.spi.ToolProvider#findFirst
>>> ToolProvider.findFirst}
>>> 45: * in order to
On Thu, 10 Feb 2022 02:19:36 GMT, Jonathan Gibbons wrote:
>> src/jdk.jartool/share/classes/module-info.java line 45:
>>
>>> 43: * Pass {@code "jar"} as the name to
>>> 44: * {@link java.util.spi.ToolProvider#findFirst
>>> ToolProvider.findFirst}
>>> 45: * in order to
On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote:
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provide
On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote:
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provide
A number of modules declare that the "provide" ToolProvider.
These modules now specify the "name" of the argument used by
`ToolProvider.findFirst` to access an instance of the tool provider within the
description part of a `@provides` API tag.
-
Commit messages:
- Separate
A number of modules declare that the "provide" ToolProvider.
These modules now specify the "name" of the argument used by
`ToolProvider.findFirst` to access an instance of the tool provider within the
description part of a `@provides` API tag.
-
Commit messages:
- Separate
On Wed, 9 Feb 2022 06:42:51 GMT, Christian Stein wrote:
> This PR removes the redundant and failing test-case.
> It also removes the test class from the problem list.
>
> Adds additional test-cases using long form option names of `jar`.
This pull request has now been integrated
This PR removes the redundant and failing test-case.
It also removes the test class from the problem list.
Adds additional test-cases using long form option names of `jar`.
-
Commit messages:
- Only assert non-zero exit code on failure
- 8281470:
On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote:
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
This pull re
[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488968#comment-17488968
]
Christian Stein commented on SUREFIRE-1909:
---
Users, project authors, testers and dev folks
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
Christian Stein has updated the pull request incrementally with one a
On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote:
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
Should I al
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
Christian Stein has updated the pull request incrementally with one a
On Thu, 3 Feb 2022 21:43:30 GMT, Lance Andersen wrote:
> I think this would be the appropriate place for documenting the behavior.
Like this?
-c, --create Create the archive. When the path specified by -f,
--file
contains a path, missing parent
On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote:
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
Thanks for t
Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
parent directories (here `a/b`) on the default file system before storing the
JAR file (here `foo.jar`) in the destination directory.
-
Commit messages:
- Expect at least jar file's name in error message
[
https://issues.apache.org/jira/browse/SUREFIRE-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462259#comment-17462259
]
Christian Stein commented on SUREFIRE-1764:
---
Seems like JUnit Platform 1.6.2 is at least
On Wed, 8 Dec 2021 15:26:23 GMT, Christian Stein wrote:
> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and
> class `PathFileObject` in module `jdk.compiler` were always composed by base
> path names. Even for versioned entries of a multi-release JAR file.
On Fri, 10 Dec 2021 16:33:33 GMT, Jonathan Gibbons wrote:
>> Christian Stein has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T
ath names using an
> existing lookup function in the associated zip file system object.
>
> This PR also removes a superseded work around for
> [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
Chr
On Fri, 10 Dec 2021 16:37:35 GMT, Jonathan Gibbons wrote:
> javac changes look good. I suggest adding this bug number to the test to
> check that URIs are not double-encoded.
I can't find [`8134451`](https://bugs.openjdk.java.net/browse/JDK-8134451) as
noted in the now removed comment
On Fri, 10 Dec 2021 16:30:37 GMT, Jonathan Gibbons wrote:
>> Christian Stein has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T
On Thu, 9 Dec 2021 18:37:11 GMT, Alan Bateman wrote:
>> Christian Stein has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Clean up reproducer test case
>> - Keep helper in ZipFileSystem simple
>
>
ath names using an
> existing lookup function in the associated zip file system object.
>
> This PR also removes a superseded work around for
> [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
Chr
[
https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17450707#comment-17450707
]
Christian Stein commented on LUCENE-10255:
--
FWIW, I agree with Uwe on the naming topic
On Mon, 15 Nov 2021 12:58:45 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8227020?
>
> The linked issue talks about non-normalized paths contributing to the leak.
> However, the root
On Thu, 11 Nov 2021 12:05:49 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which implements the enhancement
> noted in https://bugs.openjdk.java.net/browse/JDK-8276559?
>
> The commit in this PR introduces a new `HEAD()` method on the
> `HttpRequest.Builder` interface.
On Thu, 4 Nov 2021 13:10:37 GMT, Christian Stein wrote:
> This PR implements the fix as suggested by Adam Farley, which reads:
>
>> Note: Looks to be as simple as adding `jaccessinspector-32` and
>> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of
>> `HelpFla
On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux
wrote:
> ...
> Armed with this rich information, Maven could auto-generate the module-
> info.java file before compiling the code; auto-generate the alternative
> module-info.java file before compiling and running the tests;
>
...
That's like
This PR implements the fix as suggested by Adam Farley, which reads:
> Note: Looks to be as simple as adding `jaccessinspector-32` and
> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of `HelpFlagsTest.java`,
> as the non-32bit versions are already there.
-
Commit messages:
On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8267472
>
> Christian Stein has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add module version to `graphics` and `we
On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein wrote:
> This commit appends the name of the JAR file to the exception message for
> when automatic module lists a non-existing provider class.
This pull request has now been integrated.
Changeset: c10de353
Author:Christian
> This commit appends the name of the JAR file to the exception message for
> when automatic module lists a non-existing provider class.
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Add JBS issue `8262944` to the `@bug
> This commit appends the name of the JAR file to the exception message for
> when automatic module lists a non-existing provider class.
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Assert that only the name of the JA
On Thu, 23 Sep 2021 11:26:26 GMT, Alan Bateman wrote:
>> This commit appends the name of the JAR file to the exception message for
>> when automatic module lists a non-existing provider class.
>
> src/java.base/share/classes/jdk/internal/module/ModulePath.java line 554:
>
>> 552:
On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij
wrote:
> [...]
For now, I think the LauncherSession is the best way to at least provide
> some hooks for pre and post fixtures. It shouldn't be too hard to get this
> in the current code base with backwards compatibility for JUnit Platform
> 1.7
Hi Gunnar,
I skimmed your post briefly and will read it in detail later -- though I
wonder
whether my over 4 years old SO question is answered as a side-effect by
your findings.
https://stackoverflow.com/questions/44167502/how-to-configure-resourcebundle-no-fallback-control-in-java-9
Cheers,
On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote:
> https://bugs.openjdk.java.net/browse/JDK-8267472
This pull request has now been integrated.
Changeset: c2e69145
Author: Christian Stein
Committer: Kevin Rushforth
URL:
https://git.openjdk.java.net/jfx/com
On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8267472
>
> Christian Stein has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add module version to `graphics` and `we
On Mon, 23 Aug 2021 18:40:55 GMT, Johan Vos wrote:
>> OK, that seems reasonable, and I can't think of any downside.
>
> The only thing that makes me slightly nervous is seeing that this is needed
> on a number of places, leading to more code duplication (and the build.gradle
> is already
On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8267472
>
> Christian Stein has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add module version to `graphics` and `we
> https://bugs.openjdk.java.net/browse/JDK-8267472
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Add module version to `graphics` and `web` project's compiler args
-
Changes:
- all: https://git.openjdk.java.
On Mon, 23 Aug 2021 14:10:56 GMT, Christian Stein wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8267472
>
> Christian Stein has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Pass module version also to `jmod`
>
On Mon, 23 Aug 2021 14:06:31 GMT, Kevin Rushforth wrote:
>> Christian Stein has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Pass module version also to `jmod`
>
> buil
> https://bugs.openjdk.java.net/browse/JDK-8267472
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Pass module version also to `jmod`
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/608/files
- new: ht
On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote:
> https://bugs.openjdk.java.net/browse/JDK-8267472
The submit workflow just started:
https://github.com/sormuras/jfx/actions/runs/1158948963
I'm not sure, if passing `--module-version` to `jmod` is needed (as the
`module-info.cl
On Mon, 23 Aug 2021 12:59:46 GMT, Joeri Sykora wrote:
> [...] I'm not sure if this is more elegant? With Gradle 7, this option is
> also no longer incubating.
As long as `--module-source-path` et al aren't supported by Gradle, I'd suggest
to keep Java module related options at a single place.
On Mon, 23 Aug 2021 10:48:23 GMT, Christian Stein wrote:
> https://bugs.openjdk.java.net/browse/JDK-8267472
Enabled actions on my fork - do I need to do something to trigger them now
manually? They don't seem to start:
https://github.com/sormuras/jfx/actions/workflows/submit.
https://bugs.openjdk.java.net/browse/JDK-8267472
-
Commit messages:
- Compile version information into modules
Changes: https://git.openjdk.java.net/jfx/pull/608/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=608=00
Issue:
Motivated by the summary of JEP 408, I finally wrote a small blog[1]
about an in-memory http handler that I use for testing browsing-related
code via URL.open..., HttpClient, or other ways to read a resource.
The basic idea is to map a prepared response (http code, bytes, and
content-type) to a
[
https://issues.apache.org/jira/browse/MJAVADOC-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337774#comment-17337774
]
Christian Stein commented on MJAVADOC-676:
--
Understood; and I support your reasoning. Thanks
[
https://issues.apache.org/jira/browse/MJAVADOC-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337494#comment-17337494
]
Christian Stein commented on MJAVADOC-676:
--
{quote}The automatic-module-name was only added
[
https://issues.apache.org/jira/browse/MJAVADOC-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337426#comment-17337426
]
Christian Stein commented on MJAVADOC-676:
--
{quote} ... this project isn't "java module&q
On Sun, Apr 25, 2021 at 4:53 PM Apache wrote:
> Thanks Christian. I’ve read that blog several times. It helped me
> immensely in getting anything to work.
You're welcome and glad to hear that it helped you!
> However, it doesn’t exactly cover my situation where some of the test
> classes
:
> >
> > I think you need to talk with Christian Stein about blackbox and
> whitebox testing.
> >
> > Robert
> > On 25-4-2021 08:47:20, Ralph Goers wrote:
> > I am trying to convert Log4j 2 to be fully modularized and am running
> into problems with
/commit/940bf900c448177cc5cc5410ff604bad8197b59c
On Thu, Mar 25, 2021 at 4:17 PM Alan Bateman
wrote:
> On 25/03/2021 14:59, Christian Stein wrote:
> > Hi,
> >
> > Besides their names, contents and purposes. (-:
> >
> > So, what's the difference of module jdk
Hi,
Besides their names, contents and purposes. (-:
So, what's the difference of module jdk.xml.dom and
module jdk.zipfs in respect to their visibility(?) at
compile and run-time?
Suppose, there's a module test.base declared as:
module test.base {
requires jdk.xml.dom;
requires
On Wed, Mar 3, 2021 at 10:10 AM Alan Bateman
wrote:
> [...]
> Thanks, it should include the file path to the JAR file in the message
> to make it easy to find the JAR file that can't be used as an automatic
> module. I'll create an issue to track that.
>
Did you create an issue, Alan? If not,
On Thu, Mar 25, 2021 at 12:26 PM Alan Bateman
wrote:
> [...]
>
> More generally, tests for modules, say white box tests that exercise
> package private methods, can continue to be compiled and run "as if"
> they are part of the module. The Maven/other plugins for testing will
> use
On Fri, Feb 26, 2021 at 12:42 PM Robert Scholte
wrote:
> I remember the same discussion with Christian Stein.
>
Yeah, me too. Came up with a JSR223 wrapper POC implementation around that
time:
https://github.com/sormuras/java-compiler-script-engine
Maybe it's of help here - if not, then not. (-:
Hi Alex,
Perhaps a deeper look how Layrry works under the hood does help:
https://github.com/moditect/layrry
If I'm not mistaken, your use-case seems very similar to those Layrry tries
to cope with.
Cheers,
Christian
On Mon, Nov 16, 2020 at 10:17 AM Alex Orlov wrote:
>
> Hello Alan,
>
>
+1 (non-binding)
On Wed, Nov 11, 2020 at 11:15 PM Karl Heinz Marbaise
wrote:
> Hi,
>
> We solved 37 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321432=12343851
>
> There are still a couple of issues left in JIRA:
>
>
[
https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Stein updated MJLINK-50:
--
Summary: Upgrade to Java 8 / Maven 3.1.0 (was: upgrade to Java 8 / Maven
3.1.0)
> Upgr
[
https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Stein resolved MJLINK-50.
---
Fix Version/s: 3.0.0
Resolution: Done
Via https://github.com/apache/maven-jlink-plugin
[
https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224041#comment-17224041
]
Christian Stein edited comment on MJLINK-50 at 10/31/20, 9:57 AM
[
https://issues.apache.org/jira/browse/MJLINK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Stein reassigned MJLINK-50:
-
Assignee: Christian Stein
> upgrade to Java 8 / Maven 3.
[
https://issues.apache.org/jira/browse/SUREFIRE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175569#comment-17175569
]
Christian Stein commented on SUREFIRE-1831:
---
# As quick measure, let's set the default value
Christian Stein created SUREFIRE-1831:
-
Summary: Module path is used without modules being declared by the
project
Key: SUREFIRE-1831
URL: https://issues.apache.org/jira/browse/SUREFIRE-1831
On Wed, Jul 29, 2020 at 6:41 PM Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:
>
> On 7/29/20 5:49 AM, Christian Stein wrote:
> > I wonder whether the logic at [1] is a) the sole place that
> > controls this feature and b) whether it can be enhanced
> > to
Hi,
when using the --module option of javac, the Java source files
of a module are automatically added to the list of to be compiled
files, checking timestamps. This works as expected as long as
existing source files are changed and/or new source files are
added.
If a Java source file is deleted
Hi,
Why do you think it's the Windows node, Robert?
For me, it [1] says 5 times: linux-jdk8-m3.6.x_build
The file separator chars displayed in the log file also points to a Linux
node:
>
> [INFO] The post-build script did not succeed. assert buildLog.text =~
> /(?i) Archive
Happy coding and testing, Maarten and Martin!
On Fri, Jul 10, 2020 at 9:13 PM Robert Scholte wrote:
> Hi,
>
> On behalf of the Apache Maven PMC I am pleased to announce that
> Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> committers
> and they've both accepted this
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153746#comment-17153746
]
Christian Stein commented on SUREFIRE-1811:
---
[~cowwoc] Robert wrote about "ALL-MODULE
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153657#comment-17153657
]
Christian Stein commented on SUREFIRE-1811:
---
> Why insist on module-info.java for such te
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153449#comment-17153449
]
Christian Stein commented on SUREFIRE-1811:
---
There are *9* classy/module-y permutations
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153430#comment-17153430
]
Christian Stein commented on SUREFIRE-1811:
---
> Do you agree?
Yes.
&g
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147540#comment-17147540
]
Christian Stein commented on SUREFIRE-1811:
---
> Not true. Java ignores unknown qualif
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147440#comment-17147440
]
Christian Stein commented on SUREFIRE-1811:
---
Pavel - [https://github.com/PashaTurok
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147438#comment-17147438
]
Christian Stein commented on SUREFIRE-1811:
---
Pavel - here are the two that I know
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147430#comment-17147430
]
Christian Stein edited comment on SUREFIRE-1811 at 6/28/20, 7:55 PM
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147430#comment-17147430
]
Christian Stein commented on SUREFIRE-1811:
---
Tibor, the tone of your post is again
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147423#comment-17147423
]
Christian Stein edited comment on SUREFIRE-1811 at 6/28/20, 7:39 PM
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147423#comment-17147423
]
Christian Stein commented on SUREFIRE-1811:
---
* module-info.*java* in *src/main/java
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146847#comment-17146847
]
Christian Stein commented on SUREFIRE-1811:
---
_"By Three They Come."_
But, t
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146093#comment-17146093
]
Christian Stein commented on SUREFIRE-1811:
---
As noted by Tibor, Surefire should not include
On Sun, Jun 21, 2020 at 8:55 PM Alex Orlov wrote:
>
> Hi all,
>
> New version of maven-failsafe-plugin (3.0.0-M5) has been released and now
> it is possible to have two module-info in one
> project — one in src/main/java and one in src/test/java and to test
> modules on module -path.
> [...]
201 - 300 of 528 matches
Mail list logo