[jira] [Comment Edited] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736358#comment-17736358
]
Herve Boutemy edited comment on MSHARED-1275 at 6/23/23 6:11 AM:
-
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, equivalent call is done when preparing report
execution
https://github.com/apache/maven-site-plugin/blob/8c597d8db03633feb010cacb2a036b1cceb29aee/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java#L231
then yes, checking during generate() means calling twice: all has been checked
before
was (Author: hboutemy):
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, need to clarify yet
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736358#comment-17736358
]
Herve Boutemy commented on MSHARED-1275:
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, need to clarify yet
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-753) javadoc plugin does not find sources in auto-module when creating docs
Henning Schmiedehausen created MJAVADOC-753:
---
Summary: javadoc plugin does not find sources in auto-module when
creating docs
Key: MJAVADOC-753
URL: https://issues.apache.org/jira/browse/MJAVADOC-753
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
clone this repo: [https://github.com/hgschmie/javadoc-bug]
run "mvn clean install"
expected outcome: builds a project, generates a javadoc jar
observed outcome:
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (basepom.default) on
project javadoc-bug: MavenReportException: Error while generating Javadoc:}}
{{[ERROR] Exit code: 1}}
{{[ERROR]
/Users/henning/oss/bugs/javadoc/src/main/java/maven/bugs/internal/InternalImportBindingBuilder.java:7:
error: cannot access Provider}}
{{[ERROR] static final class InternalBindingProvider implements
Provider {}}
{{[ERROR] ^}}
{{[ERROR] class file for javax.inject.Provider not found}}
{{[ERROR] 1 error}}
{{[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages}}
Setting the release to "8" works (but loses the module information)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miguel Ortega updated MBUILDCACHE-45:
-
Attachment: maven-cache.zip
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miguel Ortega updated MBUILDCACHE-45:
-
Attachment: (was: maven-cache.zip)
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736278#comment-17736278
]
Miguel Ortega edited comment on MBUILDCACHE-45 at 6/22/23 8:42 PM:
---
[~olamy] Hello Olivier, in the ticket I attached an example to reproduce, which
is indeed a very simple spring boot project, where I can reproduce what I
described in the ticket.
It seems in a pristine project the cache will not cache "target/classes" files
if I do "mvn clean compile" which seems coherent with the documentation stating
_*"Once the extension is activated, the cache automatically kicks in on every
{{package}} or higher phase."*_
But then again it you do a "mvn clean compile" (where cache does not exists)
and an the "mvn clean package" you get an error as described above, which does
not seem nominal behaviour. Hopefully i'm not missing something obvious.
was (Author: JIRAUSER298944):
[~olamy] Hello Olivier, in the ticket I attached an example to reproduce, which
is indeed a very simple spring boot project, where I can reproduce what I
described in the ticket.
It seems in a pristine project the cache will not cache "target/classes" files
if I do "mvn clean compile" which seems coherent with the documentation stating
_*"Once the extension is activated, the cache automatically kicks in on every
{{package}} or higher phase."*_
But then again it you do a "mvn clean compile" and a the "mvn clean package"
you get an error as described above, which does not seem nominal behaviour.
Hopefully i'm not missing something obvious.
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miguel Ortega updated MBUILDCACHE-45:
-
Description:
+*Step to reproduce*+
1. Execute a first command on a pristine projet( NO CACHE has ever been stored)
{code:java}
mvn test{code}
Results are cached (contrary to documentation that states that "cache will
kick-in automatically on every lifecycle build of phase {{package}} or
higher.") This could also be a feature since tests can be skipped if nothing
changes.
2 . But if I run next:
{code:java}
mvn clean verify
#OR
mvn clean install{code}
Then the build fails
{code:java}
[ERROR] Failed to execute goal
org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
on project demo: Execution repackage of goal
org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
Unable to find main class -> [Help 1]
[ERROR]
{code}
The root cause seems to be that after "clean", the maven target directory is
cleaned and even if the cache is detected, classes are not restored to the
target folder anymore
{code:java}
[INFO] Attempting to restore project com.example:demo from build cache
[INFO] Remote cache is incomplete or missing, trying local build for
com.example:demo
[INFO] Local build found by checksum 596f60b3f5056d7d
[INFO] Found cached build, restoring com.example:demo from cache by checksum
596f60b3f5056d7d
[INFO] Project com.example:demo restored partially. Highest cached goal: test,
requested: install
[INFO] Skipping plugin execution (cached): resources:resources
[INFO] Skipping plugin execution (cached): compiler:compile
[INFO] Skipping plugin execution (cached): resources:testResources
[INFO] Skipping plugin execution (cached): compiler:testCompile
[INFO] Skipping plugin execution (cached): surefire:test {code}
*+Workaround+*
Manually remove cache data or disable cache via command line argument
*+Environment+*
{code:java}
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home:
Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
was:
+*Step to reproduce*+
1. Execute a first command
{code:java}
mvn test{code}
Results are cached (contrary to documentation that states that "cache will
kick-in automatically on every lifecycle build of phase {{package}} or
higher.") This could also be a feature since tests can be skipped if nothing
changes.
2 . But if I run next:
{code:java}
mvn clean verify
#OR
mvn clean install{code}
Then the build fails
{code:java}
[ERROR] Failed to execute goal
org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
on project demo: Execution repackage of goal
org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
Unable to find main class -> [Help 1]
[ERROR]
{code}
The root cause seems to be that after "clean", the maven target directory is
cleaned and even if the cache is detected, classes are not restored to the
target folder anymore
{code:java}
[INFO] Attempting to restore project com.example:demo from build cache
[INFO] Remote cache is incomplete or missing, trying local build for
com.example:demo
[INFO] Local build found by checksum 596f60b3f5056d7d
[INFO] Found cached build, restoring com.example:demo from cache by checksum
596f60b3f5056d7d
[INFO] Project com.example:demo restored partially. Highest cached goal: test,
requested: install
[INFO] Skipping plugin execution (cached): resources:resources
[INFO] Skipping plugin execution (cached): compiler:compile
[INFO] Skipping plugin execution (cached): resources:testResources
[INFO] Skipping plugin execution (cached): compiler:testCompile
[INFO] Skipping plugin execution (cached): surefire:test {code}
*+Workaround+*
Manually remove cache data or disable cache via command line argument
*+Environment+*
{code:java}
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home:
Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that
[jira] [Commented] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736278#comment-17736278
]
Miguel Ortega commented on MBUILDCACHE-45:
--
[~olamy] Hello Olivier, in the ticket I attached an example to reproduce, which
is indeed a very simple spring boot project, where I can reproduce what I
described in the ticket.
It seems in a pristine project the cache will not cache "target/classes" files
if I do "mvn clean compile" which seems coherent with the documentation stating
_*"Once the extension is activated, the cache automatically kicks in on every
{{package}} or higher phase."*_
But then again it you do a "mvn clean compile" and a the "mvn clean package"
you get an error as described above, which does not seem nominal behaviour.
Hopefully i'm not missing something obvious.
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-752) Setting the output directory affects dependencySourceIncludes
[
https://issues.apache.org/jira/browse/MJAVADOC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-752:
Component/s: javadoc
(was: jar)
> Setting the output directory affects dependencySourceIncludes
> -
>
> Key: MJAVADOC-752
> URL: https://issues.apache.org/jira/browse/MJAVADOC-752
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> I have a large, multi-module build (github.com/jdbi/jdbi) where we build
> separate javadoc jars for all modules. These are built with a javadoc plugin
> configuration that writes the javadoc information into target/apidocs. This
> works fine.
> At the end of our build we aggregate all the separate javadoc modules into a
> single documentation site.
> This is the javadoc configuration for that:
> {{
>
> ${project.build.directory}/generated-docs/apidocs
> true
>
> org.jdbi:*
>
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
> }}
> The reactor build tries to load the included modules (org.jdbi:*) but does
> not look into the target/apidocs folder where the javadoc was written but
> from target/generated-docs/apidocs. Setting the output directory for the
> aggregation module affects the directory that the javadoc plugin uses to
> resolve the dependencySourceInclude directory.
> Expected effect: Setting the output directory only affects the place where
> the aggregated doc is written. The plugin still picks up the existing javadoc
> from the target/apidocs folders in the included modules
> Observed effect: Setting the output directory makes the plugin look at the
> wrong folders for the included moduled and does not find the existing
> documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #1179: Remove references to deprecated ReaderFactory in non generated code
gnodet opened a new pull request, #1179: URL: https://github.com/apache/maven/pull/1179 - Prefix the key name for the TransformerContext - Remove references to deprecated ReaderFactory in non generated code Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-484) [Question/Bug?] about requireSameVersion
[
https://issues.apache.org/jira/browse/MENFORCER-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736188#comment-17736188
]
Slawomir Jaranowski commented on MENFORCER-484:
---
{{requireSameVersion}} simply check if given artivacts have the same version
like in example:
https://maven.apache.org/enforcer/enforcer-rules/requireSameVersions.html
{{dependencyConvergence}} check if the same artifact accessible by transitive
dependencies has the same version on all dependency tree levels
https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
> [Question/Bug?] about requireSameVersion
>
>
> Key: MENFORCER-484
> URL: https://issues.apache.org/jira/browse/MENFORCER-484
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireSameVersions
>Reporter: Eugenio Lentini
>Priority: Major
>
> Hello,
> I am using the {{requireSameVersion}} rule but it does not print, like the
> dependency convergence, where issues are.
> There is just an error but via {{mvn dependency:tree -Dverbose}} I cannot see
> any conflict.
> Questions:
> * How does it suppose to work this rule?
> * Is it possible to print the tree as in dependencyConvergence?
> * What is the difference between requireSameVersion and
> dependencyConvergence?
> Thanks in advance for the answers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-7818:
Assignee: Tamas Cservenak
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.9.3
>
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7818:
-
Fix Version/s: 3.9.3
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
> Fix For: 3.9.3
>
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736137#comment-17736137
]
ASF GitHub Bot commented on MNG-7818:
-
lprimak commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238561833
##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
org.hamcrest
hamcrest
-2.2
+${hamcrestVersion}
+test
+
+
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
test
junit
junit
${junitVersion}
test
-
Review Comment:
No. `` section will take precedence and correctly pull
in the newer version, as desired.
However, it won't pull it in unless required (also correct)
It's not desirable to have hamcrest included unless required (as in JUnit 5)
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppCl
[GitHub] [maven] lprimak commented on a diff in pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
lprimak commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238561833
##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
org.hamcrest
hamcrest
-2.2
+${hamcrestVersion}
+test
+
+
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
test
junit
junit
${junitVersion}
test
-
Review Comment:
No. `` section will take precedence and correctly pull
in the newer version, as desired.
However, it won't pull it in unless required (also correct)
It's not desirable to have hamcrest included unless required (as in JUnit 5)
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736136#comment-17736136
]
ASF GitHub Bot commented on MNG-7818:
-
cstamas commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1602674746
From test-arq-suite branch JUnit4 ()locally build maven-3.9.x this PR +
master shrinkwap-resolver + test-arg-suite:
```
[DEBUG]junit:junit:jar:4.13.2:test
[DEBUG] org.hamcrest:hamcrest-core:jar:2.2:test (scope managed from
compile) (version managed from 1.3)
[DEBUG] org.hamcrest:hamcrest:jar:2.2:test (scope managed from
compile) (version managed from 2.2)
```
So, what happens, is that by placing hamcrest BEFORE junit in depMgt, the
hamcrest will "overrule" the 1.3 from junit, and 2.2 (empty hjar) depends on
hamcrest:jar 2.2, so all good.
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[GitHub] [maven] cstamas commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
cstamas commented on PR #1178: URL: https://github.com/apache/maven/pull/1178#issuecomment-1602674746 From test-arq-suite branch JUnit4 ()locally build maven-3.9.x this PR + master shrinkwap-resolver + test-arg-suite: ``` [DEBUG]junit:junit:jar:4.13.2:test [DEBUG] org.hamcrest:hamcrest-core:jar:2.2:test (scope managed from compile) (version managed from 1.3) [DEBUG] org.hamcrest:hamcrest:jar:2.2:test (scope managed from compile) (version managed from 2.2) ``` So, what happens, is that by placing hamcrest BEFORE junit in depMgt, the hamcrest will "overrule" the 1.3 from junit, and 2.2 (empty hjar) depends on hamcrest:jar 2.2, so all good. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736113#comment-17736113 ] ASF GitHub Bot commented on MDEP-872: - elharo merged PR #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326 > update commons-io to 2.13.0 > --- > > Key: MDEP-872 > URL: https://issues.apache.org/jira/browse/MDEP-872 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] elharo merged pull request #326: [MDEP-872] update commons-io to 2.13.0
elharo merged PR #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736112#comment-17736112 ] ASF GitHub Bot commented on MDEP-872: - elharo commented on PR #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326#issuecomment-1602565602 Looks like CI is flaky > update commons-io to 2.13.0 > --- > > Key: MDEP-872 > URL: https://issues.apache.org/jira/browse/MDEP-872 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-872. Resolution: Fixed > update commons-io to 2.13.0 > --- > > Key: MDEP-872 > URL: https://issues.apache.org/jira/browse/MDEP-872 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-872. -- > update commons-io to 2.13.0 > --- > > Key: MDEP-872 > URL: https://issues.apache.org/jira/browse/MDEP-872 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] elharo commented on pull request #326: [MDEP-872] update commons-io to 2.13.0
elharo commented on PR #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326#issuecomment-1602565602 Looks like CI is flaky -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SUREFIRE-2179:
-
Assignee: Konrad Windszus
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. Optionally this parameter should support Maven coordinates which are
> then resolved automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736053#comment-17736053
]
ASF GitHub Bot commented on SUREFIRE-2178:
--
kwin merged PR #666:
URL: https://github.com/apache/maven-surefire/pull/666
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SUREFIRE-2178.
---
Fix Version/s: 3.x-candidate
Resolution: Fixed
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.x-candidate
>
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2182) Log starter implementation on DEBUG level
[ https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed SUREFIRE-2182. - Fix Version/s: 3.x-candidate Resolution: Fixed Fixed in https://github.com/apache/maven-surefire/commit/49e6607fb3b5a0690cddb4fe371b98f80859c843 > Log starter implementation on DEBUG level > - > > Key: SUREFIRE-2182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2182 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.x-candidate > > > In order to ease debugging classpath issues the fork configuration determined > by > [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216] > should be logged with debug level for when using the fork starter. Similarly > a DEBUG log entry should be emitted when the in-process starter is being used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level
[ https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736051#comment-17736051 ] ASF GitHub Bot commented on SUREFIRE-2182: -- kwin merged PR #665: URL: https://github.com/apache/maven-surefire/pull/665 > Log starter implementation on DEBUG level > - > > Key: SUREFIRE-2182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2182 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > In order to ease debugging classpath issues the fork configuration determined > by > [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216] > should be logged with debug level for when using the fork starter. Similarly > a DEBUG log entry should be emitted when the in-process starter is being used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-surefire] kwin merged pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level
kwin merged PR #665: URL: https://github.com/apache/maven-surefire/pull/665 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Reopened] (MNG-7819) Create IT that exercise file locking with snaphots
[ https://issues.apache.org/jira/browse/MNG-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reopened MNG-7819: -- > Create IT that exercise file locking with snaphots > -- > > Key: MNG-7819 > URL: https://issues.apache.org/jira/browse/MNG-7819 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Integration Tests >Reporter: Tamas Cservenak >Priority: Blocker > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Resolver (1.9.8-1.9.12) contained a nasty bug, that was triggered in Maven > under certain circumstances and is related to file locking. > Example reproducer: > * using file-lock factory and file-gav naming > * the built project has a snapshot dependency > * the snapshot dependency has a snapshot parent > * here, model builder will want to resolve parent POM and cause "lock upgrade" > Reproducer for 3.9.2 bug: > https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7819) Create IT that exercise file locking with snaphots
[ https://issues.apache.org/jira/browse/MNG-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7819: Assignee: Tamas Cservenak > Create IT that exercise file locking with snaphots > -- > > Key: MNG-7819 > URL: https://issues.apache.org/jira/browse/MNG-7819 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Integration Tests >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Blocker > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Resolver (1.9.8-1.9.12) contained a nasty bug, that was triggered in Maven > under certain circumstances and is related to file locking. > Example reproducer: > * using file-lock factory and file-gav naming > * the built project has a snapshot dependency > * the snapshot dependency has a snapshot parent > * here, model builder will want to resolve parent POM and cause "lock upgrade" > Reproducer for 3.9.2 bug: > https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7819) Create IT that exercise file locking with snaphots
[ https://issues.apache.org/jira/browse/MNG-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7819. Resolution: Fixed > Create IT that exercise file locking with snaphots > -- > > Key: MNG-7819 > URL: https://issues.apache.org/jira/browse/MNG-7819 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Integration Tests >Reporter: Tamas Cservenak >Priority: Blocker > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Resolver (1.9.8-1.9.12) contained a nasty bug, that was triggered in Maven > under certain circumstances and is related to file locking. > Example reproducer: > * using file-lock factory and file-gav naming > * the built project has a snapshot dependency > * the snapshot dependency has a snapshot parent > * here, model builder will want to resolve parent POM and cause "lock upgrade" > Reproducer for 3.9.2 bug: > https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736028#comment-17736028
]
ASF GitHub Bot commented on MNG-7818:
-
cstamas commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238203575
##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
org.hamcrest
hamcrest
-2.2
+${hamcrestVersion}
+test
+
+
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
test
junit
junit
${junitVersion}
test
-
Review Comment:
I recommend to look at
https://hamcrest.org/JavaHamcrest/distributables#maven-upgrade-example
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736027#comment-17736027
]
ASF GitHub Bot commented on MNG-7818:
-
cstamas commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1602247282
> Test failures are the "locking" issues, not sure how to clean maven repo
in GH actions :(
You mean the IT MNG-7819 ? As that will cleared up once Resolver 1.9.13
released and updated in Maven.
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on a diff in pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
cstamas commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238203575
##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
org.hamcrest
hamcrest
-2.2
+${hamcrestVersion}
+test
+
+
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
test
junit
junit
${junitVersion}
test
-
Review Comment:
I recommend to look at
https://hamcrest.org/JavaHamcrest/distributables#maven-upgrade-example
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] cstamas commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
cstamas commented on PR #1178: URL: https://github.com/apache/maven/pull/1178#issuecomment-1602247282 > Test failures are the "locking" issues, not sure how to clean maven repo in GH actions :( You mean the IT MNG-7819 ? As that will cleared up once Resolver 1.9.13 released and updated in Maven. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736025#comment-17736025
]
Konrad Windszus commented on SUREFIRE-2179:
---
Maybe also supporting wildcards in the same way as documented in
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762
makes sense here as well (in case a dedicated directory is populated with JAR
files through another goal).
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. Optionally this parameter should support Maven coordinates which are
> then resolved automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-64) Apply global exclusions to folder names
Frank Wagner created MBUILDCACHE-64:
---
Summary: Apply global exclusions to folder names
Key: MBUILDCACHE-64
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-64
Project: Maven Build Cache Extension
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Frank Wagner
It is currently not possible to exclude folders by their name, like
{quote}
node_modules
dist
build
...
{quote}
That's because isFilteredOutSubpath(),
[https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L638,]
uses startWith on normalized absolute paths.
That function could be enhanced with an additional criterion like in
[https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L510]
{{filteredOutPaths.stream().anyMatch(it ->
it.getFileName().equals(entry.getFileName()))}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736022#comment-17736022
]
ASF GitHub Bot commented on SUREFIRE-2178:
--
kwin commented on code in PR #666:
URL: https://github.com/apache/maven-surefire/pull/666#discussion_r1238198570
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2534,10 +2544,10 @@ private TestClassPath generateTestClasspath() {
}
/**
- * Return a new set containing only the artifacts accepted by the given
filter.
+ * Return a new set containing only the artifacts not accepted by the
given filter.
*
* @param artifacts The unfiltered artifacts
- * @param filterThe filter to apply
+ * @param filterThe excludes filter to apply
* @return The filtered result
*/
private static Set filterArtifacts(Set artifacts,
ArtifactFilter filter) {
Review Comment:
Can be further improved, but not really related or blocking I think.
Important is that the description is correct now.
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin commented on a diff in pull request #666: [SUREFIRE-2178] clarify classpathDependencyExcludes
kwin commented on code in PR #666:
URL: https://github.com/apache/maven-surefire/pull/666#discussion_r1238198570
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2534,10 +2544,10 @@ private TestClassPath generateTestClasspath() {
}
/**
- * Return a new set containing only the artifacts accepted by the given
filter.
+ * Return a new set containing only the artifacts not accepted by the
given filter.
*
* @param artifacts The unfiltered artifacts
- * @param filterThe filter to apply
+ * @param filterThe excludes filter to apply
* @return The filtered result
*/
private static Set filterArtifacts(Set artifacts,
ArtifactFilter filter) {
Review Comment:
Can be further improved, but not really related or blocking I think.
Important is that the description is correct now.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736021#comment-17736021
]
ASF GitHub Bot commented on SUREFIRE-2178:
--
michael-o commented on code in PR #666:
URL: https://github.com/apache/maven-surefire/pull/666#discussion_r1238197209
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2534,10 +2544,10 @@ private TestClassPath generateTestClasspath() {
}
/**
- * Return a new set containing only the artifacts accepted by the given
filter.
+ * Return a new set containing only the artifacts not accepted by the
given filter.
*
* @param artifacts The unfiltered artifacts
- * @param filterThe filter to apply
+ * @param filterThe excludes filter to apply
* @return The filtered result
*/
private static Set filterArtifacts(Set artifacts,
ArtifactFilter filter) {
Review Comment:
I think the second param needs to be renamed.
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] michael-o commented on a diff in pull request #666: [SUREFIRE-2178] clarify classpathDependencyExcludes
michael-o commented on code in PR #666:
URL: https://github.com/apache/maven-surefire/pull/666#discussion_r1238197209
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2534,10 +2544,10 @@ private TestClassPath generateTestClasspath() {
}
/**
- * Return a new set containing only the artifacts accepted by the given
filter.
+ * Return a new set containing only the artifacts not accepted by the
given filter.
*
* @param artifacts The unfiltered artifacts
- * @param filterThe filter to apply
+ * @param filterThe excludes filter to apply
* @return The filtered result
*/
private static Set filterArtifacts(Set artifacts,
ArtifactFilter filter) {
Review Comment:
I think the second param needs to be renamed.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736019#comment-17736019
]
ASF GitHub Bot commented on SUREFIRE-2178:
--
kwin opened a new pull request, #666:
URL: https://github.com/apache/maven-surefire/pull/666
Add the info that each item of additionalClasspathElements need to be a
filesystem path
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/SUREFIRE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `SUREFIRE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
install`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin opened a new pull request, #666: SUREFIRE-2178 clarify classpathDependencyExcludes
kwin opened a new pull request, #666: URL: https://github.com/apache/maven-surefire/pull/666 Add the info that each item of additionalClasspathElements need to be a filesystem path Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SUREFIRE-2178:
-
Assignee: Konrad Windszus
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-476) Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
Ernst Reissner created MPLUGIN-476:
--
Summary: Cannot invoke
"com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
Key: MPLUGIN-476
URL: https://issues.apache.org/jira/browse/MPLUGIN-476
Project: Maven Plugin Tools
Issue Type: New Feature
Components: Plugin Plugin
Affects Versions: 3.9.0
Reporter: Ernst Reissner
I write a plugin (https://github.com/Reissner/latex-maven-plugin)
and `mvn clean deploy` results in following message:
```
[INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ latex-maven-plugin ---
[INFO] Using 'UTF-8' encoding to read mojo source files.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 14.056 s
[INFO] Finished at: 2023-06-22T09:29:29+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor
(default-descriptor) on project latex-maven-plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor failed: Cannot
invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is
null -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
```
After long search (1 night) I found the following 'reason':
```
package eu.simuline.m2latex.core;
public enum Target {
txt() {
private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
// may throw BuildFailureException TEX01
public void processSource(LatexProcessor latexProcessor,
LatexMainDesc desc) throws
BuildFailureException {
latexProcessor.processLatex2txt(desc);
}
public String getPatternOutputFiles(Settings settings) {
return "^T$T\\.txt$";
}
}, ...;
...
}
```
Removing the line
```
private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
```
'resolves' the problem.
I feel this could indicate not just a bug but a conceptual flaw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level
[
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735997#comment-17735997
]
ASF GitHub Bot commented on SUREFIRE-2182:
--
kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1238087796
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
} else {
ForkConfiguration forkConfiguration =
createForkConfiguration(platform, resolvedJavaModularityResult);
if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+.debug("Using fork starter with configuration "
Review Comment:
Maybe "Using fork starter with configuration implementation " to be in line
with
https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#LL2228C32-L2228C32?
> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined
> by
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
> should be logged with debug level for when using the fork starter. Similarly
> a DEBUG log entry should be emitted when the in-process starter is being used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
