[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988772#comment-16988772
]
Tibor Digana commented on SUREFIRE-1733:
[~rfscholte]
[~nhoj.patrick]
That's exactly what i am saying the libs are in wrong paths:
*--module-path junit-platform-commons-1.6.0-M1.jar*
*--class-path junit-platform-launcher-1.6.0-M1.jar*
They are both Java Modules capable and thus they should be in Module Path.
WDYT?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
>
[jira] [Commented] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero commented on MNG-6763:
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins is not yet done compiling L, Maven on my workstation cannot find the
new version in our Nexus and remembers that for 24 hours, so unless I delete
the metadata for L (or fiddle with command line parameters) the build will fail
every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
> Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in
> our build process.
> This results in lots of queries (more than 300 in a simple Dropwizard
> project) to our repo which will never succeed. If we could specify that our
> repo only supplies groupIds beginning with org.example, Maven could skip
> update checks for groupIds starting with com.fasterxml.jackson and so on,
> speeding up the build process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6809) Output log error running tests don't show entirely
Shayane Alcantara created MNG-6809:
--
Summary: Output log error running tests don't show entirely
Key: MNG-6809
URL: https://issues.apache.org/jira/browse/MNG-6809
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.5.4
Reporter: Shayane Alcantara
Attachments: Captura de tela de 2019-12-05 11-44-10.png
**Describe the bug**
When compiling any application and there is an test error or failure with a lot
of caracteres, the output log doesn't show the entire log, compromising the
understanding.
**To reproduce**
Steps to reproduce:
{{}}1. Introduce some error to see the log
{{2. Run }}{{sudo mvn clean install}}{{}}
{{3. }}If the error has a lot of caracteres, the log will be cut.
{{4. See the cut log.}}
**Expected behavior**
The entire log should be visible.
**Screenshots**
!Captura de tela de 2019-12-05 11-44-10.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6809) Output log error running tests don't show entirely
[
https://issues.apache.org/jira/browse/MNG-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shayane Alcantara updated MNG-6809:
---
Description:
**Describe the bug**
When compiling any application and there is an test error or failure with a
lot of caracteres, the output log doesn't show the entire log, compromising the
understanding.
**To reproduce**
Steps to reproduce:
1. Introduce some error to see the log
{{2. Run sudo mvn clean install}}
3. If the error has a lot of caracteres, the log will be cut.
{{4. See the cut log.}}
**Expected behavior**
The entire log should be visible.
**Screenshots**
!Captura de tela de 2019-12-05 11-44-10.png!
was:
**Describe the bug**
When compiling any application and there is an test error or failure with a lot
of caracteres, the output log doesn't show the entire log, compromising the
understanding.
**To reproduce**
Steps to reproduce:
{{}}1. Introduce some error to see the log
{{2. Run }}{{sudo mvn clean install}}{{}}
{{3. }}If the error has a lot of caracteres, the log will be cut.
{{4. See the cut log.}}
**Expected behavior**
The entire log should be visible.
**Screenshots**
!Captura de tela de 2019-12-05 11-44-10.png!
> Output log error running tests don't show entirely
> --
>
> Key: MNG-6809
> URL: https://issues.apache.org/jira/browse/MNG-6809
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.5.4
>Reporter: Shayane Alcantara
>Priority: Minor
> Labels: test
> Attachments: Captura de tela de 2019-12-05 11-44-10.png
>
>
> **Describe the bug**
> When compiling any application and there is an test error or failure with a
> lot of caracteres, the output log doesn't show the entire log, compromising
> the understanding.
>
> **To reproduce**
> Steps to reproduce:
> 1. Introduce some error to see the log
> {{2. Run sudo mvn clean install}}
> 3. If the error has a lot of caracteres, the log will be cut.
> {{4. See the cut log.}}
> **Expected behavior**
> The entire log should be visible.
> **Screenshots**
> !Captura de tela de 2019-12-05 11-44-10.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:03 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins is not yet done compiling L, Maven on my workstation cannot find the
new version in our Nexus and remembers that for 24 hours, so unless I delete
the metadata for L (or fiddle with command line parameters) the build will fail
every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
> Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in
> our build
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:06 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for, to force Maven to
query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
> Additionally, we use
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:06 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for, to force Maven to
query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
>
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:07 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven on my workstation which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:08 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process, because it would skip requests
for {{com.fasterxml.jackson.core}} etc.
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:09 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process, because it would skip requests
to {{acme-releases}} for {{com.fasterxml.jackson.core}} etc. (those artifacts
are available in {{acme-central-mirror}}, which is also queried).
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process, because it would skip requests
for {{com.fasterxml.jackson.core}} etc.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml
[jira] [Comment Edited] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988861#comment-16988861
]
dennis lucero edited comment on MNG-6763 at 12/5/19 6:10 PM:
-
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process, because it would skip hundreds
of requests to {{acme-releases}} for {{com.fasterxml.jackson.core}} etc. (those
artifacts are available in {{acme-central-mirror}}, which is also queried).
was (Author: striderapache):
{quote}You should simply use your repository manager which mean to configure
your setting to mirror everything through your own repository manager.
{quote}
This is already done (acme-central-mirror in the settings.xml above)
{quote}Furthermore you have an update policy given with {{always}} on a release
repository this does not make sense...
{quote}
It does make sense. It is used to disable [negative
caching|https://en.wikipedia.org/wiki/Negative_cache]. Is there another option
to disable negative caching?
Consider this situation:
Project P depends on Library L. I make a change on L, give it a new (release)
version number and push it to our Git repo. Then Jenkins will get L, compile it
and push it to our Maven Repository Manager (Nexus, acme-releases in the
settings.xml above). I then update P to include the new version of L and try to
build it.
If Jenkins has not yet finished compiling L, Maven on my workstation cannot
find the new version in our Nexus and remembers that for 24 hours, so unless I
delete the metadata for L (or fiddle with command line parameters) the build
will fail every time in the next 24 hours.
After Jenkins is finished a few minutes later, the new version of L is
available in Nexus and I can build P if and only if Nexus is asked for the new
version again – that’s what {{updatePolicy always}} is for (in this case), to
force Maven to query Nexus again.
{quote}the setup in your repository manager can decide which kind of artifacts
(dependencies) can be provided...
{quote}
But there is currently no way to tell Maven _on my workstation_ which artifacts
could *possibly* be available in a repo. That is what this issue is about. If I
could tell Maven on my workstation to query {{acme-releases}} only for
dependencies with, for example, groupIds beginning with {{com.example.acme}},
this would greatly speed up the build process, because it would skip requests
to {{acme-releases}} for {{com.fasterxml.jackson.core}} etc. (those artifacts
are available in {{acme-central-mirror}}, which is also queried).
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
>
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989056#comment-16989056
]
Robert Scholte commented on SUREFIRE-1733:
--
A little bit of history: I already noticed a long time ago that we're missing
at least one important scope, but this has never been real important until
JUnit5. It introduces a clear separation of API and implementation. Test is not
the right scope anymore, we need something like test-compile and test-runtime,
but that is quite hard introduce.
junit-platform-launcher is only required at test-runtime, but there's simply no
scope available for it.
Some acceptable solutions I can think of:
- give junit-platform-launcher the test scope (other solutions I can think of
are hacks, not going to propose those)
- introduce a parameter like additionalModules, where you specify the module
names(!). You can feed these directly to Plexus java's ResolvePathsRequest.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
>
[jira] [Updated] (MNG-6809) Output log error running tests don't show entirely
[
https://issues.apache.org/jira/browse/MNG-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6809:
Description:
**Describe the bug**
When compiling any application and there is an test error or failure with a
lot of caracteres, the output log doesn't show the entire log, compromising the
understanding.
**To reproduce**
Steps to reproduce:
1. Introduce some error to see the log
{{2. Run sudo mvn test}}
3. If the error has a lot of caracteres, the log will be cut.
{{4. See the cut log.}}
**Expected behavior**
The entire log should be visible.
**Screenshots**
!Captura de tela de 2019-12-05 11-44-10.png!
was:
**Describe the bug**
When compiling any application and there is an test error or failure with a
lot of caracteres, the output log doesn't show the entire log, compromising the
understanding.
**To reproduce**
Steps to reproduce:
1. Introduce some error to see the log
{{2. Run sudo mvn clean install}}
3. If the error has a lot of caracteres, the log will be cut.
{{4. See the cut log.}}
**Expected behavior**
The entire log should be visible.
**Screenshots**
!Captura de tela de 2019-12-05 11-44-10.png!
> Output log error running tests don't show entirely
> --
>
> Key: MNG-6809
> URL: https://issues.apache.org/jira/browse/MNG-6809
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.5.4
>Reporter: Shayane Alcantara
>Priority: Minor
> Labels: test
> Attachments: Captura de tela de 2019-12-05 11-44-10.png
>
>
> **Describe the bug**
> When compiling any application and there is an test error or failure with a
> lot of caracteres, the output log doesn't show the entire log, compromising
> the understanding.
>
> **To reproduce**
> Steps to reproduce:
> 1. Introduce some error to see the log
> {{2. Run sudo mvn test}}
> 3. If the error has a lot of caracteres, the log will be cut.
> {{4. See the cut log.}}
> **Expected behavior**
> The entire log should be visible.
> **Screenshots**
> !Captura de tela de 2019-12-05 11-44-10.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Moved] (SUREFIRE-1734) Output log error running tests don't show entirely
[
https://issues.apache.org/jira/browse/SUREFIRE-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-6809 to SUREFIRE-1734:
---
Component/s: (was: Logging)
Key: SUREFIRE-1734 (was: MNG-6809)
Affects Version/s: (was: 3.5.4)
Project: Maven Surefire (was: Maven)
> Output log error running tests don't show entirely
> --
>
> Key: SUREFIRE-1734
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1734
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Shayane Alcantara
>Priority: Minor
> Labels: test
> Attachments: Captura de tela de 2019-12-05 11-44-10.png
>
>
> **Describe the bug**
> When compiling any application and there is an test error or failure with a
> lot of caracteres, the output log doesn't show the entire log, compromising
> the understanding.
>
> **To reproduce**
> Steps to reproduce:
> 1. Introduce some error to see the log
> {{2. Run sudo mvn test}}
> 3. If the error has a lot of caracteres, the log will be cut.
> {{4. See the cut log.}}
> **Expected behavior**
> The entire log should be visible.
> **Screenshots**
> !Captura de tela de 2019-12-05 11-44-10.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] rfscholte commented on issue #287: [MNG-6065] - Log fail-level option.
rfscholte commented on issue #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#issuecomment-562259775 Talking about `Level` within the context of logging is clear, but we're talking about the context of Maven. Suppose we would talk about `Level 42`, beside the band, what could it mean? 42 directories deep? Advanced user (depending on max level)? Hence I don't think `level` is enough, most likely `severity` or `loglevel` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989186#comment-16989186
]
Tibor Digana commented on SUREFIRE-1733:
[~rfscholte]
[~nhoj.patrick]
{{junit-platform-launcher}} is not a hack. It is a normal dependency in the
junit5 provider that we have in the project. The user does not have it in his
project.
I think we do not need to complicate the things with test-runtime/test-test
scope. I think this is a normal bug of the code. The {{plexus-java}} is used to
separate Cp and MP from POM dependencies. It is not applied to the Provider
dependencies and that's most probably whole problem here. Feel free to comment
on this.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
>
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989189#comment-16989189
]
Robert Scholte commented on SUREFIRE-1733:
--
You misunderstand my point regarding hack: of course junit-platform-launcher is
not a hack, it is required. I could think of hacks to solve this, but I won't
mention those.
Main question: based on which module-descriptor should plexus-java decide to
add the launcher to the module-path?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR]
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989199#comment-16989199
]
Tibor Digana commented on SUREFIRE-1733:
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined. The merge with engines is defined
as well. I only need to check each library whether it is Java Modularity
capable. _IF capable THEN move the lib to MP, ELSE move it to CP._ This is my
understanding so far. Pls comment on this, thx.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989199#comment-16989199
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/5/19 9:56 PM:
-
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library in
provider path whether it is Java Modularity capable. _IF capable THEN move the
lib to MP, ELSE move it to CP._ This is my understanding so far. Pls comment on
this, thx.
was (Author: tibor17):
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library whether
it is Java Modularity capable. _IF capable THEN move the lib to MP, ELSE move
it to CP._ This is my understanding so far. Pls comment on this, thx.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989199#comment-16989199
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/5/19 9:55 PM:
-
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library whether
it is Java Modularity capable. _IF capable THEN move the lib to MP, ELSE move
it to CP._ This is my understanding so far. Pls comment on this, thx.
was (Author: tibor17):
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined. The merge with engines is defined
as well. I only need to check each library whether it is Java Modularity
capable. _IF capable THEN move the lib to MP, ELSE move it to CP._ This is my
understanding so far. Pls comment on this, thx.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
>
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989236#comment-16989236
]
Robert Scholte commented on SUREFIRE-1733:
--
No, that's not correct. Even though I'm not sure what you mean with "capable" (
I assume "it has a module descriptor"), there's no need to do that.
A quick lesson of JPMS: you specify the module with the main-class, plus
optional additional modules. The JDK/JRE will verify if all required modules
(both direct and indirect, or transitive as we would call it) are available.
These are the only useful jars on the modulepath.
With plexus-java you give all artifacts and by specify the main artifact and
based on that it can build up the modulepath and classspath.
Based on
https://github.com/junit-team/junit5/blob/master/junit-platform-launcher/src/module/org.junit.platform.launcher/module-info.java
I don't think this is a provider for some service. But if it is, you can
simply set
github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/ResolvePathsRequest.java#L225
to true.
In general: plexus-java should give you the right module-path, there is no
reason to iterate over the classpath again and shift artifacts. It simply means
plexus-java was fed with incomplete information.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989277#comment-16989277
]
Tibor Digana commented on SUREFIRE-1733:
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these libraries in his
{{module-info.java}} but the thing is that he is not expected to complicate his
life doing it because it is our responsibility and we are not doing it. As a
result these libs appear on classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989277#comment-16989277
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/6/19 12:35 AM:
--
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these (see Surefire
*provider's deps*) libraries in his {{module-info.java}} but the thing is that
he is not expected to complicate his life doing it because it is our
responsibility and we are not doing it. As a result these libs appear on
classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
was (Author: tibor17):
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these libraries in his
{{module-info.java}} but the thing is that he is not expected to complicate his
life doing it because it is our responsibility and we are not doing it. As a
result these libs appear on classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR]
[jira] [Commented] (SUREFIRE-1731) Unable to test Multi Release Jar with surefire or failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989282#comment-16989282 ] Tibor Digana commented on SUREFIRE-1731: Would you help us fixing this issue? I think it would be simple if you copy the fix from the compiler. > Unable to test Multi Release Jar with surefire or failsafe > -- > > Key: SUREFIRE-1731 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1731 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.22.2, 3.0.0-M4 >Reporter: John Patrick >Priority: Major > > I'm creating a Multi Release jar, containing base Java 1.8 and Java 11 > classes. But am not able to successful test the Java 11 part. > In the following repo, I've got 3 tests. > * 1 test needs to be executed using Java 1.8 that are under src/test/java. > * 2 tests need to be executed using Java 11 that are under src/test/java11. > If the src/test/java tests are executed using Java 11 I expect it to fail > which is expected, because it would be picking up the classes under > target/classes/META-INF/versions/11/ and not the Java 1.8 version under > target/classes/. Because the tests have been written to prove the correct > source file is used for execution so the Java 1.8 BaseClass returns a > different string to the Java 11 BaseClass. > [https://github.com/nhojpatrick/issue-maven-multi-release-jar-testing] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1735) Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
Adam Czepil created SUREFIRE-1735:
-
Summary: Using GraalVM toolchain causes NPE when default java is
not set to GraalVM JDK
Key: SUREFIRE-1735
URL: https://issues.apache.org/jira/browse/SUREFIRE-1735
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M4
Reporter: Adam Czepil
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
{{Caused by: java.lang.NullPointerException}}
{{ at org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(SystemUtils.java:141) }}
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1735) Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
[
https://issues.apache.org/jira/browse/SUREFIRE-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Czepil updated SUREFIRE-1735:
--
Description:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
Caused by: java.lang.NullPointerException
{{ \{{ at
org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(SystemUtils.java:141)
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
was:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
{{Caused by: java.lang.NullPointerException}}
{{ at org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(SystemUtils.java:141) }}
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
> Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
> --
>
> Key: SUREFIRE-1735
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1735
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Adam Czepil
>Priority: Major
>
> When I use toolchains and configure GraalVM as the active toolchain AND my
> default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from
> surefire plugin
> Caused by: java.lang.NullPointerException
> {{ \{{ at
> org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
> (SystemUtils.java:141)
> It works fine when I change JAVA_HOME to point to GraalVM home.
> The reason is that
> [https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
> try to read JAVA_VERSION from releases file and GraalVM doesn't have this
> variable there.
> I'm not sure who is at fault, maybe GraalVM should export that var.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1735) Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
[
https://issues.apache.org/jira/browse/SUREFIRE-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Czepil updated SUREFIRE-1735:
--
Description:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
{{}}
*Caused by*: java.lang.NullPointerException
*at*
org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(*SystemUtils.java:141*)
*at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast
(*SystemUtils.java:215*)
*at* org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
(*AbstractSurefireMojo.java:2446*)
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
was:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
Caused by: java.lang.NullPointerException
{{ \{{ at
org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(SystemUtils.java:141)
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
> Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
> --
>
> Key: SUREFIRE-1735
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1735
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Adam Czepil
>Priority: Major
>
> When I use toolchains and configure GraalVM as the active toolchain AND my
> default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from
> surefire plugin
> {{}}
> *Caused by*: java.lang.NullPointerException
> *at*
> org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
> (*SystemUtils.java:141*)
> *at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast
> (*SystemUtils.java:215*)
> *at*
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
> (*AbstractSurefireMojo.java:2446*)
>
> It works fine when I change JAVA_HOME to point to GraalVM home.
> The reason is that
> [https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
> try to read JAVA_VERSION from releases file and GraalVM doesn't have this
> variable there.
> I'm not sure who is at fault, maybe GraalVM should export that var.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1735) Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
[
https://issues.apache.org/jira/browse/SUREFIRE-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Czepil updated SUREFIRE-1735:
--
Description:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
*Caused by*: java.lang.NullPointerException
*at*
org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(*SystemUtils.java:141*)
*at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast
(*SystemUtils.java:215*)
*at* org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
(*AbstractSurefireMojo.java:2446*)
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
was:
When I use toolchains and configure GraalVM as the active toolchain AND my
default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from surefire
plugin
{{}}
*Caused by*: java.lang.NullPointerException
*at*
org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
(*SystemUtils.java:141*)
*at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast
(*SystemUtils.java:215*)
*at* org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
(*AbstractSurefireMojo.java:2446*)
It works fine when I change JAVA_HOME to point to GraalVM home.
The reason is that
[https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
try to read JAVA_VERSION from releases file and GraalVM doesn't have this
variable there.
I'm not sure who is at fault, maybe GraalVM should export that var.
> Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK
> --
>
> Key: SUREFIRE-1735
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1735
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Adam Czepil
>Priority: Major
>
> When I use toolchains and configure GraalVM as the active toolchain AND my
> default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from
> surefire plugin
> *Caused by*: java.lang.NullPointerException
> *at*
> org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile
> (*SystemUtils.java:141*)
> *at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast
> (*SystemUtils.java:215*)
> *at*
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
> (*AbstractSurefireMojo.java:2446*)
>
> It works fine when I change JAVA_HOME to point to GraalVM home.
> The reason is that
> [https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java]
> try to read JAVA_VERSION from releases file and GraalVM doesn't have this
> variable there.
> I'm not sure who is at fault, maybe GraalVM should export that var.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1735) Using GraalVM toolchain causes NPE when default JAVA_HOME is not set to GraalVM JDK's home
[ https://issues.apache.org/jira/browse/SUREFIRE-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Czepil updated SUREFIRE-1735: -- Summary: Using GraalVM toolchain causes NPE when default JAVA_HOME is not set to GraalVM JDK's home (was: Using GraalVM toolchain causes NPE when default java is not set to GraalVM JDK) > Using GraalVM toolchain causes NPE when default JAVA_HOME is not set to > GraalVM JDK's home > -- > > Key: SUREFIRE-1735 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1735 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M4 >Reporter: Adam Czepil >Priority: Major > > When I use toolchains and configure GraalVM as the active toolchain AND my > default JDK is NOT GraalVM (JAVA_HOME != GraalVM) I'm getting NPE from > surefire plugin > *Caused by*: java.lang.NullPointerException > *at* > org.apache.maven.surefire.booter.SystemUtils.toJdkVersionFromReleaseFile > (*SystemUtils.java:141*) > *at* org.apache.maven.surefire.booter.SystemUtils.isJava9AtLeast > (*SystemUtils.java:215*) > *at* > org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm > (*AbstractSurefireMojo.java:2446*) > > It works fine when I change JAVA_HOME to point to GraalVM home. > The reason is that > [https://github.com/apache/maven-surefire/blob/master/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java] > try to read JAVA_VERSION from releases file and GraalVM doesn't have this > variable there. > I'm not sure who is at fault, maybe GraalVM should export that var. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] mthmulders commented on issue #287: [MNG-6065] - Log fail-level option.
mthmulders commented on issue #287: [MNG-6065] - Log fail-level option. URL: https://github.com/apache/maven/pull/287#issuecomment-562465676 > Talking about `Level` within the context of logging is clear, but we're talking about the context of Maven. > Suppose we would talk about `Level 42`, beside the band, what could it mean? 42 directories deep? Advanced user (depending on max level)? Hence I don't think `level` is enough, most likely `severity` or `loglevel` In terms of log messages, I would say that "severity" would make sense. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MENFORCER-334) Regression: pluginVersions in Parent-POM pluginManagement not working
[ https://issues.apache.org/jira/browse/MENFORCER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988578#comment-16988578 ] Wolf Geldmacher commented on MENFORCER-334: --- Looks like it. I somehow missed MENFORCER-306 when I searched for the issue - Sorry. Feel free to mark as duplicate and close. > Regression: pluginVersions in Parent-POM pluginManagement not working > - > > Key: MENFORCER-334 > URL: https://issues.apache.org/jira/browse/MENFORCER-334 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0-M2 > Environment: Maven 3.6.1, Ubuntu 18.04 LTS, Oracle JDK 1.8.0_181 >Reporter: Wolf Geldmacher >Priority: Major > Attachments: enforcer-regression.zip > > > The enforcer plugin no longer accepts versions defined in a parent POMs > pluginManagement section. > In the example project attached you will find two pom.xml files. The one in > the parent directory is to be installed/deployed into the repository and then > to be used as parent POM in the project stub of the project directory. > If the parent defines version 1.4.1 for the maven-enforcer-plugin, everything > works as expected (i.e. when running "mvn validate" in the "project" > directory validation succeeds), when the parent defines version 3.0.0-M2, > validation fails with: > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (default) @ project --- > [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequirePluginVersions > failed with message: > Some plugins are missing valid versions:(LATEST RELEASE SNAPSHOT are not > allowed ) > org.apache.maven.plugins:maven-compiler-plugin. The version currently in use > is 3.8.1 > org.apache.maven.plugins:maven-surefire-plugin. The version currently in use > is 3.0.0-M3 > org.apache.maven.plugins:maven-jar-plugin. The version currently in use is > 3.1.2 > org.apache.maven.plugins:maven-clean-plugin. The version currently in use is > 3.1.0 > org.apache.maven.plugins:maven-install-plugin. The version currently in use > is 3.0.0-M1 > org.apache.maven.plugins:maven-site-plugin. The version currently in use is > 3.7.1 > org.apache.maven.plugins:maven-resources-plugin. The version currently in use > is 3.1.0 > org.apache.maven.plugins:maven-deploy-plugin. The version currently in use is > 3.0.0-M1 > org.apache.maven.plugins:maven-enforcer-plugin. The version currently in use > is 3.0.0-M2 > Best Practice is to always define plugin versions! > even though these versions have been defined in the pluginManagement section > of the parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-334) Regression: pluginVersions in Parent-POM pluginManagement not working
[ https://issues.apache.org/jira/browse/MENFORCER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988570#comment-16988570 ] Tobias Gruetzmacher commented on MENFORCER-334: --- Is this the same as MENFORCER-306? > Regression: pluginVersions in Parent-POM pluginManagement not working > - > > Key: MENFORCER-334 > URL: https://issues.apache.org/jira/browse/MENFORCER-334 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0-M2 > Environment: Maven 3.6.1, Ubuntu 18.04 LTS, Oracle JDK 1.8.0_181 >Reporter: Wolf Geldmacher >Priority: Major > Attachments: enforcer-regression.zip > > > The enforcer plugin no longer accepts versions defined in a parent POMs > pluginManagement section. > In the example project attached you will find two pom.xml files. The one in > the parent directory is to be installed/deployed into the repository and then > to be used as parent POM in the project stub of the project directory. > If the parent defines version 1.4.1 for the maven-enforcer-plugin, everything > works as expected (i.e. when running "mvn validate" in the "project" > directory validation succeeds), when the parent defines version 3.0.0-M2, > validation fails with: > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (default) @ project --- > [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequirePluginVersions > failed with message: > Some plugins are missing valid versions:(LATEST RELEASE SNAPSHOT are not > allowed ) > org.apache.maven.plugins:maven-compiler-plugin. The version currently in use > is 3.8.1 > org.apache.maven.plugins:maven-surefire-plugin. The version currently in use > is 3.0.0-M3 > org.apache.maven.plugins:maven-jar-plugin. The version currently in use is > 3.1.2 > org.apache.maven.plugins:maven-clean-plugin. The version currently in use is > 3.1.0 > org.apache.maven.plugins:maven-install-plugin. The version currently in use > is 3.0.0-M1 > org.apache.maven.plugins:maven-site-plugin. The version currently in use is > 3.7.1 > org.apache.maven.plugins:maven-resources-plugin. The version currently in use > is 3.1.0 > org.apache.maven.plugins:maven-deploy-plugin. The version currently in use is > 3.0.0-M1 > org.apache.maven.plugins:maven-enforcer-plugin. The version currently in use > is 3.0.0-M2 > Best Practice is to always define plugin versions! > even though these versions have been defined in the pluginManagement section > of the parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] S4n60w3n commented on a change in pull request #24: [MDEP-435] Added xml outputType to dependency tree
S4n60w3n commented on a change in pull request #24: [MDEP-435] Added xml
outputType to dependency tree
URL:
https://github.com/apache/maven-dependency-plugin/pull/24#discussion_r354179787
##
File path:
src/main/java/org/apache/maven/plugins/dependency/tree/XMLDependencyNodeVisitor.java
##
@@ -0,0 +1,186 @@
+package org.apache.maven.plugins.dependency.tree;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.xml.parsers.DocumentBuilder;
+import javax.xml.parsers.DocumentBuilderFactory;
+import javax.xml.parsers.ParserConfigurationException;
+import javax.xml.transform.OutputKeys;
+import javax.xml.transform.Transformer;
+import javax.xml.transform.TransformerException;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMSource;
+import javax.xml.transform.stream.StreamResult;
+
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.shared.dependency.graph.DependencyNode;
+import
org.apache.maven.shared.dependency.graph.traversal.DependencyNodeVisitor;
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+import java.io.Writer;
+import java.util.List;
+
+/**
+ * A dependency node visitor that serializes visited nodes to
+ * https://en.wikipedia.org/wiki/XML;>XML format
+ *
+ * @author mailto:sikora.bog...@webscope.io;>Bogdan Sikora
+ * @since 3.1.2
+ */
+public class XMLDependencyNodeVisitor
+extends AbstractSerializingVisitor
+implements DependencyNodeVisitor
+{
+/**
+ * Constructor.
+ *
+ * @param writer the writer to write to.
+ */
+public XMLDependencyNodeVisitor( Writer writer )
+{
+super( writer );
+}
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public boolean visit( DependencyNode node )
+{
+try
+{
+if ( node.getParent() == null || node.getParent() == node )
+{
+DocumentBuilderFactory dbFactory =
DocumentBuilderFactory.newInstance();
Review comment:
@mthmulders I will try to make time for that, but basically if you run my
implementation and yours on this repo and output it to the file. Then you can
make diff. It should be the same
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988745#comment-16988745
]
John Patrick commented on SUREFIRE-1733:
If it's easier it's actually a public repo
https://github.com/nhojpatrick/nhojpatrick-hamcrest with branches being as
listed below;
||Surefire||JUnit||Branch||
|v2.22.2|v5.5.2|jpms|
|v2.22.2|v5.6.0-M1|junit-v5.6.x_jpms|
|v3.0.0-M4|v5.5.2|surefire-failsafe-v3.0.x_jpms|
|v3.0.0-M4|v5.6.0-M1|surefire-failsafe-v3.0.x_junit-v5.6.x_jpms|
But for v3.0.0-M4 and v5.6.0-M1 it is the following args file content;
{code}
[DEBUG] args file content:
--module-path
"PROJECT/target/classes:USER_HOME/.m2/repository/org/hamcrest/hamcrest/2.2/hamcrest-2.2.jar:USER_HOME/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.6.0-M1/junit-jupiter-api-5.6.0-M1.jar:USER_HOME/.m2/repository/org/apiguardian/apiguardian-api/1.1.0/apiguardian-api-1.1.0.jar:USER_HOME/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar:USER_HOME/.m2/repository/org/junit/platform/junit-platform-commons/1.6.0-M1/junit-platform-commons-1.6.0-M1.jar:USER_HOME/.m2/repository/org/slf4j/slf4j-api/1.7.29/slf4j-api-1.7.29.jar"
--class-path
"USER_HOME/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M4/surefire-booter-3.0.0-M4.jar:USER_HOME/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M4/surefire-api-3.0.0-M4.jar:USER_HOME/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M4/surefire-logger-api-3.0.0-M4.jar:PROJECT/target/test-classes:USER_HOME/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.12.1/log4j-slf4j-impl-2.12.1.jar:USER_HOME/.m2/repository/org/apache/logging/log4j/log4j-api/2.12.1/log4j-api-2.12.1.jar:USER_HOME/.m2/repository/org/apache/logging/log4j/log4j-core/2.12.1/log4j-core-2.12.1.jar:USER_HOME/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.6.0-M1/junit-jupiter-engine-5.6.0-M1.jar:USER_HOME/.m2/repository/org/junit/platform/junit-platform-engine/1.6.0-M1/junit-platform-engine-1.6.0-M1.jar:USER_HOME/.m2/repository/org/junit/vintage/junit-vintage-engine/5.6.0-M1/junit-vintage-engine-5.6.0-M1.jar:USER_HOME/.m2/repository/junit/junit/4.12/junit-4.12.jar:USER_HOME/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:USER_HOME/.m2/repository/org/apache/maven/surefire/surefire-junit-platform/3.0.0-M4/surefire-junit-platform-3.0.0-M4.jar:USER_HOME/.m2/repository/org/apache/maven/surefire/common-java5/3.0.0-M4/common-java5-3.0.0-M4.jar:USER_HOME/.m2/repository/org/junit/platform/junit-platform-launcher/1.6.0-M1/junit-platform-launcher-1.6.0-M1.jar"
--patch-module
com.github.nhojpatrick.hamcrest.testing="PROJECT/target/test-classes"
--add-exports
com.github.nhojpatrick.hamcrest.testing/com.github.nhojpatrick.hamcrest.testing=ALL-UNNAMED
--add-modules
com.github.nhojpatrick.hamcrest.testing
--add-reads
com.github.nhojpatrick.hamcrest.testing=ALL-UNNAMED
org.apache.maven.surefire.booter.ForkedBooter
{code}
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline
Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline URL: https://github.com/apache/maven-surefire/pull/256#issuecomment-562083080 @jon-bell The problem is a little different from sending serious data. Our ITs fail because closed stream does not see the errors sent when JVM could not start up. This may include serious issues with JVM (class not found) and in our ITs we expect error message from JVM saying that 70MB Xmx cannot be allocated. It s a kind of race condition on the JVM when `Process.waitFor` has returned with non-zero int and the streams are closed in the same thread T1 however the thread T2 did not have a chance to read out all bytes completely. This was happening with the `maven-shared-utils` library as well but it was not visible so often due to the `Process.waitFor` was called every 10 millis. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline
Tibor17 commented on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline URL: https://github.com/apache/maven-surefire/pull/256#issuecomment-562087769 @jon-bell Essentially what you say is that we should close all the streams ater `BYE`. That makes sense. In opposite to that it means that the `InputStream.close()` should not be called on JVM failure (before receiving `BYE` in `ForkClient`). Would it mean that the T2 should close itself stream after `InputStream.read()` has returned `-1`? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline
Tibor17 commented on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline URL: https://github.com/apache/maven-surefire/pull/256#issuecomment-562083080 @jon-bell The problem is a little different from sending serious data. Our ITs fail because closed stream does not see the errors sent when JVM could not start up. This may include serious issues with JVM (class not found) and in our ITs we expect error message from JVM saying that 70MB Xmx cannot be allocated. It s a kind of race condition on the JVM then `Process.waitFor` has returned with non-zero and the streams are closed in the same thread T1 however the thread T2 did not have a chance to read out all bytes completely. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline
Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline URL: https://github.com/apache/maven-surefire/pull/256#issuecomment-562083080 @jon-bell The problem is a little different from sending serious data. Our ITs fail because closed stream does not see the errors sent when JVM could not start up. This may include serious issues with JVM (class not found) and in our ITs we expect error message from JVM saying that 70MB Xmx cannot be allocated. It s a kind of race condition on the JVM then `Process.waitFor` has returned with non-zero and the streams are closed in the same thread T1 however the thread T2 did not have a chance to read out all bytes completely. This was happening witht the `maven-shared-utils` library but it was not so visible due to `Process.waitFor` was called every 10 millis. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline
Tibor17 edited a comment on issue #256: repackaged external artifacts (utilities) with no duplicates and use in extensions-api with Commandline URL: https://github.com/apache/maven-surefire/pull/256#issuecomment-562083080 @jon-bell The problem is a little different from sending serious data. Our ITs fail because closed stream does not see the errors sent when JVM could not start up. This may include serious issues with JVM (class not found) and in our ITs we expect error message from JVM saying that 70MB Xmx cannot be allocated. It s a kind of race condition on the JVM then `Process.waitFor` has returned with non-zero and the streams are closed in the same thread T1 however the thread T2 did not have a chance to read out all bytes completely. This was happening with the `maven-shared-utils` library as well but it was not visible so often due to the `Process.waitFor` was called every 10 millis. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
