[jira] [Updated] (MPLUGIN-536) Allow generation of documentation for nested POJOs used as @Parameters
[
https://issues.apache.org/jira/browse/MPLUGIN-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated MPLUGIN-536:
--
Description:
As a plugin developer of a plugin with a few dozen complex options, I'd like to
see a new feature where by the generated site documentation and help mojo
document the fields of nested pojos that are present with javadoc comments.
{code:java}
@Parameter
private Thing thing;
{code}
{code:java}
public class Thing {
public Foo getFoo() { ... }
public void setFoo(Foo foo) { ... }
}
{code}
Currently the plugins just report the fully qualified class name as a dead
link, which means nested attributes have to be documented manually and the
consistency of this varies wildly between projects.
I'd either like to see the ability for the documentation to be generated from
project sources, dependency sources, or JavaDoc JARs, or the ability to provide
a custom @Documentation annotation to document attributes in nested objects.
This could be specified within a "schemas" section at the bottom of the goal
HTML page.
was:
As a plugin developer of a plugin with a few dozen complex options, I'd like to
see a new feature where by the generated site documentation and help mojo
document the fields of nested pojos that are present with javadoc comments.
{code:java}
@Parameter
private Thing thing;
{code}
{code:java}
public class Thing {
public Foo getFoo() { ... }
public void setFoo(Foo foo) { ... }
}
{code}
Currently the plugins just report the fully qualified class name as a dead
link, which means nested attributes have to be documented manually and the
consistency of this varies wildly between projects.
I'd either like to see the ability for the documentation to be generated from
project sources, dependency sources, or JavaDoc JARs, or the ability to provide
a custom @Documentation parameter to document attributes in nested objects.
This could be specified within a "schemas" section at the bottom of the goal
HTML page.
> Allow generation of documentation for nested POJOs used as @Parameters
> --
>
> Key: MPLUGIN-536
> URL: https://issues.apache.org/jira/browse/MPLUGIN-536
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: maven-plugin-annotations, Plugin Plugin, Plugin
> Reporting Plugin
>Reporter: Ashley Scopes
>Priority: Minor
>
> As a plugin developer of a plugin with a few dozen complex options, I'd like
> to see a new feature where by the generated site documentation and help mojo
> document the fields of nested pojos that are present with javadoc comments.
> {code:java}
> @Parameter
> private Thing thing;
> {code}
> {code:java}
> public class Thing {
> public Foo getFoo() { ... }
> public void setFoo(Foo foo) { ... }
> }
> {code}
> Currently the plugins just report the fully qualified class name as a dead
> link, which means nested attributes have to be documented manually and the
> consistency of this varies wildly between projects.
> I'd either like to see the ability for the documentation to be generated from
> project sources, dependency sources, or JavaDoc JARs, or the ability to
> provide a custom @Documentation annotation to document attributes in nested
> objects.
> This could be specified within a "schemas" section at the bottom of the goal
> HTML page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-536) Allow generation of documentation for nested POJOs used as @Parameters
Ashley Scopes created MPLUGIN-536:
-
Summary: Allow generation of documentation for nested POJOs used
as @Parameters
Key: MPLUGIN-536
URL: https://issues.apache.org/jira/browse/MPLUGIN-536
Project: Maven Plugin Tools
Issue Type: New Feature
Components: maven-plugin-annotations, Plugin Plugin, Plugin Reporting
Plugin
Reporter: Ashley Scopes
As a plugin developer of a plugin with a few dozen complex options, I'd like to
see a new feature where by the generated site documentation and help mojo
document the fields of nested pojos that are present with javadoc comments.
{code:java}
@Parameter
private Thing thing;
{code}
{code:java}
public class Thing {
public Foo getFoo() { ... }
public void setFoo(Foo foo) { ... }
}
{code}
Currently the plugins just report the fully qualified class name as a dead
link, which means nested attributes have to be documented manually and the
consistency of this varies wildly between projects.
I'd either like to see the ability for the documentation to be generated from
project sources, dependency sources, or JavaDoc JARs, or the ability to provide
a custom @Documentation parameter to document attributes in nested objects.
This could be specified within a "schemas" section at the bottom of the goal
HTML page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-535) maven-plugin-plugin clobbers code block formatting
[
https://issues.apache.org/jira/browse/MPLUGIN-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated MPLUGIN-535:
--
Description:
If a plugin parameter JavaDoc provides a code example within a HTML tag,
then it appears that the generated Help Mojo discards this information and
renders the content inline, discarding whitespace detail. This results in
examples being incorrectly formatted in the help goal.
ewer versions of Java introduce a snippet doclet that can replace this but
this is not available within Java 11 releases of JavaDoc, so needs to be
respected as well.
Example output:
{code}
[INFO] For example:
[INFO]
[INFO] ftp://myorganisation.org/protoc/plugins/myplugin.exe
[INFO]
[INFO]
[INFO] https://myorganisation.org/protoc/plugins/myplugin2.exe
[INFO] foo=bar,baz=bork
[INFO]
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
[INFO]
[INFO] Objects support the following attributes:
{code}
Produced from the following JavaDoc comment (which renders with correct
formatting if using JavaDoc itself):
{code}
/**
* Binary plugins to use with the protobuf compiler, specified as a valid URL.
*
* This includes support for:
*
*
* Local file system objects, specified using {@code
file://path/to/file}
* HTTP resources, specified using {@code
http://example.website/path/to/file}
* HTTPS resources, specified using {@code
https://example.website/path/to/file}
* FTP resources, specified using {@code
ftp://example.server/path/to/file}
*
*
* Additionally, the {@code jar} protocol can be used with any of the
above to
* enable extracting a file from a JAR or ZIP and using it directly.
*
* For example:
* {@code
*
*
*
* ftp://myorganisation.org/protoc/plugins/myplugin.exe
*
*
*
*
* https://myorganisation.org/protoc/plugins/myplugin2.exe
* foo=bar,baz=bork
*
*
*
*
*
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
*
*
* }
*
* Objects support the following attributes:
*
*
* {@code url} - the URL to resolve.
* {@code options} - a string of options to pass to the plugin
* - optional.
* {@code order} - an integer order to run the plugins in. Defaults
* to 100,000. Higher numbers run later than lower numbers.
* {@code skip} - set to {@code true} to skip invoking this plugin -
* useful if you want to control whether the plugin runs via a
* property - optional.
*
*
* @since 2.0.0
*/
@Parameter
@Nullable List binaryUrlPlugins;
{code}
See
https://github.com/ascopes/protobuf-maven-plugin/blob/main/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/mojo/AbstractGenerateMojo.java#L232
for a reproduction.
was:
If a plugin parameter JavaDoc provides a code example within a HTML tag,
then it appears that the generated Help Mojo discards this information and
renders the content inline, discarding whitespace detail. This results in
examples being incorrectly formatted in the help goal.
ewer versions of Java introduce a snippet doclet that can replace this but
this is not available within Java 11 releases of JavaDoc, so needs to be
respected as well.
Example output:
{code}
[INFO] For example:
[INFO]
[INFO] ftp://myorganisation.org/protoc/plugins/myplugin.exe
[INFO]
[INFO]
[INFO] https://myorganisation.org/protoc/plugins/myplugin2.exe
[INFO] foo=bar,baz=bork
[INFO]
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
[INFO]
[INFO] Objects support the following attributes:
{code}
Produced from the following JavaDoc comment (which renders with correct
formatting if using JavaDoc itself):
{code}
/**
* Binary plugins to use with the protobuf compiler, specified as a valid URL.
*
* This includes support for:
*
*
* Local file system objects, specified using {@code
file://path/to/file}
* HTTP resources, specified using {@code
http://example.website/path/to/file}
* HTTPS resources, specified using {@code
https://example.website/path/to/file}
* FTP resources, specified using {@code
ftp://example.server/path/to/file}
*
*
* Additionally, the {@code jar} protocol can be used with any of the
above to
* enable extracting a file from a JAR or ZIP and using it directly.
*
* For example:
* {@code
*
*
*
* ftp://myorganisation.org/protoc/plugins/myplugin.exe
*
*
*
*
* https://myorganisation.org/protoc/plugins/myplugin2.exe
* foo=bar,baz=bork
*
*
*
*
*
jar:https://myorganisation.org
[jira] [Updated] (MPLUGIN-535) maven-plugin-plugin clobbers code block formatting
[
https://issues.apache.org/jira/browse/MPLUGIN-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated MPLUGIN-535:
--
Description:
If a plugin parameter JavaDoc provides a code example within a HTML tag,
then it appears that the generated Help Mojo discards this information and
renders the content inline, discarding whitespace detail. This results in
examples being incorrectly formatted in the help goal.
ewer versions of Java introduce a snippet doclet that can replace this but
this is not available within Java 11 releases of JavaDoc, so needs to be
respected as well.
Example output:
{code}
[INFO] For example:
[INFO]
[INFO] ftp://myorganisation.org/protoc/plugins/myplugin.exe
[INFO]
[INFO]
[INFO] https://myorganisation.org/protoc/plugins/myplugin2.exe
[INFO] foo=bar,baz=bork
[INFO]
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
[INFO]
[INFO] Objects support the following attributes:
{code}
Produced from the following JavaDoc comment (which renders with correct
formatting if using JavaDoc itself):
{code}
/**
* Binary plugins to use with the protobuf compiler, specified as a valid URL.
*
* This includes support for:
*
*
* Local file system objects, specified using {@code
file://path/to/file}
* HTTP resources, specified using {@code
http://example.website/path/to/file}
* HTTPS resources, specified using {@code
https://example.website/path/to/file}
* FTP resources, specified using {@code
ftp://example.server/path/to/file}
*
*
* Additionally, the {@code jar} protocol can be used with any of the
above to
* enable extracting a file from a JAR or ZIP and using it directly.
*
* For example:
* {@code
*
*
*
* ftp://myorganisation.org/protoc/plugins/myplugin.exe
*
*
*
*
* https://myorganisation.org/protoc/plugins/myplugin2.exe
* foo=bar,baz=bork
*
*
*
*
*
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
*
*
* }
*
* Objects support the following attributes:
*
*
* {@code url} - the URL to resolve.
* {@code options} - a string of options to pass to the plugin
* - optional.
* {@code order} - an integer order to run the plugins in. Defaults
* to 100,000. Higher numbers run later than lower numbers.
* {@code skip} - set to {@code true} to skip invoking this plugin -
* useful if you want to control whether the plugin runs via a
* property - optional.
*
*
* @since 2.0.0
*/
@Parameter
@Nullable List binaryUrlPlugins;
{code}
See
https://github.com/ascopes/protobuf-maven-plugin/blob/main/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/mojo/AbstractGenerateMojo.java#L232
for a reproduction.
was:
If a plugin parameter JavaDoc provides a code example within a HTML tag,
then it appears that the generated Help Mojo discards this information and
renders the content inline, discarding whitespace detail. This results in
examples being incorrectly formatted in the help goal.
ewer versions of Java introduce a snippet doclet that can replace this but
this is not available within Java 11 releases of JavaDoc, so needs to be
respected as well.
Example output:
{code}
[INFO] For example:
[INFO]
[INFO] ftp://myorganisation.org/protoc/plugins/myplugin.exe
[INFO]
[INFO]
[INFO] https://myorganisation.org/protoc/plugins/myplugin2.exe
[INFO] foo=bar,baz=bork
[INFO]
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
[INFO]
[INFO] Objects support the following attributes:
{code}
Produced from the following JavaDoc comment (which renders with correct
formatting if using JavaDoc itself):
{code}
/**
* Binary plugins to use with the protobuf compiler, specified as a valid URL.
*
* This includes support for:
*
*
* Local file system objects, specified using {@code
file://path/to/file}
* HTTP resources, specified using {@code
http://example.website/path/to/file}
* HTTPS resources, specified using {@code
https://example.website/path/to/file}
* FTP resources, specified using {@code
ftp://example.server/path/to/file}
*
*
* Additionally, the {@code jar} protocol can be used with any of the
above to
* enable extracting a file from a JAR or ZIP and using it directly.
*
* For example:
* {@code
*
*
*
* ftp://myorganisation.org/protoc/plugins/myplugin.exe
*
*
*
*
* https://myorganisation.org/protoc/plugins/myplugin2.exe
* foo=bar,baz=bork
*
*
*
*
*
jar:https://myorganisation.org/p
[jira] [Created] (MPLUGIN-535) maven-plugin-plugin clobbers code block formatting
Ashley Scopes created MPLUGIN-535:
-
Summary: maven-plugin-plugin clobbers code block formatting
Key: MPLUGIN-535
URL: https://issues.apache.org/jira/browse/MPLUGIN-535
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Reporter: Ashley Scopes
If a plugin parameter JavaDoc provides a code example within a HTML tag,
then it appears that the generated Help Mojo discards this information and
renders the content inline, discarding whitespace detail. This results in
examples being incorrectly formatted in the help goal.
ewer versions of Java introduce a snippet doclet that can replace this but
this is not available within Java 11 releases of JavaDoc, so needs to be
respected as well.
Example output:
{code}
[INFO] For example:
[INFO]
[INFO] ftp://myorganisation.org/protoc/plugins/myplugin.exe
[INFO]
[INFO]
[INFO] https://myorganisation.org/protoc/plugins/myplugin2.exe
[INFO] foo=bar,baz=bork
[INFO]
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
[INFO]
[INFO] Objects support the following attributes:
{code}
Produced from the following JavaDoc comment (which renders with correct
formatting if using JavaDoc itself):
{code}
/**
* Binary plugins to use with the protobuf compiler, specified as a valid URL.
*
* This includes support for:
*
*
* Local file system objects, specified using {@code
file://path/to/file}
* HTTP resources, specified using {@code
http://example.website/path/to/file}
* HTTPS resources, specified using {@code
https://example.website/path/to/file}
* FTP resources, specified using {@code
ftp://example.server/path/to/file}
*
*
* Additionally, the {@code jar} protocol can be used with any of the
above to
* enable extracting a file from a JAR or ZIP and using it directly.
*
* For example:
* {@code
*
*
*
* ftp://myorganisation.org/protoc/plugins/myplugin.exe
*
*
*
*
* https://myorganisation.org/protoc/plugins/myplugin2.exe
* foo=bar,baz=bork
*
*
*
*
*
jar:https://myorganisation.org/protoc/plugins/myplugin3.zip!/protoc-gen-something.exe
*
*
* }
*
* Objects support the following attributes:
*
*
* {@code url} - the URL to resolve.
* {@code options} - a string of options to pass to the plugin
* - optional.
* {@code order} - an integer order to run the plugins in. Defaults
* to 100,000. Higher numbers run later than lower numbers.
* {@code skip} - set to {@code true} to skip invoking this plugin -
* useful if you want to control whether the plugin runs via a
* property - optional.
*
*
* @since 2.0.0
*/
@Parameter
@Nullable List binaryUrlPlugins;
{code}
See
https://github.com/ascopes/protobuf-maven-plugin/blob/main/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/mojo/AbstractGenerateMojo.java#L232
for a reproduction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRELEASE-1149) Current release of the plugin has configuration docs missing
[
https://issues.apache.org/jira/browse/MRELEASE-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated MRELEASE-1149:
Description:
If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and
click "Goals", I am getting a 404 back. This seems to be fairly recent but I do
not have a nice way of viewing the parameters for this plugin as a result.
It may just need the site being redeployed, not entirely sure. I noticed the
site descriptor has not been changed for a long time so I don't believe it is
related to that, so may need an internal fix.
The plugin documentation report is also missing though. May be related to
recent updates in {{maven-plugin-plugin}} perhaps?
was:
If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and
click "Goals", I am getting a 404 back. This seems to be fairly recent but I do
not have a nice way of viewing the parameters for this plugin as a result.
It may just need the site being redeployed, not entirely sure. I noticed the
site descriptor has not been changed for a long time so I don't believe it is
related to that, so may need an internal fix.
The plugin documentation report is also missing though. May be related?
> Current release of the plugin has configuration docs missing
>
>
> Key: MRELEASE-1149
> URL: https://issues.apache.org/jira/browse/MRELEASE-1149
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.1.0
> Environment: Prod website
>Reporter: Ashley Scopes
>Priority: Major
>
> If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and
> click "Goals", I am getting a 404 back. This seems to be fairly recent but I
> do not have a nice way of viewing the parameters for this plugin as a result.
> It may just need the site being redeployed, not entirely sure. I noticed the
> site descriptor has not been changed for a long time so I don't believe it is
> related to that, so may need an internal fix.
> The plugin documentation report is also missing though. May be related to
> recent updates in {{maven-plugin-plugin}} perhaps?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRELEASE-1149) Current release of the plugin has configuration docs missing
[ https://issues.apache.org/jira/browse/MRELEASE-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashley Scopes updated MRELEASE-1149: Description: If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and click "Goals", I am getting a 404 back. This seems to be fairly recent but I do not have a nice way of viewing the parameters for this plugin as a result. It may just need the site being redeployed, not entirely sure. I noticed the site descriptor has not been changed for a long time so I don't believe it is related to that, so may need an internal fix. The plugin documentation report is also missing though. May be related? was: If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and click "Goals", I am getting a 404 back. This seems to be fairly recent but I do not have a nice way of viewing the parameters for this plugin as a result. It may just need the site being redeployed, not entirely sure. I noticed the site descriptor has not been changed for a long time so I don't believe it is related to that, so may need an internal fix. > Current release of the plugin has configuration docs missing > > > Key: MRELEASE-1149 > URL: https://issues.apache.org/jira/browse/MRELEASE-1149 > Project: Maven Release Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 3.1.0 > Environment: Prod website >Reporter: Ashley Scopes >Priority: Major > > If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and > click "Goals", I am getting a 404 back. This seems to be fairly recent but I > do not have a nice way of viewing the parameters for this plugin as a result. > It may just need the site being redeployed, not entirely sure. I noticed the > site descriptor has not been changed for a long time so I don't believe it is > related to that, so may need an internal fix. > The plugin documentation report is also missing though. May be related? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1149) Current release of the plugin has configuration docs missing
Ashley Scopes created MRELEASE-1149: --- Summary: Current release of the plugin has configuration docs missing Key: MRELEASE-1149 URL: https://issues.apache.org/jira/browse/MRELEASE-1149 Project: Maven Release Plugin Issue Type: Bug Components: documentation Affects Versions: 3.1.0 Environment: Prod website Reporter: Ashley Scopes If I visit https://maven.apache.org/maven-release/maven-release-plugin/ and click "Goals", I am getting a 404 back. This seems to be fairly recent but I do not have a nice way of viewing the parameters for this plugin as a result. It may just need the site being redeployed, not entirely sure. I noticed the site descriptor has not been changed for a long time so I don't believe it is related to that, so may need an internal fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845700#comment-17845700
]
Ashley Scopes edited comment on MWRAPPER-133 at 5/12/24 11:57 AM:
--
We had the same issue, which was unfortunate.
For us, we have a Groovy function that we reuse to inject our default Maven
settings via the `withMaven` pipeline script plugin. To address this, we
injected the fixed environment variables into the function.
{code:groovy}
// vars/withMavenConfig.groovy
void call(Closure closure) {
withMaven(...) {
withEnv(["MAVEN_ARGS='${env.MAVEN_CONFIG}'"]) {
closure()
}
}
}
{code}
{code:groovy}
pipeline {
agent { label "master" }
environment { ... }
stages {
stage("Run") {
steps {
script {
withMavenConfig {
sh("./mvnw -B clean verify")
}
}
}
}
}
}
{code}
This is far from ideal though...
That being said, I feel that maybe Apache shouldn't have just totally removed
this, and instead deprecated it explicitly and made the wrapper log a warning
when encountered this, as this caused a lot of issues for us.
was (Author: JIRAUSER291213):
We had the same issue, which was unfortunate.
For us, we have a Groovy function that we reuse to inject our default Maven
settings via the `withMaven` pipeline script plugin. To address this, we
injected the fixed environment variables into the function.
{code:groovy}
void withCommonMavenSettings(Closure closure) {
withMaven(...) {
withEnv(["MAVEN_ARGS='${MAVEN_CONFIG}'"]) {
closure()
}
}
}
{code}
This is far from ideal though...
That being said, I feel that maybe Apache shouldn't have just totally removed
this, and instead deprecated it explicitly and made the wrapper log a warning
when encountered this, as this caused a lot of issues for us.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845700#comment-17845700
]
Ashley Scopes commented on MWRAPPER-133:
We had the same issue, which was unfortunate.
For us, we have a Groovy function that we reuse to inject our default Maven
settings via the `withMaven` pipeline script plugin. To address this, we
injected the fixed environment variables into the function.
{code:groovy}
void withCommonMavenSettings(Closure closure) {
withMaven(...) {
withEnv(["MAVEN_ARGS='${MAVEN_CONFIG}'"]) {
closure()
}
}
}
{code}
This is far from ideal though...
That being said, I feel that maybe Apache shouldn't have just totally removed
this, and instead deprecated it explicitly and made the wrapper log a warning
when encountered this, as this caused a lot of issues for us.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-137) Can't match distributionUrl when using MINGW64
[
https://issues.apache.org/jira/browse/MWRAPPER-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845699#comment-17845699
]
Ashley Scopes commented on MWRAPPER-137:
Didn't see this until after I'd raised a ticket and raised a fix for this...
JIRA hid this issue from me for some odd reason.
Raised a fix for this under MWRAPPER-139 at
https://github.com/apache/maven-wrapper/pull/139
> Can't match distributionUrl when using MINGW64
> --
>
> Key: MWRAPPER-137
> URL: https://issues.apache.org/jira/browse/MWRAPPER-137
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.1
>Reporter: Robert Scholte
>Priority: Major
>
> Any mvnw command fails with the following message:
> {noformat}
> $ ./mvnw verify
> 'istributionUrl is not valid, must match *-bin.zip or maven-mvnd-*.zip, but
> found
> 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/apache-maven-4.0.0-alpha-13-bin.zip
> {noformat}
> Also notice that the {{d}} from distributionUrl has been replaced with a
> single quote.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-139) Shell scripts break on LF in config for Windows
Ashley Scopes created MWRAPPER-139:
--
Summary: Shell scripts break on LF in config for Windows
Key: MWRAPPER-139
URL: https://issues.apache.org/jira/browse/MWRAPPER-139
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.3.1
Reporter: Ashley Scopes
Today, I updated the Maven Wrapper in a project I have on GitHub by running
`./mvnw wrapper:wrapper`, and then pushed it to GitHub.
It appears that upon doing this, the bash scripts no longer work due to how
newlines are being interpreted in the maven-wrapper.properties file.
{code}
+ ./mvnw --version
distributionUrl is not valid, must match *-bin.zip or maven-mvnd-*.zip, but
found
'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.6/apache-maven-3.9.6-bin.zip
'
{code}
This appears to just affect when running on GitHub actions with a Windows
runner and the `bash` shell.
I will see if I can find the issue and raise a fix in an MR
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
[
https://issues.apache.org/jira/browse/SUREFIRE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated SUREFIRE-2101:
Description:
If I enable phrased test naming in config, and then write a test such as the
following:
{code:java}
// Note no @DisplayName("...")
class SomeTest {
void fooHasThreeCharacters() {
assertThat(foo).hasSize(3);
}
}
{code}
...then the console reports will contain a null name rather than something
meaningful.
I am proposing that when this phrased name is unavailable, Surefire should fall
back to the original test name that would have been provided if phrased naming
was disabled. The reasoning behind this is that showing an unformatted class
name is more useful to the developer reading Maven logs than just the phrase
{{null}}.
!example-reproduction.png!
was:
If I enable phrased test naming in config, and then write a test such as the
following:
{code:java}
// Note no @DisplayName("...")
class SomeTest {
void fooHasThreeCharacters() {
assertThat(foo).hasSize(3)
}
}
{code}
...then the console reports will contain a null name rather than something
meaningful.
I am proposing that when this phrased name is unavailable, Surefire should fall
back to the original test name that would have been provided if phrased naming
was disabled. The reasoning behind this is that showing an unformatted class
name is more useful to the developer reading Maven logs than just the phrase
{{null}}.
!example-reproduction.png!
> Phrased test names with missing @DisplayName result in a "null" test name
> -
>
> Key: SUREFIRE-2101
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M7
> Environment: All platforms
>Reporter: Ashley Scopes
>Priority: Minor
> Attachments: example-reproduction.png
>
>
> If I enable phrased test naming in config, and then write a test such as the
> following:
> {code:java}
> // Note no @DisplayName("...")
> class SomeTest {
> void fooHasThreeCharacters() {
> assertThat(foo).hasSize(3);
> }
> }
> {code}
> ...then the console reports will contain a null name rather than something
> meaningful.
> I am proposing that when this phrased name is unavailable, Surefire should
> fall back to the original test name that would have been provided if phrased
> naming was disabled. The reasoning behind this is that showing an unformatted
> class name is more useful to the developer reading Maven logs than just the
> phrase {{null}}.
> !example-reproduction.png!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
[
https://issues.apache.org/jira/browse/SUREFIRE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556071#comment-17556071
]
Ashley Scopes commented on SUREFIRE-2101:
-
I have opened a PR at https://github.com/apache/maven-surefire/pull/549 to
address this issue.
> Phrased test names with missing @DisplayName result in a "null" test name
> -
>
> Key: SUREFIRE-2101
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M7
> Environment: All platforms
>Reporter: Ashley Scopes
>Priority: Minor
> Attachments: example-reproduction.png
>
>
> If I enable phrased test naming in config, and then write a test such as the
> following:
> {code:java}
> // Note no @DisplayName("...")
> class SomeTest {
> void fooHasThreeCharacters() {
> assertThat(foo).hasSize(3)
> }
> }
> {code}
> ...then the console reports will contain a null name rather than something
> meaningful.
> I am proposing that when this phrased name is unavailable, Surefire should
> fall back to the original test name that would have been provided if phrased
> naming was disabled. The reasoning behind this is that showing an unformatted
> class name is more useful to the developer reading Maven logs than just the
> phrase {{null}}.
> !example-reproduction.png!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
[
https://issues.apache.org/jira/browse/SUREFIRE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated SUREFIRE-2101:
Description:
If I enable phrased test naming in config, and then write a test such as the
following:
{code:java}
// Note no @DisplayName("...")
class SomeTest {
void fooHasThreeCharacters() {
assertThat(foo).hasSize(3)
}
}
{code}
...then the console reports will contain a null name rather than something
meaningful.
I am proposing that when this phrased name is unavailable, Surefire should fall
back to the original test name that would have been provided if phrased naming
was disabled. The reasoning behind this is that showing an unformatted class
name is more useful to the developer reading Maven logs than just the phrase
{{null}}.
!example-reproduction.png!
was:
If I enable phrased test naming in config, and then write a test such as the
following:
{code:java}
// Note no @DisplayName("...")
class SomeTest {
void fooHasThreeCharacters() {
assertThat(foo).hasSize(3)
}
}
{code}
...then the console reports will contain a null name rather than something
meaningful.
I am proposing that when this phrased name is unavailable, Surefire should fall
back to the original test name that would have been provided if phrased naming
was disabled. The reasoning behind this is that showing an unformatted class
name is more useful to the developer reading Maven logs than just the phrase
{{null}}.
> Phrased test names with missing @DisplayName result in a "null" test name
> -
>
> Key: SUREFIRE-2101
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M7
> Environment: All platforms
>Reporter: Ashley Scopes
>Priority: Minor
> Attachments: example-reproduction.png
>
>
> If I enable phrased test naming in config, and then write a test such as the
> following:
> {code:java}
> // Note no @DisplayName("...")
> class SomeTest {
> void fooHasThreeCharacters() {
> assertThat(foo).hasSize(3)
> }
> }
> {code}
> ...then the console reports will contain a null name rather than something
> meaningful.
> I am proposing that when this phrased name is unavailable, Surefire should
> fall back to the original test name that would have been provided if phrased
> naming was disabled. The reasoning behind this is that showing an unformatted
> class name is more useful to the developer reading Maven logs than just the
> phrase {{null}}.
> !example-reproduction.png!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
[
https://issues.apache.org/jira/browse/SUREFIRE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashley Scopes updated SUREFIRE-2101:
Attachment: example-reproduction.png
> Phrased test names with missing @DisplayName result in a "null" test name
> -
>
> Key: SUREFIRE-2101
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M7
> Environment: All platforms
>Reporter: Ashley Scopes
>Priority: Minor
> Attachments: example-reproduction.png
>
>
> If I enable phrased test naming in config, and then write a test such as the
> following:
> {code:java}
> // Note no @DisplayName("...")
> class SomeTest {
> void fooHasThreeCharacters() {
> assertThat(foo).hasSize(3)
> }
> }
> {code}
> ...then the console reports will contain a null name rather than something
> meaningful.
> I am proposing that when this phrased name is unavailable, Surefire should
> fall back to the original test name that would have been provided if phrased
> naming was disabled. The reasoning behind this is that showing an unformatted
> class name is more useful to the developer reading Maven logs than just the
> phrase {{null}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
Ashley Scopes created SUREFIRE-2101:
---
Summary: Phrased test names with missing @DisplayName result in a
"null" test name
Key: SUREFIRE-2101
URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M7
Environment: All platforms
Reporter: Ashley Scopes
If I enable phrased test naming in config, and then write a test such as the
following:
{code:java}
// Note no @DisplayName("...")
class SomeTest {
void fooHasThreeCharacters() {
assertThat(foo).hasSize(3)
}
}
{code}
...then the console reports will contain a null name rather than something
meaningful.
I am proposing that when this phrased name is unavailable, Surefire should fall
back to the original test name that would have been provided if phrased naming
was disabled. The reasoning behind this is that showing an unformatted class
name is more useful to the developer reading Maven logs than just the phrase
{{null}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
