[jira] [Commented] (MSITE-1002) Maven Site 4 will break code highlight of site generated by Markdown
[ https://issues.apache.org/jira/browse/MSITE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824986#comment-17824986 ] Michael Osipov commented on MSITE-1002: --- [~kwin], ping. > Maven Site 4 will break code highlight of site generated by Markdown > > > Key: MSITE-1002 > URL: https://issues.apache.org/jira/browse/MSITE-1002 > Project: Maven Site Plugin > Issue Type: Bug > Components: doxia integration >Affects Versions: 4.0.0-M13 >Reporter: Xavi Lee >Priority: Major > Attachments: maven-site-3.png, maven-site-4.png > > > repro repo https://github.com/awxiaoxian2020/code-render-bug > master branch is Maven Site 3 with Fluido skin 1 > v4 branch is Maven Site 4 with Fluido skin 2. > Open their respective `target/site/test.html` files in local to see the > rendered result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSITE-1003) Upgrade plugins and components (in ITs)
Michael Osipov created MSITE-1003: - Summary: Upgrade plugins and components (in ITs) Key: MSITE-1003 URL: https://issues.apache.org/jira/browse/MSITE-1003 Project: Maven Site Plugin Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 4.0.0, 4.0.0-M14 * Upgrade to Doxia 2.0.0-M9 * Upgrade to Doxia Sitetools 2.0.0-M17 * Upgrade to Maven Reporting API 4.0.0-M10 * Upgrade to Maven Reporting Impl 4.0.0-M14 * Upgrade to Maven Reporting Exec 4.0.0-M13 * Upgrade to Maven Plugin Tools 3.11.0 * Upgrade to Maven JXR Plugin 3.3.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1362) Upgrade plugins and components (in ITs)
Michael Osipov created MSHARED-1362: --- Summary: Upgrade plugins and components (in ITs) Key: MSHARED-1362 URL: https://issues.apache.org/jira/browse/MSHARED-1362 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-exec Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-exec-2.0.0, maven-reporting-exec-2.0.0-M13 * Upgrade to Maven Site Plugin 4.0.0-M13 * Upgrade to Doxia 2.0.0-M9 * Upgrade to Doxia Sitetools 2.0.0-M17 * Upgrade to Maven Reporting API 4.0.0-M10 * Upgrade to Maven Reporting Impl 4.0.0-M14 * Upgrade to Maven Plugin Tools 3.11.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1361) Upgrade plugins and components (in ITs) (2)
Michael Osipov created MSHARED-1361: --- Summary: Upgrade plugins and components (in ITs) (2) Key: MSHARED-1361 URL: https://issues.apache.org/jira/browse/MSHARED-1361 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0, maven-reporting-impl-4.0.0-M14 * Upgrade to Doxia 2.0.0-M9 * Upgrade to Doxia Sitetools 2.0.0-M17 * Upgrade to Maven Reporting API 4.0.0-M10 * Upgrade to Maven Plugin Tools 3.11.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-322) Upgrade to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-322. - > Upgrade to Doxia 2.0.0-M9 > - > > Key: DOXIASITETOOLS-322 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-322 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > This requires accommodations for DOXIA-709. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-324) Allow configuration of parser per markup
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIASITETOOLS-324: -- Fix Version/s: (was: 2.0.0-M17) > Allow configuration of parser per markup > > > Key: DOXIASITETOOLS-324 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the Doxia parsers being used for the Doxia markup sources have a > fix configuration > (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324). > It would be beneficial to allow to dynamically configure the parsers (based > on a matching markup source path pattern) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-512) Error: descriptor failed: Range [6, 5) out of bounds for length 12
[
https://issues.apache.org/jira/browse/MPLUGIN-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MPLUGIN-512:
Description:
The plugin explodes, when the artifactId does not follow the convention
(maven-xxx-plugin or xxx-maven-plugin) and there is no configuration for prefix
either.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor
(default-descriptor) on project maven-plugin: Execution default-descriptor of
goal org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed:
Range [6, 5) out of bounds for length 12 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor
(default-descriptor) on project maven-plugin: Execution default-descriptor of
goal org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed:
Range [6, 5) out of bounds for length 12
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:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed: Range
[6, 5) out of bounds for length 12
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:133)
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
(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:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
[jira] [Created] (MPLUGIN-512) Error: descriptor failed: Range [6, 5) out of bounds for length 12
Tamas Cservenak created MPLUGIN-512:
---
Summary: Error: descriptor failed: Range [6, 5) out of bounds for
length 12
Key: MPLUGIN-512
URL: https://issues.apache.org/jira/browse/MPLUGIN-512
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.11.0
Reporter: Tamas Cservenak
The plugin explodes.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor
(default-descriptor) on project maven-plugin: Execution default-descriptor of
goal org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed:
Range [6, 5) out of bounds for length 12 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor
(default-descriptor) on project maven-plugin: Execution default-descriptor of
goal org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed:
Range [6, 5) out of bounds for length 12
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:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.11.0:descriptor failed: Range
[6, 5) out of bounds for length 12
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:133)
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
(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
[jira] [Commented] (DOXIASITETOOLS-332) Create anchors for indexable entries automatically
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824957#comment-17824957 ] ASF GitHub Bot commented on DOXIASITETOOLS-332: --- asfgit merged PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139 > Create anchors for indexable entries automatically > -- > > Key: DOXIASITETOOLS-332 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-332 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 2.0.0-M16 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > At some point some wrapping code was dropped which created duplicate IDs in > the output. Doxia 2.0.0-M9 can now natively, without collisions, produce > those IDs. We should enable them by default for site rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-332) Create anchors for indexable entries automatically
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-332. - Resolution: Fixed Fixed with [f394a9d3d724074b186a7d470593d34bfb067253|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git;a=commit;h=f394a9d3d724074b186a7d470593d34bfb067253]. > Create anchors for indexable entries automatically > -- > > Key: DOXIASITETOOLS-332 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-332 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 2.0.0-M16 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > At some point some wrapping code was dropped which created duplicate IDs in > the output. Doxia 2.0.0-M9 can now natively, without collisions, produce > those IDs. We should enable them by default for site rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-332) Create anchors for indexable entries automatically
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824958#comment-17824958 ] ASF GitHub Bot commented on DOXIASITETOOLS-332: --- asfgit merged PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139 > Create anchors for indexable entries automatically > -- > > Key: DOXIASITETOOLS-332 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-332 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 2.0.0-M16 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > At some point some wrapping code was dropped which created duplicate IDs in > the output. Doxia 2.0.0-M9 can now natively, without collisions, produce > those IDs. We should enable them by default for site rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-332] Create anchors for indexable entries automatically [maven-doxia-sitetools]
asfgit merged PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139 -- 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
Re: [PR] [DOXIASITETOOLS-332] Create anchors for indexable entries automatically [maven-doxia-sitetools]
asfgit merged PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139 -- 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] (DOXIASITETOOLS-332) Create anchors for indexable entries automatically
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824956#comment-17824956 ] ASF GitHub Bot commented on DOXIASITETOOLS-332: --- michael-o commented on PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139#issuecomment-1986879067 > Thanks for that. There is still an issue with duplicate anchors in case of skipped/reverse heading levels in the source markup ([#126 (comment)](https://github.com/apache/maven-doxia-sitetools/pull/126#issuecomment-1925656300)). But let's tackle this edge case separately (and it anyhow needs a fix in Doxia itself). Correct, I noticed this one too, needs to be solved with Doxia though. > Create anchors for indexable entries automatically > -- > > Key: DOXIASITETOOLS-332 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-332 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 2.0.0-M16 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > At some point some wrapping code was dropped which created duplicate IDs in > the output. Doxia 2.0.0-M9 can now natively, without collisions, produce > those IDs. We should enable them by default for site rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-332] Create anchors for indexable entries automatically [maven-doxia-sitetools]
michael-o commented on PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139#issuecomment-1986879067 > Thanks for that. There is still an issue with duplicate anchors in case of skipped/reverse heading levels in the source markup ([#126 (comment)](https://github.com/apache/maven-doxia-sitetools/pull/126#issuecomment-1925656300)). But let's tackle this edge case separately (and it anyhow needs a fix in Doxia itself). Correct, I noticed this one too, needs to be solved with Doxia though. -- 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] [Created] (MDEP-910) No hardcoded groupId needed for automatic module/parent resolving in Maven 4
Matthias Bünger created MDEP-910:
Summary: No hardcoded groupId needed for automatic module/parent
resolving in Maven 4
Key: MDEP-910
URL: https://issues.apache.org/jira/browse/MDEP-910
Project: Maven Dependency Plugin
Issue Type: Improvement
Affects Versions: waiting-for-feedback
Reporter: Matthias Bünger
I was asking this on the dev-list last week, but as nobody could answer it (or
at least nobody did answer) I got the feeling that this might be some
unseen/unwanted implementation detail. If I'm wrong please give me a short
explanation for my understanding and ofc close the issue:
I was double checking my Maven 4 examples and was wondering why
automatic version resolving of module dependencies only works when the
groupId is set fixed, but not working when using the project's variable.
To make my question clearer - let's assume a multi-module project with
groupId "test.bukama.maven" and two modules ("ModuleA" and "ModuleB")
where one has the other as a dependency (It's the same with parent
versioning, not only module dependencies btw):
In Maven 3.9.x you can define a module dependencies using projects
variables for "groupId" and "version", e.g.
{code:xml}
${project.groupId}
ModuleA
${project.version}
{code}
With automatic versioning in Maven 4 you can write
{code:xml}
test.bukama.maven
ModuleA
{code}
and get rid fo the repeatabled versions. But when you use the project's
variable for the groupId like in Maven 3.9.x
{code:xml}
${project.groupId}
ModuleA
{code}
you get an error that the version definition is missing:
{quote}[ERROR] The project test.bukama.maven:ModuleB:0.0.1-SNAPSHOT
(D:\Github\Maven4\Maven4\ModuleB\pom.xml) has 1 error
[ERROR] 'dependencies.dependency.version' for
test.bukama.maven:ModuleA:jar is missing. @
test.bukama.maven:ModuleB:[unknown-version],
D:\Github\Maven4\Maven4\ModuleB\pom.xml, line 11, column 9{quote}
The "root" attribute is set to "true" in parent-pom and not set in the
module-poms!
As I havn't found anything on the JIRA about this (but maybe overseen
it), may I ask why you have to hardcode the groupId for automatic
versioning to work? Why Maven 4 assumes the parents project version for
the missing version but does not do the same for the groupId?
Thank you!
Matthias
P.S. For me personal the best would be to only write the artifact of the
projects own module (I think was working in alpha1-snapshot back then if
I remember correctly), but getting rid of the version is most important
for me :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8071) Build in parallel by default
[
https://issues.apache.org/jira/browse/MNG-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824948#comment-17824948
]
Matthias Bünger commented on MNG-8071:
--
I think it's a good idea to do this in Maven 4 by default. Would need a
documentation update ofc to reflect that.
> Build in parallel by default
>
>
> Key: MNG-8071
> URL: https://issues.apache.org/jira/browse/MNG-8071
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Core
>Affects Versions: 4.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> Currently to build in parallel you have to explicitly define {{-T ..}}. What
> about just doing that by default in Maven 4?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNGSITE-534) There is no hint about Maven Daemon - https://maven.apache.org/
[ https://issues.apache.org/jira/browse/MNGSITE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNGSITE-534: Description: Currently on the Maven site itself (maven.apache.org) there is no hint at all, reference to the Maven Daemon .. We should add a reference for downloading it on the page https://maven.apache.org/ The Maven Daemon site on Github https://github.com/apache/maven-mvnd references explicit https://maven.apache.org.. was:Currently on the Maven site itself (maven.apache.org) there is no hint at all, reference to the Maven Daemon .. We should add a reference for downloading it on the page https://maven.apache.org/ > There is no hint about Maven Daemon - https://maven.apache.org/ > --- > > Key: MNGSITE-534 > URL: https://issues.apache.org/jira/browse/MNGSITE-534 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > Currently on the Maven site itself (maven.apache.org) there is no hint at > all, reference to the Maven Daemon .. We should add a reference for > downloading it on the page https://maven.apache.org/ > The Maven Daemon site on Github https://github.com/apache/maven-mvnd > references explicit https://maven.apache.org.. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8071) Build in parallel by default
Karl Heinz Marbaise created MNG-8071:
Summary: Build in parallel by default
Key: MNG-8071
URL: https://issues.apache.org/jira/browse/MNG-8071
Project: Maven
Issue Type: Improvement
Components: Command Line, Core
Affects Versions: 4.0.0
Reporter: Karl Heinz Marbaise
Fix For: Issues to be reviewed for 4.x
Currently to build in parallel you have to explicitly define {{-T ..}}. What
about just doing that by default in Maven 4?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-534) There is no hint about Maven Daemon - https://maven.apache.org/
Karl Heinz Marbaise created MNGSITE-534: --- Summary: There is no hint about Maven Daemon - https://maven.apache.org/ Key: MNGSITE-534 URL: https://issues.apache.org/jira/browse/MNGSITE-534 Project: Maven Project Web Site Issue Type: Improvement Reporter: Karl Heinz Marbaise Currently on the Maven site itself (maven.apache.org) there is no hint at all, reference to the Maven Daemon .. We should add a reference for downloading it on the page https://maven.apache.org/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824936#comment-17824936 ] Elliotte Rusty Harold edited comment on MGPG-111 at 3/9/24 12:42 PM: - Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. Anything else runs counter to the design of Maven and the Maven repository system, and will cause more problems than it solves.The design of the Maven repo system is far from perfect, but it's what we've got, and we can't hack changes into it. Anything better would require a complete rethink of everything beyond jar files and classpaths. It's the classic antipattern of someone wishing the system were other than it is, and trying to pound the round peg into a square hole by using a bigger hammer. Other examples of this antipattern include "functional" programming in Java, various schemes to avoid declaring and handling checked exceptions, and any number of faster XML parsers that achieve speed by changing or subsetting the XML spec. was (Author: elharo): Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824938#comment-17824938 ] Tamas Cservenak commented on MGPG-111: -- Aye, modern tools like takari-lifecycle would even forbid using it. In fact, it enforces that whatever you touch (at source level) be declared as direct dependency. See here http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824936#comment-17824936 ] Elliotte Rusty Harold commented on MGPG-111: Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-111) Clean upn dependency declarations
[ https://issues.apache.org/jira/browse/MGPG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824935#comment-17824935 ] Elliotte Rusty Harold commented on MGPG-111: so com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile is used but not declared. Definitely something to fix. In fact, it sems klikely 3 if not 4 of Used undeclared dependencies detected should be fixed. plexus-cipher needs further investigation. junixsocket-core might need some thought as to how the dependency analyzer can recognize this. > Clean upn dependency declarations > - > > Key: MGPG-111 > URL: https://issues.apache.org/jira/browse/MGPG-111 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Used undeclared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.9.6:provided > [WARNING]org.apache.maven:maven-settings:jar:3.9.6:provided > [WARNING]com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile > [WARNING]org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided > [WARNING] Unused declared dependencies found: > [WARNING]com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile > [WARNING]org.codehaus.plexus:plexus-cipher:jar:2.0:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-332) Create anchors for indexable entries automatically
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824921#comment-17824921 ] ASF GitHub Bot commented on DOXIASITETOOLS-332: --- kwin commented on PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139#issuecomment-1986815451 Thanks for that. There is still an issue with duplicate anchors in case of skipped/reverse heading levels in the source markup. But let's tackle this edge case separately (and it anyhow needs a fix in Doxia itself). > Create anchors for indexable entries automatically > -- > > Key: DOXIASITETOOLS-332 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-332 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 2.0.0-M16 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M17 > > > At some point some wrapping code was dropped which created duplicate IDs in > the output. Doxia 2.0.0-M9 can now natively, without collisions, produce > those IDs. We should enable them by default for site rendering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-332] Create anchors for indexable entries automatically [maven-doxia-sitetools]
kwin commented on PR #139: URL: https://github.com/apache/maven-doxia-sitetools/pull/139#issuecomment-1986815451 Thanks for that. There is still an issue with duplicate anchors in case of skipped/reverse heading levels in the source markup. But let's tackle this edge case separately (and it anyhow needs a fix in Doxia itself). -- 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
[PR] remove repetitive words [maven]
carrychair opened a new pull request, #1436: URL: https://github.com/apache/maven/pull/1436 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] (SUREFIRE-2219) Option to include stdOut/stdErr console logs into test report
[
https://issues.apache.org/jira/browse/SUREFIRE-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824919#comment-17824919
]
ASF GitHub Bot commented on SUREFIRE-2219:
--
kriegaex commented on PR #692:
URL: https://github.com/apache/maven-surefire/pull/692#issuecomment-1986798014
@acouvreur, actually I am just the user having opened SUREFIRE-2219, not the
developer implementing it. Back then, I just had 45 minutes to investigate and
do some back-end leg work to hopefully expedite the implementation, handing
this off to any committers who feel up for the task and are way more competent
regarding content generation via the sink API than I will ever be. I am afraid,
I might just create a mess and cleaning it up might take more effort than
someone else doing it right.
> Option to include stdOut/stdErr console logs into test report
> -
>
> Key: SUREFIRE-2219
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2219
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Report Plugin
>Affects Versions: 3.2.2
>Reporter: Alexander Kriegisch
>Priority: Major
> Attachments: image-2023-12-02-11-16-11-109.png
>
>
> Surefire report XML includes tags capturing console logs, e.g.
> {{testsuite/testcase/system-err}}:
> !image-2023-12-02-11-16-11-109.png!
> As a report reader, I want to see the stdOut/stdErr console logs per test
> case in the HTML report, ideally in a monotype font to easily be able to read
> stack traces.
> This requirement has been discussed online a lot, e.g. on Stack Overflow or
> Reddit. I wonder why such a feature is missing. The HTML report basically
> being an XML transformation from the surefire report, it should not be super
> complicated to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2219] Add test stdErr/stdOut output to ReportTestCase [maven-surefire]
kriegaex commented on PR #692: URL: https://github.com/apache/maven-surefire/pull/692#issuecomment-1986798014 @acouvreur, actually I am just the user having opened SUREFIRE-2219, not the developer implementing it. Back then, I just had 45 minutes to investigate and do some back-end leg work to hopefully expedite the implementation, handing this off to any committers who feel up for the task and are way more competent regarding content generation via the sink API than I will ever be. I am afraid, I might just create a mess and cleaning it up might take more effort than someone else doing it right. -- 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
Re: [PR] Maven 4.0.0-alpha-13 release notes [maven-site]
gnodet commented on PR #499: URL: https://github.com/apache/maven-site/pull/499#issuecomment-1986797653 > Seems legit, as we can tell the difference "Generated by Modello 2.3.0". But, now spotted other difference: older XSD have ASL2 headers, while new one does not have those. Were they present in templates or you just added them by hand? Yes. -- 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] [Comment Edited] (MGPG-90) Signing fails with 3.0.1: "no pinentry"
[ https://issues.apache.org/jira/browse/MGPG-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824918#comment-17824918 ] Tamas Cservenak edited comment on MGPG-90 at 3/9/24 8:43 AM: - 3.2.0 is on vote, it contains Java (Bouncy Castle) based signer, so nothing needed on CI, just provide key (in TSK) and passphrase as "secrets" in form of env variables and you are free to go. See here [https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/examples/deploy-signed-artifacts.html#sign-using-bc-signer] Tested on GH and did deploy successfully signed artifacts to oss.sonatype.org was (Author: cstamas): 3.2.0 is on vote, it contains Java (Bouncy Castle) based signer, so nothing needed on CI, just provide key (in TSK) and passphrase as "secrets" in form of env variables and you are free to go. See here https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/examples/deploy-signed-artifacts.html#sign-using-bc-signer > Signing fails with 3.0.1: "no pinentry" > --- > > Key: MGPG-90 > URL: https://issues.apache.org/jira/browse/MGPG-90 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Jens Reimann >Priority: Blocker > > Starting with 3.0.1 performing a maven release fails in the process of > signing artifacts with the message: "gpg: no pinentry". > I do believe this is due to the fact that in non-interactive mode with a > newer `gpg` version, the gpg plugin forces a "pinentry error" if no pin is > provided. And the release plugin runs the gpg plugin in non-interactive mode > However, not everyone wants to store the pin in a configuration file. > Assuming you have an interactive release process, you also might want an > interactive pin entry. > I would suggest to allow the user to force the pin entry to interactive (not > matter what the current maven context says). That way, you can keep the > current behavior, but still allow a manual/interactive release process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-90) Signing fails with 3.0.1: "no pinentry"
[ https://issues.apache.org/jira/browse/MGPG-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824918#comment-17824918 ] Tamas Cservenak commented on MGPG-90: - 3.2.0 is on vote, it contains Java (Bouncy Castle) based signer, so nothing needed on CI, just provide key (in TSK) and passphrase as "secrets" in form of env variables and you are free to go. See here https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/examples/deploy-signed-artifacts.html#sign-using-bc-signer > Signing fails with 3.0.1: "no pinentry" > --- > > Key: MGPG-90 > URL: https://issues.apache.org/jira/browse/MGPG-90 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Jens Reimann >Priority: Blocker > > Starting with 3.0.1 performing a maven release fails in the process of > signing artifacts with the message: "gpg: no pinentry". > I do believe this is due to the fact that in non-interactive mode with a > newer `gpg` version, the gpg plugin forces a "pinentry error" if no pin is > provided. And the release plugin runs the gpg plugin in non-interactive mode > However, not everyone wants to store the pin in a configuration file. > Assuming you have an interactive release process, you also might want an > interactive pin entry. > I would suggest to allow the user to force the pin entry to interactive (not > matter what the current maven context says). That way, you can keep the > current behavior, but still allow a manual/interactive release process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Maven 4.0.0-alpha-13 release notes [maven-site]
cstamas commented on PR #499: URL: https://github.com/apache/maven-site/pull/499#issuecomment-1986790152 Seems legit, as we can tell the difference :smile: "Generated by Modello 2.3.0". But, now spotted other difference: older XSD have ASL2 headers, while new one does not have those. Were they present in templates or you just added them by hand? -- 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
Re: [PR] Maven 4.0.0-alpha-13 release notes [maven-site]
cstamas commented on PR #499: URL: https://github.com/apache/maven-site/pull/499#issuecomment-1986789727 @gnodet pls review, pused XSDs and redirects. -- 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-2219) Option to include stdOut/stdErr console logs into test report
[
https://issues.apache.org/jira/browse/SUREFIRE-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824917#comment-17824917
]
ASF GitHub Bot commented on SUREFIRE-2219:
--
michael-o commented on PR #692:
URL: https://github.com/apache/maven-surefire/pull/692#issuecomment-1986786689
> Thanks for this feature @kriegaex ! I would also need this feature, do you
need any help on getting the work done ? I'm able to help
Here is a precursor: https://github.com/apache/maven-surefire/pull/670
> Option to include stdOut/stdErr console logs into test report
> -
>
> Key: SUREFIRE-2219
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2219
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Report Plugin
>Affects Versions: 3.2.2
>Reporter: Alexander Kriegisch
>Priority: Major
> Attachments: image-2023-12-02-11-16-11-109.png
>
>
> Surefire report XML includes tags capturing console logs, e.g.
> {{testsuite/testcase/system-err}}:
> !image-2023-12-02-11-16-11-109.png!
> As a report reader, I want to see the stdOut/stdErr console logs per test
> case in the HTML report, ideally in a monotype font to easily be able to read
> stack traces.
> This requirement has been discussed online a lot, e.g. on Stack Overflow or
> Reddit. I wonder why such a feature is missing. The HTML report basically
> being an XML transformation from the surefire report, it should not be super
> complicated to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2219] Add test stdErr/stdOut output to ReportTestCase [maven-surefire]
michael-o commented on PR #692: URL: https://github.com/apache/maven-surefire/pull/692#issuecomment-1986786689 > Thanks for this feature @kriegaex ! I would also need this feature, do you need any help on getting the work done ? I'm able to help Here is a precursor: https://github.com/apache/maven-surefire/pull/670 -- 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
