[jira] [Commented] (MDEP-876) Potential Improvement for Maven
[
https://issues.apache.org/jira/browse/MDEP-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737971#comment-17737971
]
Michael Osipov commented on MDEP-876:
-
d...@maven.apache.org
> Potential Improvement for Maven
> ---
>
> Key: MDEP-876
> URL: https://issues.apache.org/jira/browse/MDEP-876
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: NRYet
>Priority: Minor
>
> Dear Maven maintainers, we are studying Maven dependency specifications and
> we would like to offer several possible improvements for Maven.
> (1) The scope management of Maven is complicated and hard to distinguish.
> Maven maintained 6 scopes (i.e., {_}compile{_}, {_}runtime{_},
> {_}provided{_}, {_}system{_}, {_}test{_}, and {_}import{_}). Compare to newer
> package managers such as NPM, which only has two scopes (i.e.,
> {_}dependencies{_}, {_}devdependencies{_}), Maven has too many types of
> scopes, which makes it more difficult for users to understand. We went over
> all POMs on the Maven Central (around 8M artifacts, collected in March 2022)
> and count the frequency of all types of scope. Some of the scopes are rarely
> used. Only 0.35% of POMs in the Maven Center used _system_ scope. Also,
> _system_ scope is similar to _provided_ scope, and _import_ scope can hardly
> be regarded as a dependency scope. We suggest simplifying the types of scopes
> by merging _system_ into _provided_ and removing {_}import{_}.
> (2) In the documentation of Default Artifact Handlers
> ([https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html]),
> _type_ and _classifier_ should introduce more commonly used values as their
> default value to provide better examples. We found that the default values
> are rarely used and are not good examples for users to understand the use of
> the settings. Setting commonly used values as default can help users
> understand the usage of the settings. We went over all POMs on the Maven
> Central (around 8M artifacts, collected in March 2022) and count the
> frequency of all possible values of classifier and type. According to our
> research, in {_}classifier{_}, the default values have low frequencies,
> including _tests_ (1.05%), _javadoc_ (0.35%), _sources_ (0.29%), and
> {_}client{_}(0.01%). More commonly used values are _features_ (1.20%),
> _linux-x86_64_ (0.34%), and _osx-x86_64_ (0.27%). As for type, the top
> default values are _pom_ (4.38%), _test-jar_ (2.85%), _war_ (1.08%) and the
> rest of the values are all below 0.1%. Other common examples are _esa_
> (2.53%), _zip_ (1.88%), and _xml_ (1.31%).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-876) Potential Improvement for Maven
[
https://issues.apache.org/jira/browse/MDEP-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737952#comment-17737952
]
NRYet commented on MDEP-876:
Sorry for bothering you. Would you please tell us which is the right forum to
raise the issue?
> Potential Improvement for Maven
> ---
>
> Key: MDEP-876
> URL: https://issues.apache.org/jira/browse/MDEP-876
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: NRYet
>Priority: Minor
>
> Dear Maven maintainers, we are studying Maven dependency specifications and
> we would like to offer several possible improvements for Maven.
> (1) The scope management of Maven is complicated and hard to distinguish.
> Maven maintained 6 scopes (i.e., {_}compile{_}, {_}runtime{_},
> {_}provided{_}, {_}system{_}, {_}test{_}, and {_}import{_}). Compare to newer
> package managers such as NPM, which only has two scopes (i.e.,
> {_}dependencies{_}, {_}devdependencies{_}), Maven has too many types of
> scopes, which makes it more difficult for users to understand. We went over
> all POMs on the Maven Central (around 8M artifacts, collected in March 2022)
> and count the frequency of all types of scope. Some of the scopes are rarely
> used. Only 0.35% of POMs in the Maven Center used _system_ scope. Also,
> _system_ scope is similar to _provided_ scope, and _import_ scope can hardly
> be regarded as a dependency scope. We suggest simplifying the types of scopes
> by merging _system_ into _provided_ and removing {_}import{_}.
> (2) In the documentation of Default Artifact Handlers
> ([https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html]),
> _type_ and _classifier_ should introduce more commonly used values as their
> default value to provide better examples. We found that the default values
> are rarely used and are not good examples for users to understand the use of
> the settings. Setting commonly used values as default can help users
> understand the usage of the settings. We went over all POMs on the Maven
> Central (around 8M artifacts, collected in March 2022) and count the
> frequency of all possible values of classifier and type. According to our
> research, in {_}classifier{_}, the default values have low frequencies,
> including _tests_ (1.05%), _javadoc_ (0.35%), _sources_ (0.29%), and
> {_}client{_}(0.01%). More commonly used values are _features_ (1.20%),
> _linux-x86_64_ (0.34%), and _osx-x86_64_ (0.27%). As for type, the top
> default values are _pom_ (4.38%), _test-jar_ (2.85%), _war_ (1.08%) and the
> rest of the values are all below 0.1%. Other common examples are _esa_
> (2.53%), _zip_ (1.88%), and _xml_ (1.31%).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7828) Bump guava from 31.1-android to 32.0.1-android
[ https://issues.apache.org/jira/browse/MNG-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737926#comment-17737926 ] ASF GitHub Bot commented on MNG-7828: - bvolpato opened a new pull request, #1189: URL: https://github.com/apache/maven/pull/1189 Update due to CVE-2023-2976. See https://issues.apache.org/jira/browse/MNG-7828 for more context. > Bump guava from 31.1-android to 32.0.1-android > -- > > Key: MNG-7828 > URL: https://issues.apache.org/jira/browse/MNG-7828 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.x-candidate, 4.0.x-candidate >Reporter: Bruno Candido Volpato da Cunha >Priority: Major > > Currently used version is in the range of CVE-2023-2976, which was fixed in > 32.0.0. > > Please check [https://osv.dev/vulnerability/GHSA-7g45-4rm6-3mm3] for more > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7828) Bump guava from 31.1-android to 32.0.1-android
Bruno Candido Volpato da Cunha created MNG-7828: --- Summary: Bump guava from 31.1-android to 32.0.1-android Key: MNG-7828 URL: https://issues.apache.org/jira/browse/MNG-7828 Project: Maven Issue Type: Dependency upgrade Affects Versions: 3.9.x-candidate, 4.0.x-candidate Reporter: Bruno Candido Volpato da Cunha Currently used version is in the range of CVE-2023-2976, which was fixed in 32.0.0. Please check [https://osv.dev/vulnerability/GHSA-7g45-4rm6-3mm3] for more information. -- 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=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=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=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=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=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
>
[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=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=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=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=17737842#comment-17737842
]
Michael Osipov commented on MASSEMBLY-992:
--
Search for michael-o-parent on GitHub, there I do attach files to.my parent.
> 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] (MNG-7827) Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback
[ https://issues.apache.org/jira/browse/MNG-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737841#comment-17737841 ] ASF GitHub Bot commented on MNG-7827: - rmannibucau commented on PR #1187: URL: https://github.com/apache/maven/pull/1187#issuecomment-1610054965 @gnodet there are two goals: 1. Drop the irrelevant documentation we never agreed upon to use SLF4J (api) for plugins 2. Ensure the default is the actual maven logging system and not stdout/stderr directly for other cases if it is present v4 API is more a way to do the bridge easily and with less internal efforts (since it is hidden anyway) > Fix org.apache.maven.plugin.logging.Log deprecation message and > AbstractMojo#getLog fallback > > > Key: MNG-7827 > URL: https://issues.apache.org/jira/browse/MNG-7827 > Project: Maven > Issue Type: Improvement > Components: Plugin API >Affects Versions: 4.0.0-alpha-7 >Reporter: Romain Manni-Bucau >Priority: Major > > In maven 4 an official Log API was created and using SLF4J as primary logging > solution is not recommended nor the official way so javadoc and impl should > be aligned to reflcet that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7827) Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback
[ https://issues.apache.org/jira/browse/MNG-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737834#comment-17737834 ] ASF GitHub Bot commented on MNG-7827: - gnodet commented on PR #1187: URL: https://github.com/apache/maven/pull/1187#issuecomment-1610044135 @rmannibucau not sure what the point of this PR is. I would not force 3.x plugins to use the maven 4 api, I think it's better to keep it for 4.x plugins. > Fix org.apache.maven.plugin.logging.Log deprecation message and > AbstractMojo#getLog fallback > > > Key: MNG-7827 > URL: https://issues.apache.org/jira/browse/MNG-7827 > Project: Maven > Issue Type: Improvement > Components: Plugin API >Affects Versions: 4.0.0-alpha-7 >Reporter: Romain Manni-Bucau >Priority: Major > > In maven 4 an official Log API was created and using SLF4J as primary logging > solution is not recommended nor the official way so javadoc and impl should > be aligned to reflcet that. -- 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=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] (MNG-7826) Maven Plugin Validation: Jacoco plugin is not reported as problem
[
https://issues.apache.org/jira/browse/MNG-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737822#comment-17737822
]
ASF GitHub Bot commented on MNG-7826:
-
cstamas commented on PR #1186:
URL: https://github.com/apache/maven/pull/1186#issuecomment-160857
This is not going in as it is, details on JIRA issue. Making this into DRAFT.
> Maven Plugin Validation: Jacoco plugin is not reported as problem
> -
>
> Key: MNG-7826
> URL: https://issues.apache.org/jira/browse/MNG-7826
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.9.3
>Reporter: Tamas Cservenak
>Priority: Major
>
> Maven 3.9.2 regarding jacoco maven plugin 0.8.10 reports this:
> {noformat}
> [WARNING] * org.jacoco:jacoco-maven-plugin:0.8.10
> [WARNING] Declared at location(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml) @ line 484
> [WARNING] Used in module(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml)
> [WARNING]* com.soebes.smpp:smpp-plugins:6.0.4-SNAPSHOT
> (smpp-plugins/pom.xml)
> [WARNING] Plugin issue(s):
> [WARNING]* Plugin is a Maven 2.x plugin, which will be not supported in
> Maven 4.x
> [WARNING]* Plugin mixes multiple Maven versions: [3.0, 2.0.2]
> [WARNING]* Plugin should declare these Maven artifacts in `provided`
> scope: [org.apache.maven:maven-repository-metadata:3.0,
> org.apache.maven:maven-artifact:3.0]
> [WARNING]* Plugin depends on plexus-container-default, which is EOL
> {noformat}
> and all these are true: culprit is ancient shared file-management, that the
> plugin depends in compile scope, while it brings in
> * p-c-d
> * maven-plugin-api, maven-artifact-manager etc from mvn 2.0.2
> * etc
> Maven 3.9.3 does not report anything related to this plugin, while if 3.9.3
> runs a build using it, it clearly shows this in debug (presence of Maven 2
> artifacts and p-c-d):
> {noformat}
> [INFO] --- jacoco:0.8.10:prepare-agent (default) @ smpp ---
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for snapshots (http://snapshots.maven.codehaus.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://cvs.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for central (http://repo1.maven.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=88693,
> ConflictMarker.markTime=60265, ConflictMarker.nodeCount=38,
> ConflictIdSorter.graphTime=53367, ConflictIdSorter.topsortTime=15824,
> ConflictIdSorter.conflictIdCount=21, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=753636, ConflictResolver.conflictItemCount=34,
> DfDependencyCollector.collectTime=66088125,
> DfDependencyCollector.transformTime=990804}
> [DEBUG] org.jacoco:jacoco-maven-plugin:jar:0.8.10
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.apache.maven.shared:file-management:jar:1.2.1:compile
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6:compile
> [DEBUG] org.apache.maven.shared:maven-shared-io:jar:1.1:compile
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.2:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven:maven-repository-metadata:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
> [DEBUG] junit:junit:jar:4.13.1:compile (version managed from default)
> [DEBUG] org.hamcrest:hamcrest-core:jar:1.3:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> [DEBUG] org.apache.maven.doxia:doxia-sink-api:jar:1.0:compile
> [DEBUG]org.jacoco:org.jacoco.agent:jar:runtime:0.8.10:compile
> [DEBUG]org.jacoco:org.jacoco.core:jar:0.8.10:compile
> [DEBUG] org.ow2.asm:asm:jar:9.5:compile (version managed from default)
[GitHub] [maven] cstamas commented on pull request #1186: [MNG-7826] Validate plugin transitive dependencies as well
cstamas commented on PR #1186: URL: https://github.com/apache/maven/pull/1186#issuecomment-160857 This is not going in as it is, details on JIRA issue. Making this into DRAFT. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (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=17737806#comment-17737806
]
Michael Osipov commented on MASSEMBLY-992:
--
You can attached the assembly desc to your parent POM, I think a separate one
is not required. You should give it a try because I'm certain that does the
job. If it does, no one is going to implement this request.
> 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=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
[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=17737793#comment-17737793
]
Michael Osipov commented on MASSEMBLY-992:
--
You are looking for
[https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html.]
Please evaluate that. The actual source does not matter anymore, it works
regardless of the source.
> 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
]
Michael Osipov updated MASSEMBLY-992:
-
Fix Version/s: waiting-for-feedback
> 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
> [#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=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=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] [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=17737753#comment-17737753
]
Michael Osipov commented on MASSEMBLY-992:
--
One can use remote resources for that. This plugin supports this.
> 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] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737716#comment-17737716
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
olamy commented on PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1609714887
is it possible to have an IT test? as I cannot see any test here. thanks
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] olamy commented on pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
olamy commented on PR #667: URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1609714887 is it possible to have an IT test? as I cannot see any test here. thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737678#comment-17737678
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1243772435
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +285,21 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Additional Maven dependencies to be used in the test execution
classpath.
+ * Each element supports the parametrization like documented in https://maven.apache.org/pom.html#dependencies;>POM Reference:
Dependencies.
+ *
+ * Those dependencies are automatically collected (i.e. have their full
dependency tree calculated) and then all underlying artifacts are resolved from
the repository (including their transitive dependencies).
+ * Afterwards the resolved artifacts are filtered to only contain {@code
compile} and {@code runtime} scoped ones and appended to the test execution
classpath
+ * (after the ones from {@link #additionalClasspathElements}).
+ *
+ * The dependency management from the project is not taken into account.
+ *
+ * @since 3.2
+ */
+@Parameter(property = "maven.test.additionalClasspathDependencies")
+private Dependency[] additionalClasspathDependencies;
Review Comment:
This is just to be more in line with existing parameters. But I can switch
to `List`. The `null` check is not necessary for either array nor Collection,
as plexus.inject will inject an empty array.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737679#comment-17737679
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1243773343
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -3474,6 +3552,14 @@ public void setAdditionalClasspathElements(String[]
additionalClasspathElements)
this.additionalClasspathElements = additionalClasspathElements;
}
+public Dependency[] getAdditionalClasspathDependencies() {
+return additionalClasspathDependencies;
+}
+
+public void setAdditionalClasspathDependencies(Dependency[]
additionalClasspathDependencies) {
+this.additionalClasspathDependencies = additionalClasspathDependencies;
+}
Review Comment:
Right, this was again to be in line with other parameters, but agree we
don't need them.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin commented on a diff in pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1243773343
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -3474,6 +3552,14 @@ public void setAdditionalClasspathElements(String[]
additionalClasspathElements)
this.additionalClasspathElements = additionalClasspathElements;
}
+public Dependency[] getAdditionalClasspathDependencies() {
+return additionalClasspathDependencies;
+}
+
+public void setAdditionalClasspathDependencies(Dependency[]
additionalClasspathDependencies) {
+this.additionalClasspathDependencies = additionalClasspathDependencies;
+}
Review Comment:
Right, this was again to be in line with other parameters, but agree we
don't need them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] kwin commented on a diff in pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1243772435
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +285,21 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Additional Maven dependencies to be used in the test execution
classpath.
+ * Each element supports the parametrization like documented in https://maven.apache.org/pom.html#dependencies;>POM Reference:
Dependencies.
+ *
+ * Those dependencies are automatically collected (i.e. have their full
dependency tree calculated) and then all underlying artifacts are resolved from
the repository (including their transitive dependencies).
+ * Afterwards the resolved artifacts are filtered to only contain {@code
compile} and {@code runtime} scoped ones and appended to the test execution
classpath
+ * (after the ones from {@link #additionalClasspathElements}).
+ *
+ * The dependency management from the project is not taken into account.
+ *
+ * @since 3.2
+ */
+@Parameter(property = "maven.test.additionalClasspathDependencies")
+private Dependency[] additionalClasspathDependencies;
Review Comment:
This is just to be more in line with existing parameters. But I can switch
to `List`. The `null` check is not necessary for either array nor Collection,
as plexus.inject will inject an empty array.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737677#comment-17737677
]
Michael Osipov commented on DOXIASITETOOLS-254:
---
What is left is to modify Fluido Skin...
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737671#comment-17737671
]
Michael Osipov edited comment on DOXIASITETOOLS-254 at 6/27/23 1:34 PM:
I have now uploaded all branches with fixes. The new, proposed model for site
with a new converter along with test. Maven Site Plugin works and MPIR tests
all work. The conversion works on the fly and issues the he following warning:
bq. [WARNING] Site model of
'org.apache.maven.plugins.project-info-reports.its:mpir-229:pom:1.0-SNAPSHOT'
for default locale is still using the old pre-version 2.0.0 model. You MUST
migrate to the new model as soon as possible otherwise your build will break in
the future!
was (Author: michael-o):
I have now uploaded all branches with fixes. The new, proposed model for site
with a new converter along with test. Maven Site Plugin works and MPIR tests
all work. The conversion works on the fly and issues the he following warning:
> [WARNING] Site model of
> 'org.apache.maven.plugins.project-info-reports.its:mpir-229:pom:1.0-SNAPSHOT'
> for default locale is still using the old pre-version 2.0.0 model. You MUST
> migrate to the new model as soon as possible otherwise your build will break
> in the future!
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737671#comment-17737671
]
Michael Osipov commented on DOXIASITETOOLS-254:
---
I have now uploaded all branches with fixes. The new, proposed model for site
with a new converter along with test. Maven Site Plugin works and MPIR tests
all work. The conversion works on the fly and issues the he following warning:
> [WARNING] Site model of
> 'org.apache.maven.plugins.project-info-reports.its:mpir-229:pom:1.0-SNAPSHOT'
> for default locale is still using the old pre-version 2.0.0 model. You MUST
> migrate to the new model as soon as possible otherwise your build will break
> in the future!
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned DOXIASITETOOLS-254:
-
Assignee: Michael Osipov
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737661#comment-17737661 ] Tomas Langer commented on MNG-6877: --- Plugin dependencies need explicit versions defined, they ignore dependency management > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737660#comment-17737660 ] Stanislav Spiridonov commented on MNG-6877: --- Anyway, it solves my mine issue (2 pass build). Do anybody know if the plugin dependencies follow the rules from the *dependencyManagement* section? > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737657#comment-17737657 ] Stanislav Spiridonov commented on MNG-6877: --- No, it isn't on project CP. IMHO If the dependency is on plugin level it isn't on project CP (it is on tool level), but it also means that "default discovery of annotation processor" is not working so you need to duplicate the APT processor in the annotationProcessorPaths section > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737656#comment-17737656 ] Tamas Cservenak commented on MNG-6877: -- Well, you DO extend compiler with annotation processor, no? And yes, this fixes the reactor ordering as well. > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737655#comment-17737655 ] Tomas Langer commented on MNG-6877: --- That is also not correct, is it? Plugin dependencies are to extend the features of the plugin, not to add annotations processors. If that is a workaround for the reactor ordering, then I get it, and we can use it. But I do not see that as a solution of the problem > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737654#comment-17737654 ] Tamas Cservenak edited comment on MNG-6877 at 6/27/23 1:05 PM: --- By adding it to plugin dependencies, it is not on module classpath, or wdym? was (Author: cstamas): By adding it to plugin, it is not on module classpath, or wdym? > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737654#comment-17737654 ] Tamas Cservenak commented on MNG-6877: -- By adding it to plugin, it is not on module classpath, or wdym? > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7826) Maven Plugin Validation: Jacoco plugin is not reported as problem
[
https://issues.apache.org/jira/browse/MNG-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737652#comment-17737652
]
Slawomir Jaranowski commented on MNG-7826:
--
[~cstamas] your output is similar to my ... please look for:
{{org.apache.maven:maven-core}}
In plugin code it is declared as {{provided}}, but when plugin dependencies are
resolved by Maven all {{provided}} artifacts are filtered early .. and
transitive artifact are resolved in oryginal versions and scope.
> Maven Plugin Validation: Jacoco plugin is not reported as problem
> -
>
> Key: MNG-7826
> URL: https://issues.apache.org/jira/browse/MNG-7826
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.9.3
>Reporter: Tamas Cservenak
>Priority: Major
>
> Maven 3.9.2 regarding jacoco maven plugin 0.8.10 reports this:
> {noformat}
> [WARNING] * org.jacoco:jacoco-maven-plugin:0.8.10
> [WARNING] Declared at location(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml) @ line 484
> [WARNING] Used in module(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml)
> [WARNING]* com.soebes.smpp:smpp-plugins:6.0.4-SNAPSHOT
> (smpp-plugins/pom.xml)
> [WARNING] Plugin issue(s):
> [WARNING]* Plugin is a Maven 2.x plugin, which will be not supported in
> Maven 4.x
> [WARNING]* Plugin mixes multiple Maven versions: [3.0, 2.0.2]
> [WARNING]* Plugin should declare these Maven artifacts in `provided`
> scope: [org.apache.maven:maven-repository-metadata:3.0,
> org.apache.maven:maven-artifact:3.0]
> [WARNING]* Plugin depends on plexus-container-default, which is EOL
> {noformat}
> and all these are true: culprit is ancient shared file-management, that the
> plugin depends in compile scope, while it brings in
> * p-c-d
> * maven-plugin-api, maven-artifact-manager etc from mvn 2.0.2
> * etc
> Maven 3.9.3 does not report anything related to this plugin, while if 3.9.3
> runs a build using it, it clearly shows this in debug (presence of Maven 2
> artifacts and p-c-d):
> {noformat}
> [INFO] --- jacoco:0.8.10:prepare-agent (default) @ smpp ---
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for snapshots (http://snapshots.maven.codehaus.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://cvs.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for central (http://repo1.maven.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=88693,
> ConflictMarker.markTime=60265, ConflictMarker.nodeCount=38,
> ConflictIdSorter.graphTime=53367, ConflictIdSorter.topsortTime=15824,
> ConflictIdSorter.conflictIdCount=21, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=753636, ConflictResolver.conflictItemCount=34,
> DfDependencyCollector.collectTime=66088125,
> DfDependencyCollector.transformTime=990804}
> [DEBUG] org.jacoco:jacoco-maven-plugin:jar:0.8.10
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.apache.maven.shared:file-management:jar:1.2.1:compile
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6:compile
> [DEBUG] org.apache.maven.shared:maven-shared-io:jar:1.1:compile
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.2:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven:maven-repository-metadata:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
> [DEBUG] junit:junit:jar:4.13.1:compile (version managed from default)
> [DEBUG] org.hamcrest:hamcrest-core:jar:1.3:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> [DEBUG] org.apache.maven.doxia:doxia-sink-api:jar:1.0:compile
> [DEBUG]org.jacoco:org.jacoco.agent:jar:runtime:0.8.10:compile
>
[jira] [Commented] (MNG-6877) Separate scope for annotation processing
[ https://issues.apache.org/jira/browse/MNG-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737650#comment-17737650 ] Tomas Langer commented on MNG-6877: --- The problem is that it SHOULD NOT BE on the classpath of the module. It should only be defined on the `annotationProcessorPath`. > Separate scope for annotation processing > > > Key: MNG-6877 > URL: https://issues.apache.org/jira/browse/MNG-6877 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Stanislav Spiridonov >Priority: Major > > Hi, I know about annotationProcessorPaths of maven-compiler-plugin and it > works somehow, but with some limitations > # dependencyManagement does not work for path elements (need to specify > version). workaround use variable > # if I have apt-processor as a part of the project (separate module) and use > it only in the maven-compiler-plugin configuration it has been built in the > last order, that brakes build > # the maven-compiler-plugin can use only INSTALLED artifacts, not from a > reactor > > Use the processor as a usual dependency is also not a case (even with > provided scope) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1284) Use jdk.security.jarsigner.JarSigner instead of CLI and Javatool from maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737620#comment-17737620 ] Michael Osipov commented on MSHARED-1284: - Is JAR signing still a think? I thought it is more or less dead, no? > Use jdk.security.jarsigner.JarSigner instead of CLI and Javatool from > maven-shared-utils > > > Key: MSHARED-1284 > URL: https://issues.apache.org/jira/browse/MSHARED-1284 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-jarsigner >Reporter: Elliotte Rusty Harold >Priority: Major > > When we move to Java 9+ one of these days (not anytime soon) we can use > jdk.security.jarsigner.JarSigner instead of the current CLI based hack that > shells out to the command line jarsigner tool -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1284) Use jdk.security.jarsigner.JarSigner instead of CLI and Javatool from maven-shared-utils
Elliotte Rusty Harold created MSHARED-1284: -- Summary: Use jdk.security.jarsigner.JarSigner instead of CLI and Javatool from maven-shared-utils Key: MSHARED-1284 URL: https://issues.apache.org/jira/browse/MSHARED-1284 Project: Maven Shared Components Issue Type: Improvement Components: maven-jarsigner Reporter: Elliotte Rusty Harold When we move to Java 9+ one of these days (not anytime soon) we can use jdk.security.jarsigner.JarSigner instead of the current CLI based hack that shells out to the command line jarsigner tool -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7826) Maven Plugin Validation: Jacoco plugin is not reported as problem
[
https://issues.apache.org/jira/browse/MNG-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737591#comment-17737591
]
Tamas Cservenak commented on MNG-7826:
--
This is my output:
https://gist.github.com/cstamas/2387fcbe072247232e88f84c7e96f9cb
How it was made: mvn install master (git commit
4ed696e06d03486a17d9604d46697fc6b357b8ef) then {{mvn
dependency:3.6.1-SNAPSHOT:tree -X}}
> Maven Plugin Validation: Jacoco plugin is not reported as problem
> -
>
> Key: MNG-7826
> URL: https://issues.apache.org/jira/browse/MNG-7826
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.9.3
>Reporter: Tamas Cservenak
>Priority: Major
>
> Maven 3.9.2 regarding jacoco maven plugin 0.8.10 reports this:
> {noformat}
> [WARNING] * org.jacoco:jacoco-maven-plugin:0.8.10
> [WARNING] Declared at location(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml) @ line 484
> [WARNING] Used in module(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml)
> [WARNING]* com.soebes.smpp:smpp-plugins:6.0.4-SNAPSHOT
> (smpp-plugins/pom.xml)
> [WARNING] Plugin issue(s):
> [WARNING]* Plugin is a Maven 2.x plugin, which will be not supported in
> Maven 4.x
> [WARNING]* Plugin mixes multiple Maven versions: [3.0, 2.0.2]
> [WARNING]* Plugin should declare these Maven artifacts in `provided`
> scope: [org.apache.maven:maven-repository-metadata:3.0,
> org.apache.maven:maven-artifact:3.0]
> [WARNING]* Plugin depends on plexus-container-default, which is EOL
> {noformat}
> and all these are true: culprit is ancient shared file-management, that the
> plugin depends in compile scope, while it brings in
> * p-c-d
> * maven-plugin-api, maven-artifact-manager etc from mvn 2.0.2
> * etc
> Maven 3.9.3 does not report anything related to this plugin, while if 3.9.3
> runs a build using it, it clearly shows this in debug (presence of Maven 2
> artifacts and p-c-d):
> {noformat}
> [INFO] --- jacoco:0.8.10:prepare-agent (default) @ smpp ---
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for snapshots (http://snapshots.maven.codehaus.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://cvs.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for central (http://repo1.maven.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=88693,
> ConflictMarker.markTime=60265, ConflictMarker.nodeCount=38,
> ConflictIdSorter.graphTime=53367, ConflictIdSorter.topsortTime=15824,
> ConflictIdSorter.conflictIdCount=21, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=753636, ConflictResolver.conflictItemCount=34,
> DfDependencyCollector.collectTime=66088125,
> DfDependencyCollector.transformTime=990804}
> [DEBUG] org.jacoco:jacoco-maven-plugin:jar:0.8.10
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.apache.maven.shared:file-management:jar:1.2.1:compile
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6:compile
> [DEBUG] org.apache.maven.shared:maven-shared-io:jar:1.1:compile
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.2:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven:maven-repository-metadata:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
> [DEBUG] junit:junit:jar:4.13.1:compile (version managed from default)
> [DEBUG] org.hamcrest:hamcrest-core:jar:1.3:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> [DEBUG] org.apache.maven.doxia:doxia-sink-api:jar:1.0:compile
> [DEBUG]org.jacoco:org.jacoco.agent:jar:runtime:0.8.10:compile
> [DEBUG]org.jacoco:org.jacoco.core:jar:0.8.10:compile
> [DEBUG]
[jira] [Commented] (MNG-7826) Maven Plugin Validation: Jacoco plugin is not reported as problem
[
https://issues.apache.org/jira/browse/MNG-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737586#comment-17737586
]
Tamas Cservenak commented on MNG-7826:
--
[~sjaranowski]why the difference of plugin versions above? Can you repeat both
steps with same version (3.6.0 or 3.6.1-SNAPSHOT)?
> Maven Plugin Validation: Jacoco plugin is not reported as problem
> -
>
> Key: MNG-7826
> URL: https://issues.apache.org/jira/browse/MNG-7826
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.9.3
>Reporter: Tamas Cservenak
>Priority: Major
>
> Maven 3.9.2 regarding jacoco maven plugin 0.8.10 reports this:
> {noformat}
> [WARNING] * org.jacoco:jacoco-maven-plugin:0.8.10
> [WARNING] Declared at location(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml) @ line 484
> [WARNING] Used in module(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.4-SNAPSHOT (pom.xml)
> [WARNING]* com.soebes.smpp:smpp-plugins:6.0.4-SNAPSHOT
> (smpp-plugins/pom.xml)
> [WARNING] Plugin issue(s):
> [WARNING]* Plugin is a Maven 2.x plugin, which will be not supported in
> Maven 4.x
> [WARNING]* Plugin mixes multiple Maven versions: [3.0, 2.0.2]
> [WARNING]* Plugin should declare these Maven artifacts in `provided`
> scope: [org.apache.maven:maven-repository-metadata:3.0,
> org.apache.maven:maven-artifact:3.0]
> [WARNING]* Plugin depends on plexus-container-default, which is EOL
> {noformat}
> and all these are true: culprit is ancient shared file-management, that the
> plugin depends in compile scope, while it brings in
> * p-c-d
> * maven-plugin-api, maven-artifact-manager etc from mvn 2.0.2
> * etc
> Maven 3.9.3 does not report anything related to this plugin, while if 3.9.3
> runs a build using it, it clearly shows this in debug (presence of Maven 2
> artifacts and p-c-d):
> {noformat}
> [INFO] --- jacoco:0.8.10:prepare-agent (default) @ smpp ---
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for snapshots (http://snapshots.maven.codehaus.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://cvs.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for central (http://repo1.maven.org/maven2).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://people.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror px-oss (http://urnebes.local:8881/content/groups/oss/)
> for apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=88693,
> ConflictMarker.markTime=60265, ConflictMarker.nodeCount=38,
> ConflictIdSorter.graphTime=53367, ConflictIdSorter.topsortTime=15824,
> ConflictIdSorter.conflictIdCount=21, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=753636, ConflictResolver.conflictItemCount=34,
> DfDependencyCollector.collectTime=66088125,
> DfDependencyCollector.transformTime=990804}
> [DEBUG] org.jacoco:jacoco-maven-plugin:jar:0.8.10
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.apache.maven.shared:file-management:jar:1.2.1:compile
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6:compile
> [DEBUG] org.apache.maven.shared:maven-shared-io:jar:1.1:compile
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.2:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven:maven-repository-metadata:jar:2.0.2:compile
> [DEBUG]
> org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
> [DEBUG] junit:junit:jar:4.13.1:compile (version managed from default)
> [DEBUG] org.hamcrest:hamcrest-core:jar:1.3:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> [DEBUG] org.apache.maven.doxia:doxia-sink-api:jar:1.0:compile
> [DEBUG]org.jacoco:org.jacoco.agent:jar:runtime:0.8.10:compile
> [DEBUG]org.jacoco:org.jacoco.core:jar:0.8.10:compile
> [DEBUG] org.ow2.asm:asm:jar:9.5:compile (version managed from default)
> [DEBUG]
[jira] [Commented] (MRESOLVER-216) [ERROR] Malformed \uxxxx encoding.
[
https://issues.apache.org/jira/browse/MRESOLVER-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737579#comment-17737579
]
Yuming Wang commented on MRESOLVER-216:
---
Try: {{grep -lrnw ~/.m2 -e '\u'| xargs rm}}
> [ERROR] Malformed \u encoding.
> --
>
> Key: MRESOLVER-216
> URL: https://issues.apache.org/jira/browse/MRESOLVER-216
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Lado Kumsiashvili
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: Screenshot 2021-12-26 at 14.44.41.png, Screenshot
> 2021-12-26 at 14.44.50.png, consoleText.txt
>
>
> We do still experience this "supposed to be fixed" Bug in maven resolver in
> our team. We use maven 3.8.2 and I guess it is packaged with 1.6.3 resolver.
> It occurs sometimes and never with
> {code:java}
> -Daether.metadataResolver.threads=1 {code}
>
> {code:java}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/Cellar/maven/3.8.2/libexec
> Java version: 1.8.0_301, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" {code}
>
> This is how the maven run with
> {code:java}
> mvn -X install {code}
> fails
> {code:java}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 8.035 s
> [INFO] Finished at: 2021-10-06T10:04:20+02:00
> [INFO]
>
> [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:574)
> at java.util.Properties.load0 (Properties.java:391)
> at java.util.Properties.load (Properties.java:341)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at
> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion
> (DefaultVersionResolver.java:213)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
> (DefaultArtifactDescriptorReader.java:204)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
> (DefaultArtifactDescriptorReader.java:171)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
> (DefaultDependencyCollector.java:538)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
> (DefaultDependencyCollector.java:523)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:410)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:506)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:458)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
> (DefaultProjectDependenciesResolver.java:170)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:243)
> at
[jira] [Closed] (MDEP-876) Potential Improvement for Maven
[
https://issues.apache.org/jira/browse/MDEP-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MDEP-876.
---
Resolution: Invalid
Wrong forum.
> Potential Improvement for Maven
> ---
>
> Key: MDEP-876
> URL: https://issues.apache.org/jira/browse/MDEP-876
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: NRYet
>Priority: Minor
>
> Dear Maven maintainers, we are studying Maven dependency specifications and
> we would like to offer several possible improvements for Maven.
> (1) The scope management of Maven is complicated and hard to distinguish.
> Maven maintained 6 scopes (i.e., {_}compile{_}, {_}runtime{_},
> {_}provided{_}, {_}system{_}, {_}test{_}, and {_}import{_}). Compare to newer
> package managers such as NPM, which only has two scopes (i.e.,
> {_}dependencies{_}, {_}devdependencies{_}), Maven has too many types of
> scopes, which makes it more difficult for users to understand. We went over
> all POMs on the Maven Central (around 8M artifacts, collected in March 2022)
> and count the frequency of all types of scope. Some of the scopes are rarely
> used. Only 0.35% of POMs in the Maven Center used _system_ scope. Also,
> _system_ scope is similar to _provided_ scope, and _import_ scope can hardly
> be regarded as a dependency scope. We suggest simplifying the types of scopes
> by merging _system_ into _provided_ and removing {_}import{_}.
> (2) In the documentation of Default Artifact Handlers
> ([https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html]),
> _type_ and _classifier_ should introduce more commonly used values as their
> default value to provide better examples. We found that the default values
> are rarely used and are not good examples for users to understand the use of
> the settings. Setting commonly used values as default can help users
> understand the usage of the settings. We went over all POMs on the Maven
> Central (around 8M artifacts, collected in March 2022) and count the
> frequency of all possible values of classifier and type. According to our
> research, in {_}classifier{_}, the default values have low frequencies,
> including _tests_ (1.05%), _javadoc_ (0.35%), _sources_ (0.29%), and
> {_}client{_}(0.01%). More commonly used values are _features_ (1.20%),
> _linux-x86_64_ (0.34%), and _osx-x86_64_ (0.27%). As for type, the top
> default values are _pom_ (4.38%), _test-jar_ (2.85%), _war_ (1.08%) and the
> rest of the values are all below 0.1%. Other common examples are _esa_
> (2.53%), _zip_ (1.88%), and _xml_ (1.31%).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-876) Potential Improvement for Maven
NRYet created MDEP-876:
--
Summary: Potential Improvement for Maven
Key: MDEP-876
URL: https://issues.apache.org/jira/browse/MDEP-876
Project: Maven Dependency Plugin
Issue Type: Improvement
Reporter: NRYet
Dear Maven maintainers, we are studying Maven dependency specifications and we
would like to offer several possible improvements for Maven.
(1) The scope management of Maven is complicated and hard to distinguish. Maven
maintained 6 scopes (i.e., {_}compile{_}, {_}runtime{_}, {_}provided{_},
{_}system{_}, {_}test{_}, and {_}import{_}). Compare to newer package managers
such as NPM, which only has two scopes (i.e., {_}dependencies{_},
{_}devdependencies{_}), Maven has too many types of scopes, which makes it more
difficult for users to understand. We went over all POMs on the Maven Central
(around 8M artifacts, collected in March 2022) and count the frequency of all
types of scope. Some of the scopes are rarely used. Only 0.35% of POMs in the
Maven Center used _system_ scope. Also, _system_ scope is similar to _provided_
scope, and _import_ scope can hardly be regarded as a dependency scope. We
suggest simplifying the types of scopes by merging _system_ into _provided_ and
removing {_}import{_}.
(2) In the documentation of Default Artifact Handlers
([https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html]),
_type_ and _classifier_ should introduce more commonly used values as their
default value to provide better examples. We found that the default values are
rarely used and are not good examples for users to understand the use of the
settings. Setting commonly used values as default can help users understand the
usage of the settings. We went over all POMs on the Maven Central (around 8M
artifacts, collected in March 2022) and count the frequency of all possible
values of classifier and type. According to our research, in {_}classifier{_},
the default values have low frequencies, including _tests_ (1.05%), _javadoc_
(0.35%), _sources_ (0.29%), and {_}client{_}(0.01%). More commonly used values
are _features_ (1.20%), _linux-x86_64_ (0.34%), and _osx-x86_64_ (0.27%). As
for type, the top default values are _pom_ (4.38%), _test-jar_ (2.85%), _war_
(1.08%) and the rest of the values are all below 0.1%. Other common examples
are _esa_ (2.53%), _zip_ (1.88%), and _xml_ (1.31%).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-374. - Resolution: Won't Fix As reporter explains, this was more his code. In short, resolver regarding locking has some expectations, that has to be met, to be able to guarantee proper working. > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more than 70% of attempts to build a Maven Project end > up with getting `.IllegalStateException: Could not acquire lock(s)` exception: > > ``` > Jun 23, 2023 2:23:02 PM > org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache > SEVERE: Could not acquire lock(s) > java.lang.IllegalStateException: Could not acquire lock(s) > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:271) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:259) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) > at > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) > at > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) > at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) > at > org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) > at > org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire > write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 > SECONDS > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) > ... 26 more > Suppressed:
[jira] [Commented] (MENFORCER-486) Bump commons-codec from 1.15 to 1.16.0
[ https://issues.apache.org/jira/browse/MENFORCER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737476#comment-17737476 ] ASF GitHub Bot commented on MENFORCER-486: -- slawekjaranowski opened a new pull request, #276: URL: https://github.com/apache/maven-enforcer/pull/276 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). > Bump commons-codec from 1.15 to 1.16.0 > -- > > Key: MENFORCER-486 > URL: https://issues.apache.org/jira/browse/MENFORCER-486 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski opened a new pull request, #276: [MENFORCER-486] Bump commons-codec from 1.15 to 1.16.0
slawekjaranowski opened a new pull request, #276: URL: https://github.com/apache/maven-enforcer/pull/276 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MENFORCER-486) Bump commons-codec from 1.15 to 1.16.0
Slawomir Jaranowski created MENFORCER-486: - Summary: Bump commons-codec from 1.15 to 1.16.0 Key: MENFORCER-486 URL: https://issues.apache.org/jira/browse/MENFORCER-486 Project: Maven Enforcer Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #274: Bump guava from 30.1.1-jre to 32.0.0-jre in /maven-enforcer-plugin/src/it/projects/dependency-convergence-cycle
slawekjaranowski merged PR #274: URL: https://github.com/apache/maven-enforcer/pull/274 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
