[jira] [Created] (DOXIA-744) Null Pointer Exception
Kai Hofmann created DOXIA-744: - Summary: Null Pointer Exception Key: DOXIA-744 URL: https://issues.apache.org/jira/browse/DOXIA-744 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 2.0.0 Environment: Windows 10 Reporter: Kai Hofmann While trying to run mvn site the following happens: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 01:50 min [INFO] Finished at: 2024-10-02T03:55:28+02:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.20.0:site (default-site) on project templateengine: Failed to render site: Error generating maven-surefire-report-plugin:3.5.0:report report: Cannot invoke "Object.toString()" because "value" is null -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.20.0:site (default-site) on project templateengine: Failed to render site at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:903) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:280) at org.apache.maven.cli.MavenCli.main (MavenCli.java:203) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:568) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to render site at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:119) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (Lif
[jira] [Closed] (DOXIATOOLS-87) Upgrade Guice to 6
[ https://issues.apache.org/jira/browse/DOXIATOOLS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed DOXIATOOLS-87. -- Resolution: Fixed > Upgrade Guice to 6 > -- > > Key: DOXIATOOLS-87 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-87 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Converter >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DOXIATOOLS-87) Upgrade Guice to 6
[ https://issues.apache.org/jira/browse/DOXIATOOLS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned DOXIATOOLS-87: -- Assignee: Sylwester Lachiewicz > Upgrade Guice to 6 > -- > > Key: DOXIATOOLS-87 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-87 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Converter >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIATOOLS-87) Upgrade Guice to 6
[ https://issues.apache.org/jira/browse/DOXIATOOLS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated DOXIATOOLS-87: --- Fix Version/s: doxia-converter-1.4 > Upgrade Guice to 6 > -- > > Key: DOXIATOOLS-87 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-87 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Converter >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1426) Upgrade to Parent 43
Michael Osipov created MSHARED-1426: --- Summary: Upgrade to Parent 43 Key: MSHARED-1426 URL: https://issues.apache.org/jira/browse/MSHARED-1426 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-api Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-api-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1427) Upgrade to Doxia 2.0.0
Michael Osipov created MSHARED-1427: --- Summary: Upgrade to Doxia 2.0.0 Key: MSHARED-1427 URL: https://issues.apache.org/jira/browse/MSHARED-1427 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-api Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-api-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8133) Broken interpolation when external parent references ${project.rootDirectory}
[
https://issues.apache.org/jira/browse/MNG-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8133:
-
Summary: Broken interpolation when external parent references
${project.rootDirectory} (was: Project build breaks when META-POM uses
{project.rootDirectory} (but root is definied))
> Broken interpolation when external parent references ${project.rootDirectory}
> -
>
> Key: MNG-8133
> URL: https://issues.apache.org/jira/browse/MNG-8133
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-beta-3
> Environment: Windows, JDK 17
>Reporter: Matthias Bünger
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> With the introduction of the {project.rootDirectory} variable in MNG-7038 I
> wanted to check if this variable may be a workaround for my PMD-plugin issue
> described in [MPMD-386|https://issues.apache.org/jira/browse/MPMD-386].
> During my tests (Maven-4.0.0-beta-3 on JDK 17) I found some strange behavior,
> for me a bug, when using the variable in a META-POM and a project using the
> META-POM. But step by step
> META-POM:
> * No usage of "{project.rootDirectory}" in META-POM and no definition of root
> directory (I'll use {root="true"} in my examples) brings up the new warning
> that no such folder is defined, but should be defined. - That's okay.
> * Using"{project.rootDirectory}" in the file path of plugin configuration,
> but no definition of root folder brings up the warning and then breaks the
> build with the {IllegalStateException} as describe in the PR of MNG-7038. -
> That's okay as it's uses of the projects variable which is calculated at the
> start, so definition is needed (documented in PR).
> * Using "{project.rootDirectory}" in the file path of plugin configuration
> with root definition let me install the META-POM in my local repository.
> So we have this META-POM (shortend, full example see
> https://github.com/Bukama/mpmd386 maven 4 folder)
> {code:xml}
> http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/xsd/maven-4.1.0.xsd"; root="true">
> 4.1.0
> my.test.mpmd386
> META-POMM4
> 1.0.0
> pom
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
>
>
>
>
> ${project.rootDirectory}/exclude-pmd.properties
>
>
>
>
> {code}
> Now the actual multi-module project which uses the META-POM looks like this.
> {code:xml}
> http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/xsd/maven-4.1.0.xsd"; root="true">
> 4.1.0
> my.test.mpmd386
> MultiModuleRoot
> 0.0.1-SNAPSHOT
> pom
> Multi Module Root
>
> my.test.mpmd386
> META-POMM4
> 1.0.0
>
>
> moduleA
>
>
> {code}
> What we see
> * Usage of the meta-POM
> * Also definies the root directory via {root="true"}, because this is where
> the project specific {exclude-pmd.properties} file is located.
> My expectation now was that the multi module will build and use the
> exclude-file from its root directory. However the build breaks cause Maven
> thinks there is no root directory set.
> {quote}
> [ERROR] Internal error: java.lang.IllegalStateException: Unable to find the
> root directory. Create a .mvn directory in the root directory or add the
> root="true" attribute on the root project's model to identify it. -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.IllegalStateException: Unable to find the root directory. Create a
> .mvn directory in the root directory or add the root="true" attribute on the
> root project's model to identify it.
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:157)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.
[jira] [Created] (MNG-8279) The project local repository and project collectors are using maven.multiModuleProjectDirectory instead of rootDirectory
Guillaume Nodet created MNG-8279:
Summary: The project local repository and project collectors are
using maven.multiModuleProjectDirectory instead of rootDirectory
Key: MNG-8279
URL: https://issues.apache.org/jira/browse/MNG-8279
Project: Maven
Issue Type: Task
Reporter: Guillaume Nodet
Fix For: 4.0.0-beta-5
This can lead to problems on projects using {{}} as this
is not taken into account when computing the
{{maven.multiModuleProjectDirectory}} property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1426) Upgrade to Parent 43
[ https://issues.apache.org/jira/browse/MSHARED-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1426. --- Resolution: Fixed Fixed with [2a556b38815d4944dde79b498436144ff4e89295|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git&a=commit&h=2a556b38815d4944dde79b498436144ff4e89295]. > Upgrade to Parent 43 > > > Key: MSHARED-1426 > URL: https://issues.apache.org/jira/browse/MSHARED-1426 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-api >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8257) Introduce model dialect extension point
[
https://issues.apache.org/jira/browse/MNG-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8257:
-
Fix Version/s: 4.0.x-candidate
4.x / Backlog
(was: 4.0.0-beta-5)
> Introduce model dialect extension point
> ---
>
> Key: MNG-8257
> URL: https://issues.apache.org/jira/browse/MNG-8257
> Project: Maven
> Issue Type: New Feature
> Components: API
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.x / Backlog, 4.0.0
>
>
> Aside of existing {{ModelParser}} we could have {{ModelDialect}} that would
> be "two ways": offering model parser but also model serializer (so read and
> write).
> As if "dialect" is present in system (and XML dialect is in core) translation
> between dialects become possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8280) Bump jlineVersion from 3.26.3 to 3.27.0
[ https://issues.apache.org/jira/browse/MNG-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8280. Fix Version/s: 4.0.0-beta-5 Assignee: Guillaume Nodet Resolution: Fixed > Bump jlineVersion from 3.26.3 to 3.27.0 > --- > > Key: MNG-8280 > URL: https://issues.apache.org/jira/browse/MNG-8280 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > > GitHub Pull Request: https://github.com/apache/maven/pull/1764 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8238) ModelCache incompatible change: computeIfAbsent(org.apache.maven.building.Source, java.lang.String, java.util.function.Supplier)'
[
https://issues.apache.org/jira/browse/MNG-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8238:
-
Affects Version/s: 4.0.0-alpha-13
(was: 4.0.0-beta-4)
> ModelCache incompatible change:
> computeIfAbsent(org.apache.maven.building.Source, java.lang.String,
> java.util.function.Supplier)'
> -
>
> Key: MNG-8238
> URL: https://issues.apache.org/jira/browse/MNG-8238
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Maven3 plugin using ModelBuilder gets this:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree
> (default-cli) on project unused: Execution default-cli of goal
> eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree failed: An
> API incompatibility was encountered while executing
> eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree:
> java.lang.AbstractMethodError: Receiver class
> eu.maveniverse.maven.mima.extensions.mmr.internal.ModelCacheImpl does not
> define or inherit an implementation of the resolved method 'abstract
> java.lang.Object computeIfAbsent(org.apache.maven.building.Source,
> java.lang.String, java.util.function.Supplier)' of interface
> org.apache.maven.model.building.ModelCache.
> {noformat}
> Fixing ModelCacheImpl to implement missing methods lead to another issue:
> missing class {{org.apache.maven.building.Source}} (this class is used by new
> methods on ModelCache interface). This class belongs to artifact
> model-builder-support but the Java package {{org.apache.maven.building}} was
> NEVER exported (nor in mvn3 nor in mvn4).
> Basically, we got to point, that Maven4 broke this compatibility, but there
> is no way to fix it either, as required class is in not exported package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8279) The project local repository and project collectors are using maven.multiModuleProjectDirectory instead of rootDirectory
[
https://issues.apache.org/jira/browse/MNG-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8279:
Assignee: Guillaume Nodet
> The project local repository and project collectors are using
> maven.multiModuleProjectDirectory instead of rootDirectory
>
>
> Key: MNG-8279
> URL: https://issues.apache.org/jira/browse/MNG-8279
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> This can lead to problems on projects using {{}} as this
> is not taken into account when computing the
> {{maven.multiModuleProjectDirectory}} property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8258:
Assignee: Herve Boutemy
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects
> - either disable it
> ({{x}}) if
> they really have a problem with the default Reproducible behaviour
> - or customize locally the value of the default Maven core-provided
> timestamp, to have a project-specific value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8278) Improve speed in stax readers
[ https://issues.apache.org/jira/browse/MNG-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8278. Fix Version/s: 4.0.0-beta-5 Assignee: Guillaume Nodet Resolution: Fixed > Improve speed in stax readers > - > > Key: MNG-8278 > URL: https://issues.apache.org/jira/browse/MNG-8278 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > > GitHub Pull Request: https://github.com/apache/maven/pull/1748 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-350) Upgrade to Parent 43
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-350. - Resolution: Fixed Fixed with [a5a2ebe6e8d73ad3385ceb4528eb692937355acb|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=a5a2ebe6e8d73ad3385ceb4528eb692937355acb]. > Upgrade to Parent 43 > > > Key: DOXIASITETOOLS-350 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-350 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: version-next, 2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1427) Upgrade to Doxia 2.0.0
[ https://issues.apache.org/jira/browse/MSHARED-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1427. --- Resolution: Fixed Fixed with [e0809ea9ed49a02d93eca913e1595b566ac9c084|https://gitbox.apache.org/repos/asf?p=maven-reportin-api.git&a=commit&h=e0809ea9ed49a02d93eca913e1595b566ac9c084]. > Upgrade to Doxia 2.0.0 > -- > > Key: MSHARED-1427 > URL: https://issues.apache.org/jira/browse/MSHARED-1427 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-api >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-350) Upgrade to Parent 43
Michael Osipov created DOXIASITETOOLS-350: - Summary: Upgrade to Parent 43 Key: DOXIASITETOOLS-350 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-350 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: version-next, 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2274) failOnFlakeCount does not work for failsafe
[
https://issues.apache.org/jira/browse/SUREFIRE-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Fesenmeyer updated SUREFIRE-2274:
Description:
The property failOnFlakeCount seems not to work for the failsafe plugin. At
least not as it is documented here:
[https://maven.apache.org/surefire/maven-failsafe-plugin/verify-mojo.html]
h2. Expected behavior
When using the failsafe configuration property {{{}failOnFlakeCount{}}}, I'd
expect that the build fails in case there are more than the specified count of
flakes.
h2. Actual behavior
The build succeeds, even when there are more than the specified count of
flakes. On the console, and the _TEST-***.xml_ report files, flakes are
correctly reported. However, the report {_}failsafe-summary.xml{_}, does not
contain a {{flakes}} property, and thus the verify step fails.
h2. How to reproduce
I've created a reproducer here:
[https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer]
Just run the integration tests for this simple maven project:
mvn verify
The build shows the following output, which is correct, except for the
information that the build succeeded (and status code 0):
{code:java}
...
[INFO] Running de.fesenmeyer.reproducer.ReproducerIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 s
-- in de.fesenmeyer.reproducer.ReproducerIT
[INFO]
[INFO] Results:
[INFO]
[WARNING] Flakes:
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test1
[ERROR] Run 1: ReproducerIT.test1:12 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test1:12 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test2
[ERROR] Run 1: ReproducerIT.test2:17 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test2:17 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[INFO]
[WARNING] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2
[INFO]
[INFO]
[INFO] --- failsafe:3.5.0:verify (default) @ failsafe-flakecount-reproducer ---
[INFO]
[INFO] BUILD SUCCESS
...
{code}
h2. Hint
Probably the Feature currently works for Surefire, it seems like it has been
only tested with Surefire.
was:
The property failOnFlakeCount seems not to work for the failsafe plugin. At
least not as it is documented here:
[https://maven.apache.org/surefire/maven-failsafe-plugin/verify-mojo.html]
h2. Expected behavior
[|https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer#expected-behavior]
When using the failsafe configuration property {{{}failOnFlakeCount{}}}, I'd
expect that the build fails in case there are more than the specified count of
flakes.
h2. Actual behavior
[|https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer#actual-behavior]
The build succeeds, even when there are more than the specified count of
flakes. On the console, and the _TEST-***.xml_ report files, flakes are
correctly reported. However, the report {_}failsafe-summary.xml{_}, does not
contain a {{flakes}} property, and thus the verify step fails.
h2. How to reproduce
I've created a reproducer here:
[https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer]
Just run the integration tests for this simple maven project:
mvn verify
The build shows the following output, which is correct, except for the
information that the build succeeded (and status code 0):
{code}
...
[INFO] Running de.fesenmeyer.reproducer.ReproducerIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 s
-- in de.fesenmeyer.reproducer.ReproducerIT
[INFO]
[INFO] Results:
[INFO]
[WARNING] Flakes:
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test1
[ERROR] Run 1: ReproducerIT.test1:12 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test1:12 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test2
[ERROR] Run 1: ReproducerIT.test2:17 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test2:17 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[INFO]
[WARNING] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2
[INFO]
[INFO]
[INFO] --- failsafe:3.5.0:verify (default) @ failsafe-flakecount-reproducer ---
[INFO]
[INFO] BUILD SUCCESS
...
{code}
h2. Hint
Probably the Feature currently works for Surefire, it seems like it has been
only tested with Surefire.
> failOnFlakeCount does not work for failsafe
> ---
>
> Key: SUREFIRE-2274
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2274
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.5.0
>Reporter: Daniel Fesenmeyer
>
[jira] [Created] (SUREFIRE-2274) failOnFlakeCount does not work for failsafe
Daniel Fesenmeyer created SUREFIRE-2274:
---
Summary: failOnFlakeCount does not work for failsafe
Key: SUREFIRE-2274
URL: https://issues.apache.org/jira/browse/SUREFIRE-2274
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 3.5.0
Reporter: Daniel Fesenmeyer
The property failOnFlakeCount seems not to work for the failsafe plugin. At
least not as it is documented here:
[https://maven.apache.org/surefire/maven-failsafe-plugin/verify-mojo.html]
h2. Expected behavior
[|https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer#expected-behavior]
When using the failsafe configuration property {{{}failOnFlakeCount{}}}, I'd
expect that the build fails in case there are more than the specified count of
flakes.
h2. Actual behavior
[|https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer#actual-behavior]
The build succeeds, even when there are more than the specified count of
flakes. On the console, and the _TEST-***.xml_ report files, flakes are
correctly reported. However, the report {_}failsafe-summary.xml{_}, does not
contain a {{flakes}} property, and thus the verify step fails.
h2. How to reproduce
I've created a reproducer here:
[https://github.com/danielFesenmeyer/failsafe-flakecount-reproducer]
Just run the integration tests for this simple maven project:
mvn verify
The build shows the following output, which is correct, except for the
information that the build succeeded (and status code 0):
{code}
...
[INFO] Running de.fesenmeyer.reproducer.ReproducerIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 s
-- in de.fesenmeyer.reproducer.ReproducerIT
[INFO]
[INFO] Results:
[INFO]
[WARNING] Flakes:
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test1
[ERROR] Run 1: ReproducerIT.test1:12 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test1:12 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[WARNING] de.fesenmeyer.reproducer.ReproducerIT.test2
[ERROR] Run 1: ReproducerIT.test2:17 » IllegalState Try 0 failed
[ERROR] Run 2: ReproducerIT.test2:17 » IllegalState Try 1 failed
[INFO] Run 3: PASS
[INFO]
[INFO]
[WARNING] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2
[INFO]
[INFO]
[INFO] --- failsafe:3.5.0:verify (default) @ failsafe-flakecount-reproducer ---
[INFO]
[INFO] BUILD SUCCESS
...
{code}
h2. Hint
Probably the Feature currently works for Surefire, it seems like it has been
only tested with Surefire.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886120#comment-17886120
]
Michael Osipov commented on DOXIASITETOOLS-343:
---
[~gnodet], [~cstamas], I'd like to do a GA relase in two weeks or so, do you
think you can pick this up until then? I lack the knowledge for.
> Rewrite DefaultSiteTools project management
> ---
>
> Key: DOXIASITETOOLS-343
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The code loads MavenProject from local repositories and uses
> {{project.getBasedir() == null}} to check if the project was loaded from the
> local repository or if it is a real project.
> This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
> model from the local repository, one should use {{ModelBuilder}} and only use
> {{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8230) Rewrite CI friendly versions
[ https://issues.apache.org/jira/browse/MNG-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8230. Resolution: Fixed > Rewrite CI friendly versions > > > Key: MNG-8230 > URL: https://issues.apache.org/jira/browse/MNG-8230 > Project: Maven > Issue Type: New Feature > Components: Core >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-351) Upgrade to Doxia 2.0.0
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-351. - Resolution: Fixed Fixed with [ea6eb76daffa47b4b4fa276fc89b07213c9d7107|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=ea6eb76daffa47b4b4fa276fc89b07213c9d7107]. > Upgrade to Doxia 2.0.0 > -- > > Key: DOXIASITETOOLS-351 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-351 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: version-next, 2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-351) Upgrade to Doxia 2.0.0
Michael Osipov created DOXIASITETOOLS-351: - Summary: Upgrade to Doxia 2.0.0 Key: DOXIASITETOOLS-351 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-351 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: version-next, 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8254) Fix loading DI-powered beans from extensions if mixed in not DI-powered beans
[
https://issues.apache.org/jira/browse/MNG-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8254:
-
Fix Version/s: (was: 4.0.0-beta-5)
> Fix loading DI-powered beans from extensions if mixed in not DI-powered beans
> -
>
> Key: MNG-8254
> URL: https://issues.apache.org/jira/browse/MNG-8254
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 4.0.0-beta-4
>Reporter: Jonas Rutishauser
>Assignee: Guillaume Nodet
>Priority: Major
>
> I am trying to provide alternate implementation for
> {{org.apache.maven.api.services.ModelBuilder}} from a core extension and
> cannot.
> With the fix for MNG-8220 it is possible to overwrite a DI bean as long as it
> is not injected in a bean which is not powered by DI as in this case of
> {{org.apache.maven.project.DefaultProjectBuilder}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIATOOLS-87) Upgrade Guice to 6
Sylwester Lachiewicz created DOXIATOOLS-87: -- Summary: Upgrade Guice to 6 Key: DOXIATOOLS-87 URL: https://issues.apache.org/jira/browse/DOXIATOOLS-87 Project: Maven Doxia Tools Issue Type: Dependency upgrade Components: Doxia Converter Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIATOOLS-86) Upgrade to Doxia 2.0
[ https://issues.apache.org/jira/browse/DOXIATOOLS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed DOXIATOOLS-86. -- Assignee: Sylwester Lachiewicz Resolution: Fixed > Upgrade to Doxia 2.0 > > > Key: DOXIATOOLS-86 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-86 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Converter >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8238) ModelCache incompatible change: computeIfAbsent(org.apache.maven.building.Source, java.lang.String, java.util.function.Supplier)'
[
https://issues.apache.org/jira/browse/MNG-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8238.
Fix Version/s: (was: 4.0.0-beta-5)
Assignee: Guillaume Nodet
Resolution: Fixed
The {{org.apache.maven.model.building.ModelCache}} is deprecated and unused in
Maven 4 anyway, so there's no point in bringing back compatibility for that one
at this point.
If an extension is actually using it *and* can work unchanged with the Maven 3
layer, we may want to revert all the changes that happened on the deprecated
modules, so that they can work with no change. That's currently not planned.
> ModelCache incompatible change:
> computeIfAbsent(org.apache.maven.building.Source, java.lang.String,
> java.util.function.Supplier)'
> -
>
> Key: MNG-8238
> URL: https://issues.apache.org/jira/browse/MNG-8238
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
>
> Maven3 plugin using ModelBuilder gets this:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree
> (default-cli) on project unused: Execution default-cli of goal
> eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree failed: An
> API incompatibility was encountered while executing
> eu.maveniverse.maven.plugins:toolbox:0.2.4-SNAPSHOT:gav-dm-tree:
> java.lang.AbstractMethodError: Receiver class
> eu.maveniverse.maven.mima.extensions.mmr.internal.ModelCacheImpl does not
> define or inherit an implementation of the resolved method 'abstract
> java.lang.Object computeIfAbsent(org.apache.maven.building.Source,
> java.lang.String, java.util.function.Supplier)' of interface
> org.apache.maven.model.building.ModelCache.
> {noformat}
> Fixing ModelCacheImpl to implement missing methods lead to another issue:
> missing class {{org.apache.maven.building.Source}} (this class is used by new
> methods on ModelCache interface). This class belongs to artifact
> model-builder-support but the Java package {{org.apache.maven.building}} was
> NEVER exported (nor in mvn3 nor in mvn4).
> Basically, we got to point, that Maven4 broke this compatibility, but there
> is no way to fix it either, as required class is in not exported package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2271) No logs from testcases visible when running integration tests
[ https://issues.apache.org/jira/browse/SUREFIRE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2271: - Fix Version/s: waiting-for-feedback > No logs from testcases visible when running integration tests > -- > > Key: SUREFIRE-2271 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2271 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.5.0 >Reporter: mikael petterson >Priority: Major > Fix For: waiting-for-feedback > > Attachments: maven-failsafe-plugin_log.txt > > > Hi, > I am running our integration tests with the failsafe plugin using: > mvn clean verify > I can see that logging messages ( slf4j + log4j2) for the unit tests ( > testng) is present in the console. Then when it comes to the integration > tests I don't see any output at all until a test fails, then I see the error > message. > I have log4j2-test.xml files located in the maven modules. > I attach logs when running: > mvn -X failsafe:integration-test > //mikael > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8254) Fix loading DI-powered beans from extensions if mixed in not DI-powered beans
[
https://issues.apache.org/jira/browse/MNG-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8254.
Resolution: Duplicate
> Fix loading DI-powered beans from extensions if mixed in not DI-powered beans
> -
>
> Key: MNG-8254
> URL: https://issues.apache.org/jira/browse/MNG-8254
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 4.0.0-beta-4
>Reporter: Jonas Rutishauser
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> I am trying to provide alternate implementation for
> {{org.apache.maven.api.services.ModelBuilder}} from a core extension and
> cannot.
> With the fix for MNG-8220 it is possible to overwrite a DI bean as long as it
> is not injected in a bean which is not powered by DI as in this case of
> {{org.apache.maven.project.DefaultProjectBuilder}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8280) Bump jlineVersion from 3.26.3 to 3.27.0
Guillaume Nodet created MNG-8280: Summary: Bump jlineVersion from 3.26.3 to 3.27.0 Key: MNG-8280 URL: https://issues.apache.org/jira/browse/MNG-8280 Project: Maven Issue Type: Task Reporter: Guillaume Nodet GitHub Pull Request: https://github.com/apache/maven/pull/1764 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8133) Project build breaks when META-POM uses {project.rootDirectory} (but root is definied)
[
https://issues.apache.org/jira/browse/MNG-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8133:
Assignee: Guillaume Nodet
> Project build breaks when META-POM uses {project.rootDirectory} (but root is
> definied)
> --
>
> Key: MNG-8133
> URL: https://issues.apache.org/jira/browse/MNG-8133
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-beta-3
> Environment: Windows, JDK 17
>Reporter: Matthias Bünger
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> With the introduction of the {project.rootDirectory} variable in MNG-7038 I
> wanted to check if this variable may be a workaround for my PMD-plugin issue
> described in [MPMD-386|https://issues.apache.org/jira/browse/MPMD-386].
> During my tests (Maven-4.0.0-beta-3 on JDK 17) I found some strange behavior,
> for me a bug, when using the variable in a META-POM and a project using the
> META-POM. But step by step
> META-POM:
> * No usage of "{project.rootDirectory}" in META-POM and no definition of root
> directory (I'll use {root="true"} in my examples) brings up the new warning
> that no such folder is defined, but should be defined. - That's okay.
> * Using"{project.rootDirectory}" in the file path of plugin configuration,
> but no definition of root folder brings up the warning and then breaks the
> build with the {IllegalStateException} as describe in the PR of MNG-7038. -
> That's okay as it's uses of the projects variable which is calculated at the
> start, so definition is needed (documented in PR).
> * Using "{project.rootDirectory}" in the file path of plugin configuration
> with root definition let me install the META-POM in my local repository.
> So we have this META-POM (shortend, full example see
> https://github.com/Bukama/mpmd386 maven 4 folder)
> {code:xml}
> http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/xsd/maven-4.1.0.xsd"; root="true">
> 4.1.0
> my.test.mpmd386
> META-POMM4
> 1.0.0
> pom
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
>
>
>
>
> ${project.rootDirectory}/exclude-pmd.properties
>
>
>
>
> {code}
> Now the actual multi-module project which uses the META-POM looks like this.
> {code:xml}
> http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/xsd/maven-4.1.0.xsd"; root="true">
> 4.1.0
> my.test.mpmd386
> MultiModuleRoot
> 0.0.1-SNAPSHOT
> pom
> Multi Module Root
>
> my.test.mpmd386
> META-POMM4
> 1.0.0
>
>
> moduleA
>
>
> {code}
> What we see
> * Usage of the meta-POM
> * Also definies the root directory via {root="true"}, because this is where
> the project specific {exclude-pmd.properties} file is located.
> My expectation now was that the multi module will build and use the
> exclude-file from its root directory. However the build breaks cause Maven
> thinks there is no root directory set.
> {quote}
> [ERROR] Internal error: java.lang.IllegalStateException: Unable to find the
> root directory. Create a .mvn directory in the root directory or add the
> root="true" attribute on the root project's model to identify it. -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.IllegalStateException: Unable to find the root directory. Create a
> .mvn directory in the root directory or add the root="true" attribute on the
> root project's model to identify it.
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:157)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
> Caused
[jira] [Closed] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8258.
Resolution: Fixed
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects
> - either disable it
> ({{x}}) if
> they really have a problem with the default Reproducible behaviour
> - or customize locally the value of the default Maven core-provided
> timestamp, to have a project-specific value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIATOOLS-86) Upgrade to Doxia 2.0
Sylwester Lachiewicz created DOXIATOOLS-86: -- Summary: Upgrade to Doxia 2.0 Key: DOXIATOOLS-86 URL: https://issues.apache.org/jira/browse/DOXIATOOLS-86 Project: Maven Doxia Tools Issue Type: Dependency upgrade Components: Doxia Converter Reporter: Sylwester Lachiewicz Fix For: doxia-converter-1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2273) Bump org.hamcrest:hamcrest from 2.2 to 3.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed SUREFIRE-2273. - Resolution: Fixed > Bump org.hamcrest:hamcrest from 2.2 to 3.0 > -- > > Key: SUREFIRE-2273 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2273 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.5.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-745) Bug within test found
[
https://issues.apache.org/jira/browse/DOXIA-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Hofmann updated DOXIA-745:
--
Affects Version/s: 2.0.0
Description:
[WARN]
C:\Users\PowerStat\Documents\Maven\maven-doxia\doxia-core\src\test\java\org\apache\maven\doxia\parser\AbstractParserTest.java:277:40:
Der Vergleich von String-Literalen sollte mit equals() erfolgen, nicht mit
'!='. [StringLiteralEquality]
Line
if (currentEvent.getName() != "text") {
should be replaced with:
if (!"text".equals(currentEvent.getName())) {
> Bug within test found
> -
>
> Key: DOXIA-745
> URL: https://issues.apache.org/jira/browse/DOXIA-745
> Project: Maven Doxia
> Issue Type: Test
> Components: Core
>Affects Versions: 2.0.0
>Reporter: Kai Hofmann
>Priority: Major
>
> [WARN]
> C:\Users\PowerStat\Documents\Maven\maven-doxia\doxia-core\src\test\java\org\apache\maven\doxia\parser\AbstractParserTest.java:277:40:
> Der Vergleich von String-Literalen sollte mit equals() erfolgen, nicht mit
> '!='. [StringLiteralEquality]
> Line
> if (currentEvent.getName() != "text") {
> should be replaced with:
> if (!"text".equals(currentEvent.getName())) {
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-745) Bug within test found
Kai Hofmann created DOXIA-745: - Summary: Bug within test found Key: DOXIA-745 URL: https://issues.apache.org/jira/browse/DOXIA-745 Project: Maven Doxia Issue Type: Test Components: Core Reporter: Kai Hofmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-745) Bug within test found
[
https://issues.apache.org/jira/browse/DOXIA-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Hofmann updated DOXIA-745:
--
Language: java
> Bug within test found
> -
>
> Key: DOXIA-745
> URL: https://issues.apache.org/jira/browse/DOXIA-745
> Project: Maven Doxia
> Issue Type: Test
> Components: Core
>Affects Versions: 2.0.0
>Reporter: Kai Hofmann
>Priority: Major
>
> [WARN]
> C:\Users\PowerStat\Documents\Maven\maven-doxia\doxia-core\src\test\java\org\apache\maven\doxia\parser\AbstractParserTest.java:277:40:
> Der Vergleich von String-Literalen sollte mit equals() erfolgen, nicht mit
> '!='. [StringLiteralEquality]
> Line
> if (currentEvent.getName() != "text") {
> should be replaced with:
> if (!"text".equals(currentEvent.getName())) {
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
