[jira] [Created] (MASSEMBLY-993) Configuration option to specify artifact classifier.
Garret Wilson created MASSEMBLY-993:
---
Summary: Configuration option to specify artifact classifier.
Key: MASSEMBLY-993
URL: https://issues.apache.org/jira/browse/MASSEMBLY-993
Project: Maven Assembly Plugin
Issue Type: Improvement
Reporter: Garret Wilson
Please add a {{classifier}} option to the Maven Assembly Plugin, similar to the
[Spring Boot Maven Plugin option of the same
name|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#goals-repackage-parameters-details-classifier],
to allow a POM to explicitly indicate what classifier to append to the end of
the artifact.
Generated Maven artifacts have an option of a "classifier" such as {{javadoc}}
or {{sources}}. This is placed on the end of a artifact base filename, such as
{{foo-1.2.3-javadoc.jar}} or {{foo-1.2.3-sources}}. See the description of
classifiers in the [Maven POM Reference|https://maven.apache.org/pom.html] for
more details.
The Spring Boot Maven Plugin has a simple [configuration to set the
classifier|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#goals-repackage-parameters-details-classifier].
Thus if I specify {{bar}} as my classifier, then Spring Boot Maven Plugin
generates {{foo-1.2.3-bar.jar}}.
The Maven Assembly Plugin's only equivalent facility is indirect and arguably
semantically incorrect. Instead of specifying a "classifier", the Assembly
Plugin has a Boolean option to [append the assembly
ID|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#appendAssemblyId].
The name of this option is a little unclear; what it's really saying is "use
the assembly ID as the artifact classifier". Using the assembly ID as the
classifier is not a bad default, but the problem is not allowing an option for
an alternate classifier.
The drawback here is that the consumer of a public, published assembly
descriptor _has no control over what the ID is defined within the descriptor_.
There needs to be a way to specify the generated artifact classifier _at the
point of plugin definition_, independent of what is defined in the descriptor.
(Of course, if MASSEMBLY-992 were implemented, this would provide one
workaround, although not solve the problem of consuming published artifact
descriptors.)
As an example see https://github.com/symphoniacloud/lambda-packaging/issues/1 .
Symphonia publishes a Maven Assembly Plugin descriptor, but the ID it uses (for
reasons I outline in that ticket) is less than ideal. If the Assembly Plugin
simply were to allow a {{classifier}} option like Spring Boot Maven Plugin
does, the POM could simply choose whatever it wants, independent of the ID in
the assembly descriptor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738286#comment-17738286
]
Garret Wilson edited comment on MASSEMBLY-992 at 6/28/23 8:21 PM:
--
That use of {{maven-dependency-plugin}} is interesting; I'll have to read more
about it. Thanks for the pointer. That technique may prove useful one day.
Nevertheless it means that in my child POM I have to declare some other plugin
with its own comprehensive configuration. I don't have to do that with the
Maven Shade Plugin. I don't have to do that with the Spring Maven Plugin. I
don't have to do that with the Versions Maven Plugin. I don't have to do that
with the Launch4J plugin. I don't have to do that with the (insert the name of
virtually any other Maven plugin).
I just want to inherit everything automatically from the POM without additional
plugins and artifacts. Thus I am filing a ticket for this improvement, so that
the Maven Plugin Assembly, like 99.9% of other Maven plugins can be 100%
configured within the POM without the need for additional artifacts or
additional plugin configurations just to get the additional artifacts included
in the project.
was (Author: garretwilson):
That use of {{maven-dependency-plugin}} is interesting; I'll have to read more
about it. Thanks for the pointer. That technique may prove useful one day.
Nevertheless it means that in my child POM I have to declare some other plugin
with its own comprehensive configuration. I don't have to do that with the
Maven Shade Plugin. I don't have to do that with the Spring Maven Plugin. I
don't have to do that with the Versions Maven Plugin. I don't have to do that
with the Launch4J plugin. I don't have to do that with the (insert the name of
virtually any other Maven plugin).
I just want to inherit everything automatically from the POM without additional
plugins and artifacts. Maybe you don't want that. But I want that. It's not
available now. So I am filing a ticket for this improvement, so that the Maven
Plugin Assembly, like 99.9% of other Maven plugins can be 100% configured
within the POM without the need for additional artifacts or additional plugin
configurations just to get the additional artifacts included in the project.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738286#comment-17738286
]
Garret Wilson edited comment on MASSEMBLY-992 at 6/28/23 8:16 PM:
--
That use of {{maven-dependency-plugin}} is interesting; I'll have to read more
about it. Thanks for the pointer. That technique may prove useful one day.
Nevertheless it means that in my child POM I have to declare some other plugin
with its own comprehensive configuration. I don't have to do that with the
Maven Shade Plugin. I don't have to do that with the Spring Maven Plugin. I
don't have to do that with the Versions Maven Plugin. I don't have to do that
with the Launch4J plugin. I don't have to do that with the (insert the name of
virtually any other Maven plugin).
I just want to inherit everything automatically from the POM without additional
plugins and artifacts. Maybe you don't want that. But I want that. It's not
available now. So I am filing a ticket for this improvement, so that the Maven
Plugin Assembly, like 99.9% of other Maven plugins can be 100% configured
within the POM without the need for additional artifacts or additional plugin
configurations just to get the additional artifacts included in the project.
was (Author: garretwilson):
That use of {{maven-dependency-plugin}} is interesting; I'll have to read more
about it. Thanks for the pointer. That technique may prove useful one day.
Nevertheless it means that in my child POM I have to declare some other plugin
with its own comprehensive configuration. I don't have to do that with the
Maven Shade Plugin. I don't have to do that with the Spring Maven Plugin. I
don't have to do that withe Versions Maven Plugin. I don't have to do that with
the Launch4J plugin. I don't have to do that with the (insert the name of
virtually any other Maven plugin).
I just want to inherit everything automatically from the POM without additional
plugins and artifacts. Maybe you don't want that. But I want that. It's not
available now. So I am filing a ticket for this improvement, so that the Maven
Plugin Assembly, like 99.9% of other Maven plugins can be 100% configured
within the POM without the need for additional artifacts or additional plugin
configurations just to get the additional artifacts included in the project.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738286#comment-17738286
]
Garret Wilson commented on MASSEMBLY-992:
-
That use of {{maven-dependency-plugin}} is interesting; I'll have to read more
about it. Thanks for the pointer. That technique may prove useful one day.
Nevertheless it means that in my child POM I have to declare some other plugin
with its own comprehensive configuration. I don't have to do that with the
Maven Shade Plugin. I don't have to do that with the Spring Maven Plugin. I
don't have to do that withe Versions Maven Plugin. I don't have to do that with
the Launch4J plugin. I don't have to do that with the (insert the name of
virtually any other Maven plugin).
I just want to inherit everything automatically from the POM without additional
plugins and artifacts. Maybe you don't want that. But I want that. It's not
available now. So I am filing a ticket for this improvement, so that the Maven
Plugin Assembly, like 99.9% of other Maven plugins can be 100% configured
within the POM without the need for additional artifacts or additional plugin
configurations just to get the additional artifacts included in the project.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737877#comment-17737877
]
Garret Wilson commented on MSHADE-451:
--
And this works fine in the [Maven Assembly
Plugin|https://maven.apache.org/plugins/maven-assembly-plugin/], which [uses
{{${project.build.finalName}}}https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#finalName]
as it should.
Looks definitely like a Maven Shade Plugin bug, unless I inadvertently put a
configuration in my POM I didn't notice.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737865#comment-17737865
]
Garret Wilson edited comment on MSHADE-451 at 6/27/23 8:27 PM:
---
I want to point out that this works fine with the [Spring Boot Maven
Plugin|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/],
too. In other words (continuing the example above), if I tell it a classifier
of {{example}}, it produces {{foo-bar-1.2.3-example.jar}} as expected, and not
{{bar-1.2.3-example.jar}} as the Maven Shade Plugin does.
was (Author: garretwilson):
I want to point out that this works fine with the [Spring Boot Maven
Plugin|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/],
too. In other words, if I tell it a classifier of {{example}}, it produces
{{foo-bar-1.2.3-example.jar}} as expected, and not {{bar-1.2.3-example.jar}} as
the Maven Shade Plugin does.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737865#comment-17737865
]
Garret Wilson commented on MSHADE-451:
--
I want to point out that this works fine with the [Spring Boot Maven
Plugin|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/],
too. In other words, if I tell it a classifier of {{example}}, it produces
{{foo-bar-1.2.3-example.jar}} as expected, and not {{bar-1.2.3-example.jar}} as
the Maven Shade Plugin does.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737849#comment-17737849
]
Garret Wilson edited comment on MASSEMBLY-992 at 6/27/23 7:59 PM:
--
After reading and re-reading your comments and GitHub project, and looking at
the [files uploaded to Maven
Central|https://repo1.maven.org/maven2/net/sf/michael-o/michael-o-parent/17/],
I think what you're really saying is that you used the Assembly Plugin to
create and upload _some other_ ZIP file to Maven Central along with your parent
POM.
OK, assuming that I modify that to include an assembly descriptor, how would I
use that assembly descriptor in a child POM?
Let's say that in my POM I use this:
{code:xml}
net.sf.michael-o
michael-o-parent
17
{code}
I see that's published on Maven Central.
Now when I issue:
{code}
mvn clean package
{code}
You're saying that Maven will then automatically go out and download some file
that was "attached" to the parent POM, with no further action on my part, and
place them somewhere so that the child POM could use it for the assembly plugin?
was (Author: garretwilson):
Pardon me, but either I'm a little slow or somehow we're talking past each
other or something else.
So let's say that in my POM I use this:
{code:xml}
net.sf.michael-o
michael-o-parent
17
{code}
I see that's published on Maven Central.
Now when I issue:
{code}
mvn clean package
{code}
You're saying that Maven will then automatically go out and download
[{{michael-o-parent-17-site-resources.zip}}|https://search.maven.org/remotecontent?filepath=net/sf/michael-o/michael-o-parent/17/michael-o-parent-17-site-resources.zip],
with no further action on my part, and place them somewhere?
What mechanism does that? I've never heard of such a mechanism.
And where would Maven place {{michael-o-parent-17-site-resources.zip}} so that
it would be available to the child POM?
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[ https://issues.apache.org/jira/browse/MASSEMBLY-992 ]
Garret Wilson deleted comment on MASSEMBLY-992:
-
was (Author: garretwilson):
{quote}You're saying that Maven will then automatically go out and download
[{{michael-o-parent-17-site-resources.zip}}|https://search.maven.org/remotecontent?filepath=net/sf/michael-o/michael-o-parent/17/michael-o-parent-17-site-resources.zip]
… {quote}
Actually it turns how that this file doesn't even include the "attached"
assembly descriptor.
[~michael-o], here are the files uploaded to Maven Central for the parent POM
you mentioned:
https://repo1.maven.org/maven2/net/sf/michael-o/michael-o-parent/17/
Which one of those files contains the assembly descriptor you "attached" to
your parent POM?
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737853#comment-17737853
]
Garret Wilson edited comment on MASSEMBLY-992 at 6/27/23 7:51 PM:
--
I'm feeling a little frustrated here. I thought the description of what I
wanted was understandable, but maybe I am not being clear. Let me try again.
# I can configure Maven Shade Plugin in My Parent POM with coordinates
{{com.example:parent}} and publish that to Maven Central.
# Then in My Child Project, a completely separate project, I need merely
indicate that the parent POM is {{com.example:parent}}.
# Finally I can issue {{mvn clean package}} in My Child Project, and it will
create a shaded JAR according to the configuration I placed in My Parent POM
_with no further action required on the part of the developer_.
It is my understanding that scenario I described cannot be done using the Maven
Assembly Plugin as currently designed.
Note that we discussed this in depth [on Stack
Overflow|https://stackoverflow.com/q/72416739] and no one else had heard of
some way to attach files to a parent POM so that they are automatically
available to the child project.
was (Author: garretwilson):
I'm feeling a little frustrated here. I thought the description of what I
wanted was understandable, but maybe I am not being clear. Let me try again.
# I can configure Maven Shade Plugin in My Parent POM with coordinates
{{com.example:parent}} and publish that to Maven Central.
# Then in My Child Project, a completely separate project, I need merely
indicate that the parent POM is {{com.example:parent}}.
# Finally I can issue {{mvn clean package}} in My Child Project, and it will
create a shaded JAR according to the configuration I placed in My Parent POM
_with no further action required on the part of the developer_.
It is my understanding that scenario I described cannot be done using the Maven
Assembly Plugin as currently designed. It is my understanding that
[~michael-o]'s "attached resources" will not work automatically as in the
scenario I described for the Maven Shade Plugin above. If I am in error in my
understanding, I will happily admit it—but please explain this in detail.
Note that we discussed this in depth [on Stack
Overflow|https://stackoverflow.com/q/72416739] and no one else had heard of
some way to attach files to a parent POM so that they are automatically
available to the child project. So if you have some magic formula,
[~michael-o], I would glad to year it, but you still haven't explained how a
ZIP file you managed to get uploaded to Maven Central helps my child project
without extra development work.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/vers
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737861#comment-17737861
]
Garret Wilson commented on MASSEMBLY-992:
-
{quote}You're saying that Maven will then automatically go out and download
[{{michael-o-parent-17-site-resources.zip}}|https://search.maven.org/remotecontent?filepath=net/sf/michael-o/michael-o-parent/17/michael-o-parent-17-site-resources.zip]
… {quote}
Actually it turns how that this file doesn't even include the "attached"
assembly descriptor.
[~michael-o], here are the files uploaded to Maven Central for the parent POM
you mentioned:
https://repo1.maven.org/maven2/net/sf/michael-o/michael-o-parent/17/
Which one of those files contains the assembly descriptor you "attached" to
your parent POM?
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737853#comment-17737853
]
Garret Wilson commented on MASSEMBLY-992:
-
I'm feeling a little frustrated here. I thought the description of what I
wanted was understandable, but maybe I am not being clear. Let me try again.
# I can configure Maven Shade Plugin in My Parent POM with coordinates
{{com.example:parent}} and publish that to Maven Central.
# Then in My Child Project, a completely separate project, I need merely
indicate that the parent POM is {{com.example:parent}}.
# Finally I can issue {{mvn clean package}} in My Child Project, and it will
create a shaded JAR according to the configuration I placed in My Parent POM
_with no further action required on the part of the developer_.
It is my understanding that scenario I described cannot be done using the Maven
Assembly Plugin as currently designed. It is my understanding that
[~michael-o]'s "attached resources" will not work automatically as in the
scenario I described for the Maven Shade Plugin above. If I am in error in my
understanding, I will happily admit it—but please explain this in detail.
Note that we discussed this in depth [on Stack
Overflow|https://stackoverflow.com/q/72416739] and no one else had heard of
some way to attach files to a parent POM so that they are automatically
available to the child project. So if you have some magic formula,
[~michael-o], I would glad to year it, but you still haven't explained how a
ZIP file you managed to get uploaded to Maven Central helps my child project
without extra development work.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737849#comment-17737849
]
Garret Wilson commented on MASSEMBLY-992:
-
Pardon me, but either I'm a little slow or somehow we're talking past each
other or something else.
So let's say that in my POM I use this:
{code:xml}
net.sf.michael-o
michael-o-parent
17
{code}
I see that's published on Maven Central.
Now when I issue:
{code}
mvn clean package
{code}
You're saying that Maven will then automatically go out and download
[{{michael-o-parent-17-site-resources.zip}}|https://search.maven.org/remotecontent?filepath=net/sf/michael-o/michael-o-parent/17/michael-o-parent-17-site-resources.zip],
with no further action on my part, and place them somewhere?
What mechanism does that? I've never heard of such a mechanism.
And where would Maven place {{michael-o-parent-17-site-resources.zip}} so that
it would be available to the child POM?
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737824#comment-17737824
]
Garret Wilson commented on MASSEMBLY-992:
-
{quote}You can attached the assembly desc to your parent POM …{quote}
Please explain how to attach an arbitrary file to a parent POM that I publish
on Maven Central. I wasn't aware Maven had that facility, but I would love to
learn.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737796#comment-17737796
]
Garret Wilson commented on MASSEMBLY-992:
-
Yes, I even linked to the "Sharing Descriptors" document in the description of
this ticket. (Thanks for fixing the typo in my other link, by the way.)
# But this technique requires me to create a separate project and publish a
separate artifact to Maven Central. I already have a parent POM that I am
configuring. I want to configure the plugin in the parent POM _without
publishing an additional artifact_.
# It's unclear to me whether the "Sharing Descriptors" technique allows
interpolation inside the {{myassembly.xml}} file itself. Maybe you can clear
that up for me. If I publish {{myassembly.xml}} as a separate artifact as
described in the "Sharing Descriptors" document, will property references
inside {{myassembly.xml}} be interpolated at build time based upon the
properties of the POM that is using the shared descriptor artifact as a
dependency? (I would guess the answer is "no", but I would be happy if you
would explain that I am mistaken.)
Lastly I understand that there are complicated workarounds. But for 99% of
plugins, I don't have to publish a separate artifact just to provide a
configuration that can be inherited by a child POM. In addition I want to use
interpolation based upon the child POM's properties. Thus I am opening this
ticket to allow definition of an assembly descriptor within the POM itself.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MASSEMBLY-992:
Description:
The Maven Assembly Plugin allows custom descriptors to be defined, but only in
an external file. Please add the capability to define the descriptor in the
body of the POM itself.
Requiring a separate descriptor file makes it almost impossible to declare an
assembly in a parent POM so that it can be inherited by child POMs. The
documentation describe a way to [share
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
but it is complex and doesn't obviously support Maven property interpolation.
Without this facility, in order to easily inherit an assembly from a parent
POM, I'm currently resorting to workaround involving AntRun to generate an
assembly descriptor on the fly. See [this
{{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
It's pretty convoluted and tedious to get right. In addition, it has to be
placed in a phase that is guaranteed to run before the execution of the Maven
Assembly Plugin itself.
{code:xml}
org.apache.maven.plugins
maven-antrun-plugin
generate-bin-assembly-descriptor
prepare-package
run
${_isSkipGenerateExe}
{code}
This was requested and finally implemented for Versions Maven Plugin; see
[#258|https://github.com/mojohaus/versions/issues/258] and
[#684|https://github.com/mojohaus/versions/issues/684], along with [_Versions
Maven Plugin rules that are inheritable_|https://stackoverflow.com/q/72416739]
on Stack Overflow.
was:
The Maven Assembly Plugin allows custom descriptors to be defined, but only in
an external file. Please add the capability to define the descriptor in the
body of the POM itself.
Requiring a separate descriptor file makes it almost impossible to declare an
assembly in a parent POM so that it can be inherited by child POMs. The
documentation describe a way to [share
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
but it is complex and doesn't obviously support Maven property interpolation.
Without this facility, in order to easily inherit an assembly from a parent
POM, I'm currently resorting to workaround involving AntRun to generate an
assembly descriptor on the fly. See [this
{{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
It's pretty convoluted and tedious to get right. In addition, it has to be
placed in a phase that is guaranteed to run before the execution of the Maven
Assembly Plugin itself.
{code:xml}
org.apache.maven.plugins
maven-antrun-plugin
generate-bin-assembly-descriptor
prepare-package
run
${_isSkipGenerateExe}
{code}
This was requested and finally implemented for Versions Maven Plugin; see
[#258|https://github.com/mojohaus/versions/issues/258] and
[#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
Maven Plugin rules that are inheritable_|https://stackoverflow.com/q/72416739]
on Stack Overflow.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaroun
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737766#comment-17737766
]
Garret Wilson commented on MASSEMBLY-992:
-
{quote}One can use remote resources for that.{quote}
And what do you mean by "remote resources"? Do you mean simply putting my
descriptor up on some HTTP server and putting its URL in the POM? But that
defeats the purpose of the the Maven build and artifact version management.
In can inherit from a parent POM a ready-made configuration for an execution of
Maven Shade Plugin (as one example out of dozens if not hundreds) without
writing an external file or hosting a "remote resource" or publishing a
separate artifact with the descriptor. I just configure the Maven Shade Plugin
in the parent POM, and it's available in the child POM. The gist of this ticket
is that I should be able to do the same thing with the Maven Assembly Plugin
without jumping through hoops and creating elaborate workarounds.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737754#comment-17737754
]
Garret Wilson commented on MASSEMBLY-992:
-
{quote}One can use remote resources for that.{quote}
Do remote resources support property interpolation in the descriptor itself
using the evaluated values in the current child POM?
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
> prepare-package
>
> run
>
>
> ${_isSkipGenerateExe}
>
> encoding="UTF-8">
>
>
>
>
>
>
>
> {code}
> This was requested and finally implemented for Versions Maven Plugin; see
> [#258|https://github.com/mojohaus/versions/issues/258] and
> [#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
> Maven Plugin rules that are
> inheritable_|https://stackoverflow.com/q/72416739] on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
[
https://issues.apache.org/jira/browse/MASSEMBLY-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MASSEMBLY-992:
Description:
The Maven Assembly Plugin allows custom descriptors to be defined, but only in
an external file. Please add the capability to define the descriptor in the
body of the POM itself.
Requiring a separate descriptor file makes it almost impossible to declare an
assembly in a parent POM so that it can be inherited by child POMs. The
documentation describe a way to [share
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
but it is complex and doesn't obviously support Maven property interpolation.
Without this facility, in order to easily inherit an assembly from a parent
POM, I'm currently resorting to workaround involving AntRun to generate an
assembly descriptor on the fly. See [this
{{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
It's pretty convoluted and tedious to get right. In addition, it has to be
placed in a phase that is guaranteed to run before the execution of the Maven
Assembly Plugin itself.
{code:xml}
org.apache.maven.plugins
maven-antrun-plugin
generate-bin-assembly-descriptor
prepare-package
run
${_isSkipGenerateExe}
{code}
This was requested and finally implemented for Versions Maven Plugin; see
[#258|https://github.com/mojohaus/versions/issues/258] and
[#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
Maven Plugin rules that are inheritable_|https://stackoverflow.com/q/72416739]
on Stack Overflow.
was:
The Maven Assembly Plugin allows custom descriptors to be defined, but only in
an external file. Please add the capability to define the descriptor in the
body of the POM itself.
Requiring a separate descriptor file makes it almost impossible to declare an
assembly in a parent POM so that it can be inherited by child POMs. The
documentation describe a way to [share
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
but it is complex and doesn't obviously support Maven property interpolation.
Without this facility, in order to easily inherit an assembly from a parent
POM, I'm currently resorting to workaround involving AntRun to generate an
assembly descriptor on the fly. See [this
{{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
It's pretty convoluted and tedious to get right:
{code:xml}
{code}
This was requested and finally implemented for Versions Maven Plugin; see
[#258|https://github.com/mojohaus/versions/issues/258] and
[#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
Maven Plugin rules that are inheritable_|https://stackoverflow.com/q/72416739]
on Stack Overflow.
> Facility to define assembly descriptor in body of POM
> -
>
> Key: MASSEMBLY-992
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Garret Wilson
>Priority: Major
>
> The Maven Assembly Plugin allows custom descriptors to be defined, but only
> in an external file. Please add the capability to define the descriptor in
> the body of the POM itself.
> Requiring a separate descriptor file makes it almost impossible to declare an
> assembly in a parent POM so that it can be inherited by child POMs. The
> documentation describe a way to [share
> descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
> but it is complex and doesn't obviously support Maven property interpolation.
> Without this facility, in order to easily inherit an assembly from a parent
> POM, I'm currently resorting to workaround involving AntRun to generate an
> assembly descriptor on the fly. See [this
> {{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
> It's pretty convoluted and tedious to get right. In addition, it has to be
> placed in a phase that is guaranteed to run before the execution of the Maven
> Assembly Plugin itself.
> {code:xml}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
>
> generate-bin-assembly-descriptor
[jira] [Created] (MASSEMBLY-992) Facility to define assembly descriptor in body of POM
Garret Wilson created MASSEMBLY-992:
---
Summary: Facility to define assembly descriptor in body of POM
Key: MASSEMBLY-992
URL: https://issues.apache.org/jira/browse/MASSEMBLY-992
Project: Maven Assembly Plugin
Issue Type: New Feature
Reporter: Garret Wilson
The Maven Assembly Plugin allows custom descriptors to be defined, but only in
an external file. Please add the capability to define the descriptor in the
body of the POM itself.
Requiring a separate descriptor file makes it almost impossible to declare an
assembly in a parent POM so that it can be inherited by child POMs. The
documentation describe a way to [share
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html],
but it is complex and doesn't obviously support Maven property interpolation.
Without this facility, in order to easily inherit an assembly from a parent
POM, I'm currently resorting to workaround involving AntRun to generate an
assembly descriptor on the fly. See [this
{{pom.xml}}|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml].
It's pretty convoluted and tedious to get right:
{code:xml}
{code}
This was requested and finally implemented for Versions Maven Plugin; see
[#258|https://github.com/mojohaus/versions/issues/258] and
[#685|https://github.com/mojohaus/versions/issues/684], along with [_Versions
Maven Plugin rules that are inheritable_|https://stackoverflow.com/q/72416739]
on Stack Overflow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson edited comment on MSHADE-451 at 6/25/23 8:24 PM:
---
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.9.1s and 3.4.1s
and I was in a rush. But I fixed it. 😉
was (Author: garretwilson):
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson edited comment on MSHADE-451 at 6/25/23 8:23 PM:
---
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
was (Author: garretwilson):
{quote}Hello human from the future: In which year will Windows 17 be
released?\{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson commented on MSHADE-451:
--
{quote}Hello human from the future: In which year will Windows 17 be
released?\{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Wind
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{${project.artifactId}-${project.version}}} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
>
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Ga
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{${project.artifactId}-${project.version}}} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
${project.artifactId}-${project.version} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Window
[jira] [Created] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
Garret Wilson created MSHADE-451:
Summary: Shade plugin not using `build.finalName` to produce
artifact with classifier.
Key: MSHADE-451
URL: https://issues.apache.org/jira/browse/MSHADE-451
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.4.1
Reporter: Garret Wilson
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
${project.artifactId}-${project.version} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7815) need for finer-grained base final name property in super POM
Garret Wilson created MNG-7815:
--
Summary: need for finer-grained base final name property in super
POM
Key: MNG-7815
URL: https://issues.apache.org/jira/browse/MNG-7815
Project: Maven
Issue Type: Improvement
Components: POM
Reporter: Garret Wilson
Maven's [super
POM|https://maven.apache.org/ref/3.9.2/maven-model-builder/super-pom.html]
defines {{build.finalName}} like this:
{code:xml}
…
${project.artifactId}-${project.version}
{code}
With no changes that produces artifacts like the following for the project
{{web-app}}:
* {{web-app-1.2.3.jar}}
* {{web-app-1.2.3-javadoc.jar}}
* {{web-app-1.2.3-sources.jar}}
Those defaults are fine used locally, or with the entire
{{com.example:web-app:1.2.3}} coordinates. But let's say that I'm going to
upload those JARs somewhere where I want them to have a unique names across
projects to be stored in the same directory. (AWS Lambda comes to mind.) I want
to produce artifacts like {{foo-bar-web-app-1.2.3.jar}}. To do that I need to
override {{build.finalName}} in my POM like this:
{code:xml}
…
foo-bar-${project.artifactId}-${project.version}
{code}
I shouldn't need to redefine the entire filename. I'm just wanting to change
the _base name_—the part that comes before the version. But it gets more
interesting because I want my Maven build to also produce a Docker image, and I
need to somehow split out the "base name" and the "version" separately. Using
{{io.fabric8:docker-maven-plugin}} I'd do something like this:
{code:xml}
foo-bar-${project.artifactId}:${project.version}
{code}
I shouldn't have to duplicate the base name.
What I _really_ need is a {{build.finalBaseName}} property. This would be
extremely simple to add to the Maven super POM in a 100% transparently
backwards compatible manner. Here is all you need in the super POM:
{code:xml}
…
${project.artifactId}
${finalBaseName}-${project.version}
{code}
With no changes, all the thousands of Maven POMs work exactly as they did
before. But if I want to change the base name from {{web-app}} to
{{foo-bar-web-app}}, I simply do this:
{code:xml}
…
foo-bar-${project.artifactId}
{code}
Even better, I don't have to duplicate the base name. Here is what I would use
to set the Docker image information:
{code:xml}
${build.finalBaseName}:${project.version}
{code}
In my own parent POM used across many projects, I'm alrady integrating this
feature myself as part of
[JAVA-308|https://globalmentor.atlassian.net/browse/JAVA-308].
{code:xml}
${project.artifactId}
…
${build.finalBaseName}-${project.version}
{code}
Still it would be very nice to have this fine-grained property available
automatically with Maven out of the box.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728873#comment-17728873
]
Garret Wilson edited comment on MNG-7802 at 6/2/23 9:58 PM:
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959] said it might have come
from some [Maven Compatibility
Layer|https://maven.apache.org/ref/3.9.2/maven-compat/]. I haven't looked into
this to find out the details, but if Maven Resolver doesn't know how to work
with data from the Maven Compatibility Layer, then … shouldn't it? My point is
that there is no "corruption" here. Everything worked as normal based upon some
set of tools, and Maven Resolver just wasn't in the loop on what to expect with
what something else wrote.
You and I as humans can look at the file above and figure out what was
intended. There is zero ambiguity in the file about what the last updated
timestamp should be. The file is 100% machine processable. Shouldn't there be
some way to improve Maven Resolver to figure that out as well?
I realize this ticket deals with complicated policy beyond this particular
issue, so I'll go back into lurk mode for this ticket and let all of you
discuss it. I just wanted to clarify that part. Have a wonderful weekend.
was (Author: garretwilson):
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojo
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728873#comment-17728873
]
Garret Wilson commented on MNG-7802:
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959] said it might have come
from some [Maven Compatibility
Layer|https://maven.apache.org/ref/3.9.2/maven-compat/]. I haven't looked into
this to find out the details, but if Maven Resolver doesn't know how to work
with data from the Maven Compatibility Layer, then … shouldn't it? My point is
that there is no "corruption" here. Everything worked as normal based upon some
set of tools, and Maven Resolver just wasn't in the loop on what to expect with
what something else wrote.
You and I as humans can look at the file above and figure out what was
intended. There is zero ambiguity in the file about what the last updated
timestamp should be. The file is 100% machine processable. Shouldn't there be
some way to improve Maven Resolver to figure that out as well?
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726696#comment-17726696 ] Garret Wilson commented on MRESOLVER-363: - Természetesen! Egy sört kérek. 😂 (I sent you an email.) I'm heading to the gym before you convince me to have a beer already. Enjoy yours. > Maven metadata is not updated in some cases > --- > > Key: MRESOLVER-363 > URL: https://issues.apache.org/jira/browse/MRESOLVER-363 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > Seems when update check for metadata happens, and: > * maven-metadata XML is present, but > * resolver-status.properties is not, OR was created by maven-compat, that > uses different key for lastUpdated. Effectively the value of lastUpdated is > not present. > The update check falsely DO NOT check for update, as it will end up with > update policy "never" in update policy analyzer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726690#comment-17726690
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}If present, it means we have it (and checksums are hopefully according
to checksum policy validated), so we can continue the work.{quote}
… unless we are keeping some separate "last-updated" flag, and something about
the "last-updated" flag is fishy (or missing), which says, "uh, oh, we better
check on this"!
{quote}IF you are present, i will ask my wife "Did Garret got his drink in last
30 minutes?"{quote}
I think this is a good analogy, actually.
*If your wife doesn't know if Garret has had a drink in the last 30 minutes*,
do you assume that I've had my drink in the last 30 minutes (and you assume
that for the rest of the party, even if the party goes on all night), or do you
think "it's probably better to assume that Garret has not had a drink in the
last 30 minutes, and ask your wife to keep an eye out in the future"? I would
argue the latter is a better approach, and that was core of my question.
Anyway, I've just had breakfast, but that drink you mentioned is already
starting to sound good. 😅 haha I'll drop you a separate email about that. Have
a good weekend!
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:06 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:07 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was first released, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
carving out certain valid values and giving them special semantics for return
codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "**two
milliseconds past** January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726687#comment-17726687
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 5:05 PM:
--
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "*two
milliseconds past* January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
was (Author: garretwilson):
{quote}Well, TS_NEVER is January 1, 1970 and TS_UNKNOWN is January 1, 1970 + 1
millisecond (0 and 1 long values respectively){quote}
(sigh) That missed the point of my question (and illustrates the peril of
making carving out certain valid values and given them special semantics
"values with special meaning" for return codes).
Pretend my question said I'm asking what bad would happen if you return "**two
milliseconds past** January 1, 1970" instead of {{TS_UNKNOWN}}, or the date
Maven was created, or any other arbitrary date in the past.
But never mind. I know we both have other work to do. I'll look for the
Versions Maven Plugin update.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726684#comment-17726684
]
Garret Wilson commented on MRESOLVER-363:
-
Look maybe I'm still not explaining my question well. I don't want to keep
insisting and make people irritated. I'll just live with {{-U}} for the moment,
and then you say that Versions Maven Plugin will have some changes that will
make {{-U}} not necessary. Great. Thanks for working on this.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:55 PM:
--
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)
{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide
{quote}
I am asking you very specifically: *What harm would come if we change it to the
following?*
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN
{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{{}TS_UNKNOWN{}}}.
I'm asking what bad would happen if you return "January 1, 1970" instead of
{{{}TS_UNKNOWN{}}}?
was (Author: garretwilson):
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide){quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:55 PM:
--
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide){quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
was (Author: garretwilson):
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)\{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726683#comment-17726683
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}2. that's exactly what happens (with a twist: file is not present -> go
grab it; file is present but no lastUpdated -> let policy decide)\{quote}
But you didn't answer my question. That's _not_ what happens today, because it
has the "twist" you mentioned.
You say you have this:
{quote}file is present but no lastUpdated -> let policy decide{quote}
I am asking you very specifically: **What harm would come if we change it to
the following?**
_file is present but no lastUpdated -> default to a lastUpdated of January 1,
1970_
{quote}Also observe this UT, that would fail if in case TS_NEVER would be
returned instead of TS_UNKNOWN{quote}
But I'm not proposing you return {{TS_NEVER}} instead of {{TS_UNKNOWN}}. I'm
asking what bad would happen if you return "January 1, 1970" instead of
{{TS_UNKNOWN}}?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:31 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "update policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:29 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:29 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated value in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider a
"last-updated" timestamp value in {{{}resolver-status.properties{}}}? (I'm not
asking you what that situation is, because it gets into a long discussion about
things that I'm still not understanding.) I'm trying to simplify this: {*}is
there ever a situation, yes or no{*}, in which it is valid for Maven to look
for and use a "last-updated" value in {{{}resolver-status.properties{}}}? (I
added bold only to be clear about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" value in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:22 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1970? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson edited comment on MRESOLVER-363 at 5/26/23 4:18 PM:
--
I understood and agree with most everything you said in the previous comment,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon {_}current Maven functionality{_}:
1. Is there ever a situation in which it is valid for Maven to consider
{{{}resolver-status.properties{}}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: {*}is there ever a situation, yes
or no{*}, in which it is valid for Maven to look for and use a "last-updated"
flag in {{{}resolver-status.properties{}}}? (I added bold only to be clear
about what question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{{}resolver-status.properties{}}}",
my second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{{}resolver-status.properties{}}}, to default to some "last-updated" date in
the past such as January 1, 1900? *What harm would come from this?*
was (Author: garretwilson):
I understood and agree with most everything you said in the previous question,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon _current Maven functionality_:
1. Is there ever a situation in which it is valid for Maven to consider
{{resolver-status.properties}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: *is there ever a situation, yes or
no*, in which it is valid for Maven to look for and use a "last-updated" flag
in {{resolver-status.properties}}? (I added bold only to be clear about what
question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{resolver-status.properties}}", my
second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{resolver-status.properties}}, to default to some "last-updated" date in the
past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726674#comment-17726674
]
Garret Wilson commented on MRESOLVER-363:
-
I understood and agree with most everything you said in the previous question,
but I'm still not understanding how it is relevant. Perhaps my trying to
understand Maven's concept of "change policy" without researching into the code
may be futile, and may even be beside the point.
So let me sidestep all the philosophy and break it down to two simple
questions, based upon _current Maven functionality_:
1. Is there ever a situation in which it is valid for Maven to consider
{{resolver-status.properties}}? (I'm not asking you what that situation is,
because it gets into a long discussion about things that I'm still not
understanding.) I'm trying to simplify this: *is there ever a situation, yes or
no*, in which it is valid for Maven to look for and use a "last-updated" flag
in {{resolver-status.properties}}? (I added bold only to be clear about what
question I am asking.)
2. _If_ the answer to #1 is "yes, in some circumstances it would be valid for
Maven to consider a last-updated flag in {{resolver-status.properties}}", my
second question is: what would be the downside if, in those circumstances
(whatever they are), if Maven cannot find a "last-updated" flag in
{{resolver-status.properties}}, to default to some "last-updated" date in the
past such as January 1, 1900? *What harm would come from this?*
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726665#comment-17726665
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}How is this difficult to resolve? If we update Maven's behavior so that
if resolver-status.properties is missing (or does not have the correct
"last-updated" flag), then instead of doing nothing, Maven proceeds as if the
"last-updated" value is January 1, 1970. Everything works as before if
"last-updated" is present. If not, then the Versions Maven Plugin related bug
is fixed and going forward there will be a "last-updated" flag. It's probably a
single line of code (not counting brackets). What is the downside?{quote}
In fact, if you agree to at least _consider_ this approach, assign it to me and
I'll be happy to look into it and file a pull request if it works out. Checking
for files and defaulting values and such is something I do day-in and day-out,
so it's right up my alley. I can't imagine this could be too difficult. Just
find out where it's looking for the {{resolver-status.properties}} file, and
add an {{else}} to the "property not found" part. But only if you would
consider it; I don't want to do it if it's out of the question to be accepted.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726664#comment-17726664
]
Garret Wilson commented on MRESOLVER-363:
-
{quote}Maven - out of the box (when user does not customize anything), the
default update policy for **RELEASE** repositories is **never**. It is exactly
due immutability (of releases), nothing is updated unless you say so.{quote}
This still doesn't make sense to me. Indicating that something that is a
"release" repository means _the artifacts within it will never change_, i.e.
they will all be non-SNAPSHOT versions. To me it does not mean that _the
repository itself will never change_. And it definitely doesn't mean _no one
will ever add things to the repository_. In fact the idea of a "repository that
can never be updated" makes no sense to me; the whole point of a repository is
that you add more versions to it as more versions are available. I can see that
in e.g. a security context you might want to make a repository as read-only,
but _you might want to do that with a non-release, snapshot repository as
well_. So it seems to me they are orthogonal concepts.
And even if I accept the idea that a "release" repository means it is
immutable, are we designating the machine's local repository in
{{~/.m2/repository}} as a "release", immutable repository? But doesn't Maven
keep {{-SNAPSHOT}} artifacts in it as well? So we are using a "release"
repository to store snapshots? None of this make sense to me.
{quote}maven never "sync to server", Maven does what you tell it to do via POM
(you enlist all the versions).{quote}
So why does Maven even have a {{resolver-status.properties}} if it never "syncs
to the server"? Why would a "last-updated" matter?
{quote}You are mixing in things with one specific plugin and it's goal: the
versions plugin.{quote}
But Versions Maven Plugin is working now if {{resolver-status.properties}} has
its "last updated" flag correctly! It only fails if this is missing. (And I've
explained above why this approach guarantees incorrect behavior.)
How is this difficult to resolve? If we update Maven's behavior so that if
{{resolver-status.properties}} is missing (or does not have the correct
"last-updated" flag), then instead of doing nothing, Maven proceeds as if the
"last-updated" value is January 1, 1970. Everything works as before if
"last-updated" is present. If not, then the Versions Maven Plugin related bug
is fixed and going forward there will be a "last-updated" flag. It's probably a
single line of code (not counting brackets). What is the downside?
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726644#comment-17726644
]
Garret Wilson commented on MRESOLVER-363:
-
Good morning. There are two big things I don't understand about this behavior:
1.
Modern build systems has the beautiful concept of an immutable, repeatable
build. If an artifact is versioned, then once you have an artifact with a
version, you know that it's the latest, so there is no point in ever updating
it. In fact you _shouldn't_ (unless there was some error in the process, in
which case you can override it to fix the error). Everything I'm saying here
you already know and could recite in your sleep I'm sure.
But {{maven-metadata-central.xml}} is not a versioned artifact. It has no
version. We _know_ that we may update this artifact–in fact no only that we
"may" update the artifact, we know that _we probably will_ update this
artifact. The whole purpose of this artifact is to _track the changing state of
the server_. It is like {{HEAD}} in get. {{HEAD}} is not immutable. It simply
tells us whether we're in sync with the server or not. It is very closely
analogous to a {{-SNAPSHOT}} version. In fact it is a "shapshot" of the server.
_It is not a versioned artifact._
So why on earth would {{maven-metadata-central.xml}} have a policy of "never
update"? How could that ever be even close to correct? It's not versioned. It's
purpose is not to track some finalized state; it's purpose is rather to track
the synchronization state of _things that are always changing_. Could you
imagine putting a "never update" policy on Git {{HEAD}}? I'm not understanding
the reasoning here.
2.
Orthogonally, the current behavior is _not_ to update the metadata if
{{resolver-status.properties}} is missing (or does not have the expected "last
updated" information). This also doesn't make sense to me. When I am writing
software that synchronizes with a server, if the "last-updated" flag is
missing, the reasonable action to me is to synchronize (because we don't know
when it was last updated) and then update the "last-updated" flag so we'll know
in the future. I don't see any benefits to the approach of, "if we don't know
when we last updated, assume that we last updated recently".
In fact this approach is demonstrably incorrect, because if you wait long
enough, the behavior is guaranteed to be wrong. Assume that we only need to
update once every 1 year. If the "last-updated" flag is missing, the current
approach assumes that it has been updated less a year ago. And for a while that
will be correct. But eventually that will be wrong; eventually more than one
year will have past, so the assumption will be wrong. The point is that this
approach guarantees that _eventually the behavior will always be incorrect_.
Even if you only want to refresh after 100 years. Even if you put 1000 years.
If the software assumes that everything is up-to-date when the "last-updated"
flag is missing, then that approach _guarantees_ incorrect behavior eventually.
A better approach is to update the file and set the "last-updated" flag if the
"last-updated" flag is missing. This may at most result in a single "extra"
update, but that is benign, and going forward it will function correctly.
Taking the other approach _guarantees_ incorrect behavior forever, for hundreds
and thousands of years.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-363) Maven metadata is not updated in some cases
[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726402#comment-17726402
]
Garret Wilson commented on MRESOLVER-363:
-
The description indicates that {{resolver-status.properties}} is not present. I
understand that this is part of the scenario used initially to reproduce this
problem in [Versions Maven Plugin Issue
#959|https://github.com/mojohaus/versions/issues/959], but I just wanted to
mention that for the original case {{resolver-status.properties}} was in fact
present and this problem still presented itself.
> Maven metadata is not updated in some cases
> ---
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Tamas Cservenak
>Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649055#comment-17649055
]
Garret Wilson commented on MNG-7559:
{quote}
indeed not a bug, but the spec could be improved to take more milestones
qualifiers like the PREVIEW qualifiers used on jdbc drivers
{quote}
With the decision to add even more "magic strings", is it any surprise this is
turning into a "mess", as [~michael-o] called it?
Perhaps the time has come for Maven to simply follow Semantic Versioning, as
everyone expects anyway?
As I
[commented|https://github.com/mojohaus/versions/issues/744#issuecomment-1272343117]
on the [original bug I filed|https://github.com/mojohaus/versions/issues/744]:
{quote}It's not surprising that at one time Maven created some reasonable,
internally consistent versioning schema, and it is notable and commendable that
Maven actually created a specification for this at a time when so many projects
were making versioning format decisions based upon arbitrary whims of the
current developer. I would guess that Maven probably even had some influence on
the codification of the Semantic Versioning specification.
But it is unquestionable that the software industry is now converging around
Semantic Version, and the last thing that we need is a central component of the
build pipeline to be marching to some other tune. Just because something was
specified at one time doesn't mean it can't be improved in a later version.
HTML 4 wasn't bad. We should not be using HTML 4 in 2022—we should be using
HTML 5, because that good specification has been improved.
It is certainly illustrative that after I filed this bug, initially everyone
_expected_ it to be a bug until we found some little-known Maven versioning
specification. This expectation illustrates that in 2022 developers _expect_ to
be using Semantic Versioning. Developer *do _not_ expect that certain suffixes
are special-cased and treated differently based upon whether they are "well
known" or not.* Marking certain limited set of identifiers as "well-known"
leads exactly to [the never-ending dilemma of which special strings to support
and how to deal with them]. It is better to treat them all the same.
The difference in version number interpretation between Maven versions and
Semantic Versions is small. It is time for Maven to be using Semantic
Versioning, in the least regarding the comparison of pre-release version
suffixes.
{quote}
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPH-193) Document charset for evaluate goal file output.
[
https://issues.apache.org/jira/browse/MPH-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MPH-193:
--
Description:
I'm using Java 17 on Windows with
`org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
[{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
option allows the evaluated information to be sent to a file. But the
documentation does not say which charset will be used!
I was afraid that you might be using the system default charset (which would be
very bad). But I did a test:
{code:xml}
…
org.apache.maven.plugins
maven-help-plugin
foobar
generate-resources
evaluate
foo
${project.build.directory}/foo.xml
{code}
It was a huge relief to find that the output file {{foo.xml}} contained the
word "touché" followed by a smiley face emoticon, encoded in UTF-8!
It is a very good thing that you are encoding the file output in UTF-8 and not
some arbitrary, per-system encoding. But this needs to be documented so we'll
know that we can depend on that. Thank you.
was:
I'm using Java 17 on Windows with
`org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
[{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
option allows the evaluated information to be sent to a file. But the
documentation does not say which charset will be used!
I was afraid that you might be using the system default charset (which would be
very bad). But I did a test:
{code:xml}
…
org.apache.maven.plugins
maven-help-plugin
foobar
generate-resources
evaluate
foo
${project.build.directory}/foo.xml
{code}
It was a huge relief to find that the output file {{foo.xml}} contained the
word "touché" followed by a smiley face emoticon, encoded in UTF-8! This is
good!
It is a huge relief to see that you're encoding the output in UTF-8 and not
some arbitrary, per-system encoding. But this needs to be documented so we'll
know that we can depend on that. Thank you.
> Document charset for evaluate goal file output.
> ---
>
> Key: MPH-193
> URL: https://issues.apache.org/jira/browse/MPH-193
> Project: Maven Help Plugin
> Issue Type: Improvement
> Components: evaluate
>Affects Versions: 3.3.0
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Java 17 on Windows with
> `org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
> [{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
> option allows the evaluated information to be sent to a file. But the
> documentation does not say which charset will be used!
> I was afraid that you might be using the system default charset (which would
> be very bad). But I did a test:
> {code:xml}
>
>
>
> …
>
> org.apache.maven.plugins
> maven-help-plugin
>
>
> foobar
> generate-resources
>
> evaluate
>
>
> foo
> ${project.build.directory}/foo.xml
>
>
>
>
> {code}
> It was a huge relief to find that the output file {{foo.xml}} contained the
> word "touché" followed by a smiley face emoticon, encoded in UTF-8!
> It is a very good thing that you are encoding the file output in UTF-8 and
> not some arbitrary, per-system encoding. But this needs to be documented so
> we'll know that we can depend on that. Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPH-193) Document charset for evaluate goal file output.
Garret Wilson created MPH-193:
-
Summary: Document charset for evaluate goal file output.
Key: MPH-193
URL: https://issues.apache.org/jira/browse/MPH-193
Project: Maven Help Plugin
Issue Type: Improvement
Components: evaluate
Affects Versions: 3.3.0
Reporter: Garret Wilson
I'm using Java 17 on Windows with
`org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
[{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
option allows the evaluated information to be sent to a file. But the
documentation does not say which charset will be used!
I was afraid that you might be using the system default charset (which would be
very bad). But I did a test:
{code:xml}
…
org.apache.maven.plugins
maven-help-plugin
foobar
generate-resources
evaluate
foo
${project.build.directory}/foo.xml
{xml}
It was a huge relief to find that the output file {{foo.xml}} contained the
word "touché" followed by a smiley face emoticon, encoded in UTF-8! This is
good!
It is a huge relief to see that you're encoding the output in UTF-8 and not
some arbitrary, per-system encoding. But this needs to be documented so we'll
know that we can depend on that. Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPH-193) Document charset for evaluate goal file output.
[
https://issues.apache.org/jira/browse/MPH-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MPH-193:
--
Description:
I'm using Java 17 on Windows with
`org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
[{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
option allows the evaluated information to be sent to a file. But the
documentation does not say which charset will be used!
I was afraid that you might be using the system default charset (which would be
very bad). But I did a test:
{code:xml}
…
org.apache.maven.plugins
maven-help-plugin
foobar
generate-resources
evaluate
foo
${project.build.directory}/foo.xml
{code}
It was a huge relief to find that the output file {{foo.xml}} contained the
word "touché" followed by a smiley face emoticon, encoded in UTF-8! This is
good!
It is a huge relief to see that you're encoding the output in UTF-8 and not
some arbitrary, per-system encoding. But this needs to be documented so we'll
know that we can depend on that. Thank you.
was:
I'm using Java 17 on Windows with
`org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
[{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
option allows the evaluated information to be sent to a file. But the
documentation does not say which charset will be used!
I was afraid that you might be using the system default charset (which would be
very bad). But I did a test:
{code:xml}
…
org.apache.maven.plugins
maven-help-plugin
foobar
generate-resources
evaluate
foo
${project.build.directory}/foo.xml
{xml}
It was a huge relief to find that the output file {{foo.xml}} contained the
word "touché" followed by a smiley face emoticon, encoded in UTF-8! This is
good!
It is a huge relief to see that you're encoding the output in UTF-8 and not
some arbitrary, per-system encoding. But this needs to be documented so we'll
know that we can depend on that. Thank you.
> Document charset for evaluate goal file output.
> ---
>
> Key: MPH-193
> URL: https://issues.apache.org/jira/browse/MPH-193
> Project: Maven Help Plugin
> Issue Type: Improvement
> Components: evaluate
>Affects Versions: 3.3.0
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Java 17 on Windows with
> `org.apache.maven.plugins:maven-help-plugin:3.3.0`. The
> [{{}}|https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html#output]
> option allows the evaluated information to be sent to a file. But the
> documentation does not say which charset will be used!
> I was afraid that you might be using the system default charset (which would
> be very bad). But I did a test:
> {code:xml}
>
>
>
> …
>
> org.apache.maven.plugins
> maven-help-plugin
>
>
> foobar
> generate-resources
>
> evaluate
>
>
> foo
> ${project.build.directory}/foo.xml
>
>
>
>
> {code}
> It was a huge relief to find that the output file {{foo.xml}} contained the
> word "touché" followed by a smiley face emoticon, encoded in UTF-8! This is
> good!
> It is a huge relief to see that you're encoding the output in UTF-8 and not
> some arbitrary, per-system encoding. But this needs to be documented so we'll
> know that we can depend on that. Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPH-192) need option for evaluate goal
Garret Wilson created MPH-192:
-
Summary: need option for evaluate goal
Key: MPH-192
URL: https://issues.apache.org/jira/browse/MPH-192
Project: Maven Help Plugin
Issue Type: New Feature
Components: evaluate
Affects Versions: 3.3.0
Reporter: Garret Wilson
It is typical and even expected for Maven plugins to have a {{}} option,
so that we can provide (via properties, profiles, etc.) a way to skip the
plugin execution. See for example the [Antrun Plugin {{}}
option|https://maven.apache.org/plugins/maven-antrun-plugin/run-mojo.html#skip]
and the [Maven Assembly Plugin {{}}
option|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#skipAssembly].
(I could provide a long list of similar plugins.)
Please provide a Maven configuration option to skip execution for the
{{evaluate}} goal.
This is particularly important because the Maven Help Plugin provides the only
means to generate output to a file which is recognized across many development
environments. (For example, Antrun {{}} can generate a file, but it is
not supported by Eclipse.)
It is important to be able to able to configure in the POM to evaluate an
expression and output to a file _only_ under certain conditions. Currently the
lack of this functionality is blocking my use of the Maven Help Plugin
{{evaluate}} goal and I am forced to look for other options, or limp along with
Antrun not working in Eclipse.
Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-4975) [regression] plugin executions injected from profile run before instead of after existing executions in the POM
[
https://issues.apache.org/jira/browse/MNG-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623431#comment-17623431
]
Garret Wilson commented on MNG-4975:
I'm reading through all the past bugs, and I'm a little confused.
1. So is it guaranteed that the plugins of a _profile_ at a certain level will
always be executed _after_ the same plugins (but different execution IDs) in
the main build at the same level? Is this documented somewhere?
2.
{quote}Note that in an inheritance chain child executions are always done after
parent executions{quote}
But a comment in MNG-5799 seems to say exactly the opposite:
{quote}Seems Parent POM bindings execute AFTER child bindings. I would think it
would be the other way around. I am working around this by binding to the NEXT
phase in the child, but I would like clarity on this. Should the child binding
execute after the parent binding?{quote}
What is the correct answer for #2, and is that documented somewhere, too?
(I realize there is a ticket MNG-5987 for documenting this, but that's not
going anywhere after six years or so.)
> [regression] plugin executions injected from profile run before instead of
> after existing executions in the POM
> ---
>
> Key: MNG-4975
> URL: https://issues.apache.org/jira/browse/MNG-4975
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0, 3.0.1, 3.0.2
> Environment: I reproduced the problem with maven 3.0, 3.0.1 and
> 3.0.2. It doesn't exist in 2.2.1
> MacOS 1.6 JVM
>Reporter: Arnaud Heritier
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0.3
>
> Attachments: pom.xml
>
>
> Let's imagine we have a lifecycle phase where we want to bind several mojos.
> We want to force the order of execution of our mojos in this phase thus we
> use ordered execution IDs (00exec, 01exec, ...).
> In project's build part we define 00exec, 01exec, 02exec
> In a profile #1 we define 03exec,04exec
> In a profile #2 we define 05exec,06exec
> If I execute my build without profiles I want to see the execution of
> 00->01->02
> If I activate profile #1 I want to see the execution of 00->01->02->03->04
> If I activate profile #2 I want to see the execution of
> 00->01->02->03->04->05->06
> This the behavior we have in Maven 2.X. Any combinaison of profiles will
> ensure executions are ordered following IDs order
> In Maven 3.x it is no more the case.
> Without profile we have 00->01->02 (GREAT)
> With Profile 1 activate we have : 03->04->00->01->02 ( :( )
> With Profile 1 & 2 activate we have : 05->06->03->04->00->01->02 ( :( )
> I attach a simple testcase with an antrun to show the problem.
> Just play with {{mvn package}} and profiles {{profile1}} & {{profile2}}
> Note that the order depends also of the order of profiles declaration in the
> POM in M3
> If profile1 is defined before profile 2 I have 05->06->03->04->00->01->02
> If profile2 is defined before profile 1 I have 03->04->05->06->00->01->02
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7577) Ability to activate profile based on multiple property values
[
https://issues.apache.org/jira/browse/MNG-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622691#comment-17622691
]
Garret Wilson edited comment on MNG-7577 at 10/22/22 8:56 PM:
--
Oops, looks like this is a duplicate (MNG-3328) … from almost _five_ years ago.
😢
was (Author: garretwilson):
Oops, looks like this is a duplicate (MNG-3328) … from _four_ years ago. 😢
> Ability to activate profile based on multiple property values
> -
>
> Key: MNG-7577
> URL: https://issues.apache.org/jira/browse/MNG-7577
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There is no way I can see to activate a profile based on multiple properties.
> (This could almost be considered a bug.) For example:
> {code:xml}
>
>
> foo
>
>
> bar
>
>
> {code}
> This was mentioned two years ago [in a
> comment|https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=17100501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17100501]
> when MNG-4565 was addressed; the following is not possible:
> {code:xml}
>
>
> !skipTests
>
>
> !skipITs
>
>
> {code}
> This is similar to MNG-5909.
> It's of limited use to have logical AND working (MNG-4565) if we can't have
> multiple things of the same type to have an AND condition on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7577) Ability to activate profile based on multiple property values
[
https://issues.apache.org/jira/browse/MNG-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622691#comment-17622691
]
Garret Wilson commented on MNG-7577:
Oops, looks like this is a duplicate (MNG-3328) … from _four_ years ago. 😢
> Ability to activate profile based on multiple property values
> -
>
> Key: MNG-7577
> URL: https://issues.apache.org/jira/browse/MNG-7577
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There is no way I can see to activate a profile based on multiple properties.
> (This could almost be considered a bug.) For example:
> {code:xml}
>
>
> foo
>
>
> bar
>
>
> {code}
> This was mentioned two years ago [in a
> comment|https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=17100501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17100501]
> when MNG-4565 was addressed; the following is not possible:
> {code:xml}
>
>
> !skipTests
>
>
> !skipITs
>
>
> {code}
> This is similar to MNG-5909.
> It's of limited use to have logical AND working (MNG-4565) if we can't have
> multiple things of the same type to have an AND condition on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7577) Ability to activate profile based on multiple property values
Garret Wilson created MNG-7577:
--
Summary: Ability to activate profile based on multiple property
values
Key: MNG-7577
URL: https://issues.apache.org/jira/browse/MNG-7577
Project: Maven
Issue Type: Improvement
Components: Core
Affects Versions: 3.8.6
Reporter: Garret Wilson
There is no way I can see to activate a profile based on multiple properties.
(This could almost be considered a bug.) For example:
{code:xml}
foo
bar
{code}
This was mentioned two years ago [in a
comment|https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=17100501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17100501]
when MNG-4565 was addressed; the following is not possible:
{code:xml}
!skipTests
!skipITs
{code}
This is similar to MNG-5909.
It's of limited use to have logical AND working (MNG-4565) if we can't have
multiple things of the same type to have an AND condition on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7562) Mechanism for preventing inheritance of sections such as .
[
https://issues.apache.org/jira/browse/MNG-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MNG-7562:
---
Description:
There needs to a way in the Maven POM to prevent an element from being
inherited altogether in child POMs.
We are currently publishing a Maven POM that is useful to serve as the parent
POM for various projects. Some of the projects that use the POM will be open
source, but some will not be. To designate our parent POM as open source, we
include this:
{code:xml}
Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0
repo
{code}
This essentially says, "this project is open source".
Unfortunately because of [POM
inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
uses this parent POM will also effectively be saying "this project is also open
source", because the effective POM of all descendant projects will also include
this same license section.
Developers could try to remember to include some {{}} section to
override this license, but the whole point of the parent POM is that it should
given developers less to do, not more. Besides, some private projects (even
ours) might not wish to indicate a license at all!
There needs to be a way for our public parent POM to indicate that it is open
source without effectively making all child projects open source as well
through POM inheritance. Preventing the {{}} section from being
inherited is one example of a more general mechanism needed to say, "Do not
inherit this element at all in child POMs".
was:
There needs to a way in the Maven POM to prevent an element from being
inherited altogether in child POMs.
We are currently publishing a Maven POM that is useful to serve as the parent
POM for various projects. Some of the projects that use the POM will be open
source, but some will not be. To designate our parent POM as open source, we
include this:
{code:xml}
Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0
repo
{code}
This essentially says, "this project is open source".
Unfortunately because of [POM
inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
uses this parent POM will also effectively be saying "this project is also open
source", because the effective POM of all descendant projects will also include
this same license section.
Developers could try to remember to include some {{}} section to
override this license, but the whole point of the parent POM is that it should
given developers less to do, not more. Besides, some private projects (even
ours) might not wish to indicate a license at all!
There needs to be a way for our public parent POM to indicate that it is open
source without effectively making all child projects open source as well
through POM inheritance. Preventing the {{}} section from being
inherited is one example.
> Mechanism for preventing inheritance of sections such as .
> ---
>
> Key: MNG-7562
> URL: https://issues.apache.org/jira/browse/MNG-7562
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There needs to a way in the Maven POM to prevent an element from being
> inherited altogether in child POMs.
> We are currently publishing a Maven POM that is useful to serve as the parent
> POM for various projects. Some of the projects that use the POM will be open
> source, but some will not be. To designate our parent POM as open source, we
> include this:
> {code:xml}
>
>
> Apache-2.0
> https://www.apache.org/licenses/LICENSE-2.0
> repo
>
>
> {code}
> This essentially says, "this project is open source".
> Unfortunately because of [POM
> inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
> uses this parent POM will also effectively be saying "this project is also
> open source", because the effective POM of all descendant projects will also
> include this same license section.
> Developers could try to remember to include some {{}} section to
> override this license, but the whole point of the parent POM is that it
> should given developers less to do, not more. Besides, some private projects
> (even ours) might not wish to indicate a license at all!
> There needs to be a way for our public parent POM to indicate that it is open
> source without effectively making all child projects open source as well
> through POM inheritance. Preventing the {{}} section from being
> inherited is one example of a more general mechanism needed to say, "Do not
> inherit this element at all in child POMs".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7562) Mechanism for preventing inheritance of sections such as .
[
https://issues.apache.org/jira/browse/MNG-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616434#comment-17616434
]
Garret Wilson edited comment on MNG-7562 at 10/12/22 1:50 PM:
--
I [asked about this on Stack Overflow|https://stackoverflow.com/q/73239332],
and someone [suggested|https://stackoverflow.com/a/73983784]
{{child.licences.append.path="false"}}, which is apparently a mechanism
introduced in MNG-6059 (building on MNG-5951) and documented briefly in [Maven
Model Builder|https://maven.apache.org/ref/3.8.6/maven-model-builder/]. But
this mechanism doesn't seem to prevent inheritance—it only seems to prevent
appending a path to the inherited value, unless I'm reading it incorrectly.
was (Author: garretwilson):
I [asked about this on Stack Overflow|https://stackoverflow.com/q/73239332],
and someone [suggested|https://stackoverflow.com/a/73983784]
{{child.licences.append.path=false}}, which is apparently a mechanism
introduced in MNG-6059 (building on MNG-5951) and documented briefly in [Maven
Model Builder|https://maven.apache.org/ref/3.8.6/maven-model-builder/]. But
this mechanism doesn't seem to prevent inheritance—it only seems to prevent
appending a path to the inherited value, unless I'm reading it incorrectly.
> Mechanism for preventing inheritance of sections such as .
> ---
>
> Key: MNG-7562
> URL: https://issues.apache.org/jira/browse/MNG-7562
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There needs to a way in the Maven POM to prevent an element from being
> inherited altogether in child POMs.
> We are currently publishing a Maven POM that is useful to serve as the parent
> POM for various projects. Some of the projects that use the POM will be open
> source, but some will not be. To designate our parent POM as open source, we
> include this:
> {code:xml}
>
>
> Apache-2.0
> https://www.apache.org/licenses/LICENSE-2.0
> repo
>
>
> {code}
> This essentially says, "this project is open source".
> Unfortunately because of [POM
> inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
> uses this parent POM will also effectively be saying "this project is also
> open source", because the effective POM of all descendant projects will also
> include this same license section.
> Developers could try to remember to include some {{}} section to
> override this license, but the whole point of the parent POM is that it
> should given developers less to do, not more. Besides, some private projects
> (even ours) might not wish to indicate a license at all!
> There needs to be a way for our public parent POM to indicate that it is open
> source without effectively making all child projects open source as well
> through POM inheritance. Preventing the {{}} section from being
> inherited is one example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7562) Mechanism for preventing inheritance of sections such as .
[
https://issues.apache.org/jira/browse/MNG-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616434#comment-17616434
]
Garret Wilson commented on MNG-7562:
I [asked about this on Stack Overflow|https://stackoverflow.com/q/73239332],
and someone [suggested|https://stackoverflow.com/a/73983784]
{{child.licences.append.path=false}}, which is apparently a mechanism
introduced in MNG-6059 (building on MNG-5951) and documented briefly in [Maven
Model Builder|https://maven.apache.org/ref/3.8.6/maven-model-builder/]. But
this mechanism doesn't seem to prevent inheritance—it only seems to prevent
appending a path to the inherited value, unless I'm reading it incorrectly.
> Mechanism for preventing inheritance of sections such as .
> ---
>
> Key: MNG-7562
> URL: https://issues.apache.org/jira/browse/MNG-7562
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There needs to a way in the Maven POM to prevent an element from being
> inherited altogether in child POMs.
> We are currently publishing a Maven POM that is useful to serve as the parent
> POM for various projects. Some of the projects that use the POM will be open
> source, but some will not be. To designate our parent POM as open source, we
> include this:
> {code:xml}
>
>
> Apache-2.0
> https://www.apache.org/licenses/LICENSE-2.0
> repo
>
>
> {code}
> This essentially says, "this project is open source".
> Unfortunately because of [POM
> inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
> uses this parent POM will also effectively be saying "this project is also
> open source", because the effective POM of all descendant projects will also
> include this same license section.
> Developers could try to remember to include some {{}} section to
> override this license, but the whole point of the parent POM is that it
> should given developers less to do, not more. Besides, some private projects
> (even ours) might not wish to indicate a license at all!
> There needs to be a way for our public parent POM to indicate that it is open
> source without effectively making all child projects open source as well
> through POM inheritance. Preventing the {{}} section from being
> inherited is one example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7562) Mechanism for preventing inheritance of sections such as .
[
https://issues.apache.org/jira/browse/MNG-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MNG-7562:
---
Description:
There needs to a way in the Maven POM to prevent an element from being
inherited altogether in child POMs.
We are currently publishing a Maven POM that is useful to serve as the parent
POM for various projects. Some of the projects that use the POM will be open
source, but some will not be. To designate our parent POM as open source, we
include this:
{code:xml}
Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0
repo
{code}
This essentially says, "this project is open source".
Unfortunately because of [POM
inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
uses this parent POM will also effectively be saying "this project is also open
source", because the effective POM of all descendant projects will also include
this same license section.
Developers could try to remember to include some {{}} section to
override this license, but the whole point of the parent POM is that it should
given developers less to do, not more. Besides, some private projects (even
ours) might not wish to indicate a license at all!
There needs to be a way for our public parent POM to indicate that it is open
source without effectively making all child projects open source as well
through POM inheritance. Preventing the {{}} section from being
inherited is one example.
was:
There needs to a way in the Maven POM to prevent an element from being
inherited altogether in child POMs.
We are currently publishing a Maven POM that is useful to serve as the parent
POM for various projects. Some of the projects that use the POM will be open
source, but some will not be. To designate our parent POM as open source, we
include this:
{code:xml}
Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0
repo
{code:xml}
This essentially says, "this project is open source".
Unfortunately because of [POM
inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
uses this parent POM will also effectively be saying "this project is also open
source", because the effective POM of all descendant projects will also include
this same license section.
Developers could try to remember to include some {{}} section to
override this license, but the whole point of the parent POM is that it should
given developers less to do, not more. Besides, some private projects (even
ours) might not wish to indicate a license at all!
There needs to be a way for our public parent POM to indicate that it is open
source without effectively making all child projects open source as well
through POM inheritance. Preventing the {{}} section from being
inherited is one example.
> Mechanism for preventing inheritance of sections such as .
> ---
>
> Key: MNG-7562
> URL: https://issues.apache.org/jira/browse/MNG-7562
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.6
>Reporter: Garret Wilson
>Priority: Major
>
> There needs to a way in the Maven POM to prevent an element from being
> inherited altogether in child POMs.
> We are currently publishing a Maven POM that is useful to serve as the parent
> POM for various projects. Some of the projects that use the POM will be open
> source, but some will not be. To designate our parent POM as open source, we
> include this:
> {code:xml}
>
>
> Apache-2.0
> https://www.apache.org/licenses/LICENSE-2.0
> repo
>
>
> {code}
> This essentially says, "this project is open source".
> Unfortunately because of [POM
> inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
> uses this parent POM will also effectively be saying "this project is also
> open source", because the effective POM of all descendant projects will also
> include this same license section.
> Developers could try to remember to include some {{}} section to
> override this license, but the whole point of the parent POM is that it
> should given developers less to do, not more. Besides, some private projects
> (even ours) might not wish to indicate a license at all!
> There needs to be a way for our public parent POM to indicate that it is open
> source without effectively making all child projects open source as well
> through POM inheritance. Preventing the {{}} section from being
> inherited is one example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7562) Mechanism for preventing inheritance of sections such as .
Garret Wilson created MNG-7562:
--
Summary: Mechanism for preventing inheritance of sections such as
.
Key: MNG-7562
URL: https://issues.apache.org/jira/browse/MNG-7562
Project: Maven
Issue Type: Improvement
Components: Inheritance and Interpolation
Affects Versions: 3.8.6
Reporter: Garret Wilson
There needs to a way in the Maven POM to prevent an element from being
inherited altogether in child POMs.
We are currently publishing a Maven POM that is useful to serve as the parent
POM for various projects. Some of the projects that use the POM will be open
source, but some will not be. To designate our parent POM as open source, we
include this:
{code:xml}
Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0
repo
{code:xml}
This essentially says, "this project is open source".
Unfortunately because of [POM
inheritance|https://maven.apache.org/pom.html#Inheritance], any project that
uses this parent POM will also effectively be saying "this project is also open
source", because the effective POM of all descendant projects will also include
this same license section.
Developers could try to remember to include some {{}} section to
override this license, but the whole point of the parent POM is that it should
given developers less to do, not more. Besides, some private projects (even
ours) might not wish to indicate a license at all!
There needs to be a way for our public parent POM to indicate that it is open
source without effectively making all child projects open source as well
through POM inheritance. Preventing the {{}} section from being
inherited is one example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-581) critical error with non-ASCII charcters in directory name: cannot read Input length = 1
[
https://issues.apache.org/jira/browse/MJAVADOC-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MJAVADOC-581:
---
Description:
This is a critical bug that breaks the build. I originally posted this [on
Stack Overflow|https://stackoverflow.com/q/53449049/421049] but got no response.
I'm using OpenJDK 11 on Windows 10. I have a very simple POM, for a single Java
file, that generates Javadocs. Here is an extract:
{code:xml}
UTF-8
11
11
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
jar
{code}
Strangely just running {{mvn clean package}} causes an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (default) on project
foobar: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - cannot read Input length = 1
[ERROR]
[ERROR] Command line was: C:\bin\jdk-11\bin\javadoc.exe @options @packages
{noformat}
In {{target/apidocs}} there are only three files: {{javadoc.bat}}, {{options}},
and {{packages}}. The {{options}} file is the most interesting. It explicitly
says {{UTF-8}} everywhere, as it should. But look at these lines:
{noformat}
-sourcepath
C:/projects/li��o 1/src/main/java
{noformat}
This project is in {{C:\projects\lição 1}}. It appears that somewhere along the
chain Java or Maven or the Javadoc plugin didn't correctly convert the
directory name to UTF-8.
Sure enough; when I renamed the directories in Windows to remove non-ASCII
characters, {{mvn clean package}} worked just fine.
This would seem like a blatant bug; once Maven starts, everything should be
UTF-8 throughout.
One [answer on Stack Overflow|https://stackoverflow.com/a/53528778/421049]
gives you a hint of what's going wrong.
In any case, I consider this to be a huge bug related to fundamental
functioning. It absolutely must be fixed. Users can't suddenly see their build
broken if their directory name has a non-ASCII character in it.
was:
This is a critical bug that breaks the build. I originally posted this [on
Stack Overflow|https://stackoverflow.com/q/53449049/421049] but got no response.
I'm using OpenJDK 11 on Windows 10. I have a very simple POM, for a single Java
file, that generates Javadocs. Here is an extract:
{code:xml}
UTF-8
11
11
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
jar
{code}
Strangely just running {{mvn clean package}} causes an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (default) on project
foobar: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - cannot read Input length = 1
[ERROR]
[ERROR] Command line was: C:\bin\jdk-11\bin\javadoc.exe @options @packages
{noformat}
In {{target/apidocs}} there are only three files: {{javadoc.bat}}, {{options}},
and {{packages}}. The {{options}} file is the most interesting. It explicitly
says {{UTF-8}} everywhere, as it should. But look at these lines:
{noformat}
-sourcepath
C:/projects/li��o 1/src/main/java
{noformat}
This project is in {{C:\projects\lição 1}}. It appears that somewhere along the
chain Java or Maven or the Javadoc plugin didn't correctly convert the
directory name to UTF-8.
Sure enough; when I renamed the directories in Windows to remove non-ASCII
characters, {{mvn clean package}} worked just fine.
This would seem like a blatant bug; once Maven starts, everything should be
UTF-8 throughout.
One [answer on Stack Overflow|https://stackoverflow.com/a/53528778/421049]
gives you a hint of what's going wrong.
In any case, I consider this to be a huge, core bug. It absolutely must be
fixed. Users can't suddenly see their build broken if their directory name has
a non-ASCII character in it.
> critical error with non-ASCII charcters in directory name: cannot read Input
> length = 1
> ---
>
> Key: MJAVADOC-581
> URL: https://issues.apache.org/jira/browse/MJAVADOC-581
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
>Reporter: Garret Wilson
>Priority: Critical
>
> This is a critical bug that breaks the build. I originally posted this [on
> Stack Overflow|https://stackoverflow.com/q/53449049/421049] but got no
> response.
> I'm using OpenJDK 11 on Windows 10. I have a very simple POM, for a single
> Java file, that generates Ja
[jira] [Created] (MJAVADOC-581) critical error with non-ASCII charcters in directory name: cannot read Input length = 1
Garret Wilson created MJAVADOC-581:
--
Summary: critical error with non-ASCII charcters in directory
name: cannot read Input length = 1
Key: MJAVADOC-581
URL: https://issues.apache.org/jira/browse/MJAVADOC-581
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.1
Reporter: Garret Wilson
This is a critical bug that breaks the build. I originally posted this [on
Stack Overflow|https://stackoverflow.com/q/53449049/421049] but got no response.
I'm using OpenJDK 11 on Windows 10. I have a very simple POM, for a single Java
file, that generates Javadocs. Here is an extract:
{code:xml}
UTF-8
11
11
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
jar
{code}
Strangely just running {{mvn clean package}} causes an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (default) on project
foobar: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - cannot read Input length = 1
[ERROR]
[ERROR] Command line was: C:\bin\jdk-11\bin\javadoc.exe @options @packages
{noformat}
In {{target/apidocs}} there are only three files: {{javadoc.bat}}, {{options}},
and {{packages}}. The {{options}} file is the most interesting. It explicitly
says {{UTF-8}} everywhere, as it should. But look at these lines:
{noformat}
-sourcepath
C:/projects/li��o 1/src/main/java
{noformat}
This project is in {{C:\projects\lição 1}}. It appears that somewhere along the
chain Java or Maven or the Javadoc plugin didn't correctly convert the
directory name to UTF-8.
Sure enough; when I renamed the directories in Windows to remove non-ASCII
characters, {{mvn clean package}} worked just fine.
This would seem like a blatant bug; once Maven starts, everything should be
UTF-8 throughout.
One [answer on Stack Overflow|https://stackoverflow.com/a/53528778/421049]
gives you a hint of what's going wrong.
In any case, I consider this to be a huge, core bug. It absolutely must be
fixed. Users can't suddenly see their build broken if their directory name has
a non-ASCII character in it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
