[jira] [Commented] (MNG-6523) System Dependencies Deprecation
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454419#comment-17454419 ] Michael Osipov commented on MNG-6523: - What about installing locally? > System Dependencies Deprecation > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > Fix For: wontfix-candidate > > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resources-plugin] dependabot[bot] opened a new pull request #9: Bump mavenVersion from 3.1.0 to 3.8.4
dependabot[bot] opened a new pull request #9: URL: https://github.com/apache/maven-resources-plugin/pull/9 Bumps `mavenVersion` from 3.1.0 to 3.8.4. Updates `maven-plugin-api` from 3.1.0 to 3.8.4 Commits https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537;>9b656c7 [maven-release-plugin] prepare release maven-3.8.4 https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359;>19c3b91 [MNG-7331] Upgrade Jansi to 2.4.0 https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c;>5c36bf5 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251 https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601;>fb5f3f5 [MNG-7270] Switch to shell alternative to which https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55;>b6186e2 Remove swap file https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4;>21e597e [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739;>ff8e977 [maven-release-plugin] prepare release maven-3.8.3 https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060;>0a6bbb8 [MNG-7235] Speed improvements when calculating the sorted project graph https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0;>8882a9c [MNG-7164] Add constructor MojoExecutionException(Throwable) https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3;>ab54d17 [MNG-7253] Display relocation message defined in model Additional commits viewable in https://github.com/apache/maven/compare/maven-3.1.0...maven-3.8.4;>compare view Updates `maven-core` from 3.1.0 to 3.8.4 Commits https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537;>9b656c7 [maven-release-plugin] prepare release maven-3.8.4 https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359;>19c3b91 [MNG-7331] Upgrade Jansi to 2.4.0 https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c;>5c36bf5 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251 https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601;>fb5f3f5 [MNG-7270] Switch to shell alternative to which https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55;>b6186e2 Remove swap file https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4;>21e597e [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739;>ff8e977 [maven-release-plugin] prepare release maven-3.8.3 https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060;>0a6bbb8 [MNG-7235] Speed improvements when calculating the sorted project graph https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0;>8882a9c [MNG-7164] Add constructor MojoExecutionException(Throwable) https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3;>ab54d17 [MNG-7253] Display relocation message defined in model Additional commits viewable in https://github.com/apache/maven/compare/maven-3.1.0...maven-3.8.4;>compare view Updates `maven-model` from 3.1.0 to 3.8.4 Commits https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537;>9b656c7 [maven-release-plugin] prepare release maven-3.8.4 https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359;>19c3b91 [MNG-7331] Upgrade Jansi to 2.4.0 https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c;>5c36bf5 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251 https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601;>fb5f3f5 [MNG-7270] Switch to shell alternative to which https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55;>b6186e2 Remove swap file https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4;>21e597e [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739;>ff8e977 [maven-release-plugin] prepare release maven-3.8.3 https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060;>0a6bbb8 [MNG-7235] Speed improvements when calculating the sorted project graph https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0;>8882a9c [MNG-7164] Add constructor MojoExecutionException(Throwable) https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3;>ab54d17 [MNG-7253] Display relocation message defined in model Additional commits viewable in
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #406: Bump junit-jupiter-engine from 5.3.2 to 5.8.2
dependabot[bot] opened a new pull request #406: URL: https://github.com/apache/maven-surefire/pull/406 Bumps [junit-jupiter-engine](https://github.com/junit-team/junit5) from 5.3.2 to 5.8.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>junit-jupiter-engine's releases. JUnit 5.8.2 = Platform 1.8.2 + Jupiter 5.8.2 + Vintage 5.8.2 See http://junit.org/junit5/docs/5.8.2/release-notes/;>Release Notes. JUnit 5.8.1 = Platform 1.8.1 + Jupiter 5.8.1 + Vintage 5.8.1 See http://junit.org/junit5/docs/5.8.1/release-notes/;>Release Notes. JUnit 5.8.0 = Platform 1.8.0 + Jupiter 5.8.0 + Vintage 5.8.0 See http://junit.org/junit5/docs/5.8.0/release-notes/;>Release Notes. JUnit 5.8.0-RC1 = Platform 1.8.0-RC1 + Jupiter 5.8.0-RC1 + Vintage 5.8.0-RC1 See http://junit.org/junit5/docs/5.8.0-RC1/release-notes/;>Release Notes. JUnit 5.8.0-M1 = Platform 1.8.0-M1 + Jupiter 5.8.0-M1 + Vintage 5.8.0-M1 See http://junit.org/junit5/docs/5.8.0-M1/release-notes/;>Release Notes. JUnit 5.7.2 = Platform 1.7.2 + Jupiter 5.7.2 + Vintage 5.7.2 See http://junit.org/junit5/docs/5.7.2/release-notes/;>Release Notes. JUnit 5.7.1 = Platform 1.7.1 + Jupiter 5.7.1 + Vintage 5.7.1 See http://junit.org/junit5/docs/5.7.1/release-notes/;>Release Notes. JUnit 5.7.0 = Platform 1.7.0 + Jupiter 5.7.0 + Vintage 5.7.0 See http://junit.org/junit5/docs/5.7.0/release-notes/;>Release Notes. JUnit 5.7.0-RC1 = Platform 1.7.0-RC1 + Jupiter 5.7.0-RC1 + Vintage 5.7.0-RC1 See http://junit.org/junit5/docs/5.7.0-RC1/release-notes/;>Release Notes. JUnit 5.7.0-M1 = Platform 1.7.0-M1 + Jupiter 5.7.0-M1 + Vintage 5.7.0-M1 See http://junit.org/junit5/docs/5.7.0-M1/release-notes/;>Release Notes. JUnit 5.6.3 = Platform 1.6.3 + Jupiter 5.6.3 + Vintage 5.6.3 See http://junit.org/junit5/docs/5.6.3/release-notes/;>Release Notes. JUnit 5.6.2 = Platform 1.6.2 + Jupiter 5.6.2 + Vintage 5.6.2 See http://junit.org/junit5/docs/5.6.2/release-notes/;>Release Notes. JUnit 5.6.1 = Platform 1.6.1 + Jupiter 5.6.1 + Vintage 5.6.1 ... (truncated) Commits https://github.com/junit-team/junit5/commit/f58cd419755846f1476e8d15783438de8d7aede4;>f58cd41 Release 5.8.2 https://github.com/junit-team/junit5/commit/893617c8bcfd50a9c22023177c80db9973e36d8f;>893617c Fix Javadoc of DEFAULT_DISCOVERY_LISTENER_CONFIGURATION_PROPERTY_NAME https://github.com/junit-team/junit5/commit/3d75f99bf78fa386c17a52009670d6bcfa3f3168;>3d75f99 Use Gradle because to document junit-platform-launcher dependency https://github.com/junit-team/junit5/commit/4ef6e70989fb9ad9efef7bb45996854d876503b1;>4ef6e70 Support CSV headers in display names in parameterized tests https://github.com/junit-team/junit5/commit/69aed70d38b2b2ca3bb51b7a4f29c909573c0544;>69aed70 Polish Overview section of User Guide https://github.com/junit-team/junit5/commit/4181b9c05d5ac8ea056e3c06d35503f99403157a;>4181b9c Make quote character in https://github.com/CsvFileSource;>@CsvFileSource configurable https://github.com/junit-team/junit5/commit/e27058ec5c283bce2f495d0d0b4d328abc16d6e1;>e27058e Stop publishing to scans.gradle.com for PR builds https://github.com/junit-team/junit5/commit/d455b9894ae508d5aa859b7b8ae42debaadb8137;>d455b98 Always update snapshots https://github.com/junit-team/junit5/commit/938ab00d4db1f5ef074856907536bdec5ec414a1;>938ab00 Increase tool timeout to reduce flakiness https://github.com/junit-team/junit5/commit/cd257bd863cc63d32adbefe0c596b881eeabe099;>cd257bd Use longer timeouts to stabilize flaky tests Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.3.2...r5.8.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #405: Bump javassist from 3.22.0-GA to 3.28.0-GA
dependabot[bot] opened a new pull request #405: URL: https://github.com/apache/maven-surefire/pull/405 Bumps [javassist](https://github.com/jboss-javassist/javassist) from 3.22.0-GA to 3.28.0-GA. Release notes Sourced from https://github.com/jboss-javassist/javassist/releases;>javassist's releases. Javassist 3.28.0-GA No release notes provided. Javassist 3.27.0-GA No release notes provided. Javassist 3.26.0-GA No release notes provided. Javassist 3.25.0-GA No release notes provided. Javassist 3.24.1-GA with a bug fix of javassist.util.proxy. Javassist 3.24.0-RC Release candidate. Java 11 supports. Javassist 3.24.0-GA with Java 11 supports. Javassist 3.23.1-GA No release notes provided. Javassist 3.23.0-GA No release notes provided. Commits See full diff in https://github.com/jboss-javassist/javassist/commits;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-resolver] caiwei-ebay commented on pull request #136: [MRESOLVER-228] skip & reconcile
caiwei-ebay commented on pull request #136: URL: https://github.com/apache/maven-resolver/pull/136#issuecomment-987514827 Basically the strategy of this approach is: - Skip more nodes - Reconcile least nodes There is one more case that the node can be skipped reconciling: the node's parents includes any conflict losers. In such case, maven won't pick up such node at all, so it is safe to skip reconciling. Also renamed a few variables, added a few comments to make it easy to understand. Here is the commit: https://github.com/apache/maven-resolver/pull/136/commits/78e5e98b6430ba71c982cbc9bce6f603cc2cb286 We have recertified this code changes by running large numbers of applications in our company by comparing dependency:tree and dependency:list result. Now most of the applications skipped quite a few nodes and just need to reconcile 0 nodes. And if there is version conflicts, this approach just needs to reconcile least nodes. -- 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-resources-plugin] slachiewicz closed pull request #8: Bump org.eclipse.sisu.plexus from 0.0.0.M2a to 0.3.5
slachiewicz closed pull request #8: URL: https://github.com/apache/maven-resources-plugin/pull/8 -- 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-resources-plugin] dependabot[bot] commented on pull request #8: Bump org.eclipse.sisu.plexus from 0.0.0.M2a to 0.3.5
dependabot[bot] commented on pull request #8: URL: https://github.com/apache/maven-resources-plugin/pull/8#issuecomment-987486001 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-script-interpreter] dependabot[bot] commented on pull request #46: Bump maven-enforcer-plugin from 3.0.0-M3 to 3.0.0
dependabot[bot] commented on pull request #46: URL: https://github.com/apache/maven-script-interpreter/pull/46#issuecomment-987478984 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-script-interpreter] slachiewicz closed pull request #46: Bump maven-enforcer-plugin from 3.0.0-M3 to 3.0.0
slachiewicz closed pull request #46: URL: https://github.com/apache/maven-script-interpreter/pull/46 -- 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-script-interpreter] slachiewicz merged pull request #45: Bump slf4j.version from 1.7.30 to 1.7.32
slachiewicz merged pull request #45: URL: https://github.com/apache/maven-script-interpreter/pull/45 -- 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-doxia-converter] slachiewicz merged pull request #19: Bump icu4j from 69.1 to 70.1
slachiewicz merged pull request #19: URL: https://github.com/apache/maven-doxia-converter/pull/19 -- 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] [Closed] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MRESOURCES-237.
---
Resolution: Fixed
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MRESOURCES-265) Resource copying not using specified encoding
[ https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MRESOURCES-265. --- Resolution: Fixed > Resource copying not using specified encoding > - > > Key: MRESOURCES-265 > URL: https://issues.apache.org/jira/browse/MRESOURCES-265 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 3.2.0 > Environment: Linux, CentOS 7 > Jenkins 2.251 > Jenkins Maven Integration plugin 3.1.2 > Java 1.8 >Reporter: Duncan Kinnear >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > > Overnight our Jenkins builds stopped working. On investigation we found that > maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) > and today it was using 3.2.0. > The stacktrace produced by adding the "e" switch to the maven command line > had the following root cause (truncated for brevity):- > Caused by: java.nio.charset.MalformedInputException: Input length = 1 > at java.nio.charset.CoderResult.throwException (CoderResult.java:281) > at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339) > at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178) > at java.io.InputStreamReader.read (InputStreamReader.java:184) > at java.io.BufferedReader.read1 (BufferedReader.java:210) > at java.io.BufferedReader.read (BufferedReader.java:286) > at java.io.BufferedReader.fill (BufferedReader.java:161) > at java.io.BufferedReader.read (BufferedReader.java:182) > at org.apache.maven.shared.filtering.BoundedReader.read > (BoundedReader.java:85) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197) > at java.io.Reader.read (Reader.java:140) > at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199) > > After a google search told us this was an encoding issue, we added the > following to the maven command line, but this made no difference: > -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8 > > The maven build log has these info messsage just before the error: > [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks — > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Using 'UTF-8' encoding to copy filtered properties files. > [INFO] Copying 430 resources > We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the > projects POM 'pluginManagement' section. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MRESOURCES-275) valid location for directory parameter is always required
[
https://issues.apache.org/jira/browse/MRESOURCES-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MRESOURCES-275.
---
Resolution: Fixed
Done in
[7cbd412b4101668567188992de7b9947af6cf237|https://gitbox.apache.org/repos/asf?p=maven-filtering.git;a=commit;h=7cbd412b4101668567188992de7b9947af6cf237]
> valid location for directory parameter is always required
> -
>
> Key: MRESOURCES-275
> URL: https://issues.apache.org/jira/browse/MRESOURCES-275
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Delany
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.3.0
>
>
> Suppose I remove src/main/resources.
> When I build, default-resources execution logs "skip non existing
> resourceDirectory"
> But when i configure my own execution like so, it throws a null pointer
> exception:
> {code:java}
>
> maven-resources-plugin
> 3.2.0
>
>
> readme-resources
> process-resources
>
> resources
>
>
>
>
>
>
>
>
>
>
> {code}
> Its a bit confusing because the documentation for the goal makes no mention
> of a directory parameter, and its obviously a required parameter, and it must
> be a valid location.
> [https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MRESOURCES-269) Symlinks cause copying resources to fail
[ https://issues.apache.org/jira/browse/MRESOURCES-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MRESOURCES-269. --- Resolution: Fixed > Symlinks cause copying resources to fail > > > Key: MRESOURCES-269 > URL: https://issues.apache.org/jira/browse/MRESOURCES-269 > Project: Maven Resources Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: jks >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > Attachments: MRESOURCES-269.tar.gz, log.txt > > > Copying a symlink fails if the target does not exist. If the symlink is > relative the order that the resources are copied matter. If A points to B > but A is copied before B the copying of A will fail with a non-helpful > message "Failed to execute goal ... on project xxx: ". > > This started failing for me on 3.2.0 (and works on 3.1.0) but that might be > because somewhere in the dependencies the traversal order changed somehow. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MRESOURCES-273) Filtering of Maven properties with long names is not working after transition from 2.6 to 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MRESOURCES-273. --- Resolution: Fixed Done in [680717c7d3c5a1f3f7891b923cfa8e0a55eb03d3|https://gitbox.apache.org/repos/asf?p=maven-filtering.git;a=commit;h=680717c7d3c5a1f3f7891b923cfa8e0a55eb03d3] > Filtering of Maven properties with long names is not working after transition > from 2.6 to 3.2.0 > --- > > Key: MRESOURCES-273 > URL: https://issues.apache.org/jira/browse/MRESOURCES-273 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.2.0 >Reporter: Elias Balasis >Assignee: Sylwester Lachiewicz >Priority: Critical > Fix For: 3.3.0 > > > In my team, part of a large global organization, we have upgraded from 2.6 to > 3.2.0 > but only to discover that 3.2.0 is not filtering Maven properties with long > names anymore. > The particular Maven property which wasn't filtered is 148 characters long. > This has never been a problem with 2.6 though. > It is implied that a breaking change has been made after 2.6 which now > prevents us from upgrading. > We are temporarily reverting to 2.6 but only temporarily. > Equally, the cost of reducing the length of the associated Maven properties > is not affordable and we will not apply such a workaround. > Please revert the broken functionality. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOURCES-273) Filtering of Maven properties with long names is not working after transition from 2.6 to 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MRESOURCES-273: Fix Version/s: 3.3.0 (was: waiting-for-feedback) > Filtering of Maven properties with long names is not working after transition > from 2.6 to 3.2.0 > --- > > Key: MRESOURCES-273 > URL: https://issues.apache.org/jira/browse/MRESOURCES-273 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.2.0 >Reporter: Elias Balasis >Priority: Critical > Fix For: 3.3.0 > > > In my team, part of a large global organization, we have upgraded from 2.6 to > 3.2.0 > but only to discover that 3.2.0 is not filtering Maven properties with long > names anymore. > The particular Maven property which wasn't filtered is 148 characters long. > This has never been a problem with 2.6 though. > It is implied that a breaking change has been made after 2.6 which now > prevents us from upgrading. > We are temporarily reverting to 2.6 but only temporarily. > Equally, the cost of reducing the length of the associated Maven properties > is not affordable and we will not apply such a workaround. > Please revert the broken functionality. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRESOURCES-273) Filtering of Maven properties with long names is not working after transition from 2.6 to 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MRESOURCES-273: --- Assignee: Sylwester Lachiewicz > Filtering of Maven properties with long names is not working after transition > from 2.6 to 3.2.0 > --- > > Key: MRESOURCES-273 > URL: https://issues.apache.org/jira/browse/MRESOURCES-273 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 3.2.0 >Reporter: Elias Balasis >Assignee: Sylwester Lachiewicz >Priority: Critical > Fix For: 3.3.0 > > > In my team, part of a large global organization, we have upgraded from 2.6 to > 3.2.0 > but only to discover that 3.2.0 is not filtering Maven properties with long > names anymore. > The particular Maven property which wasn't filtered is 148 characters long. > This has never been a problem with 2.6 though. > It is implied that a breaking change has been made after 2.6 which now > prevents us from upgrading. > We are temporarily reverting to 2.6 but only temporarily. > Equally, the cost of reducing the length of the associated Maven properties > is not affordable and we will not apply such a workaround. > Please revert the broken functionality. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-6523) System Dependencies Deprecation
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454290#comment-17454290 ] Leonardo Maffei da Silva commented on MNG-6523: --- Of course I would like to not have to do it; however, I have no power to change it by myself: it is simply above me. About what you would do or not to you employer, honestly I don't care. However, I would like to solve the demands *my client* imposes to me. I am simply providing a reasonable use case: I must use, or rather access, files that would take *so long* to get access to unless I upload the files by myself and let, in that case, _maven_ use it. It is also specially useful to prevent failing build due to broken links. > System Dependencies Deprecation > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > Fix For: wontfix-candidate > > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7309) Remove redundant MojoDescriptor parameterMap
[ https://issues.apache.org/jira/browse/MNG-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7309: --- Description: The class maven-plugin-api:MojoDescriptor contains a list of parameters and a map of parameters: https://maven.apache.org/ref/3.8.4/maven-plugin-api/xref/org/apache/maven/plugin/descriptor/MojoDescriptor.html#L58 The code is broken, in a way that the two – that should contain same things – may end up not containing same things. Note: not that anything uses it in such way, as instances of this class are loaded up from descriptor, but still, it may easily lead to confusion. was: The class maven-plugin-api:MojoDescritor contains a list of parameters and a map of parameters. The code is broken, in a way that the two – that should contain same things – may end up not containing same things. Note: not that anything uses it in such way, as instances of this class are loaded up from descriptor, but still, it may easily lead to confusion. > Remove redundant MojoDescriptor parameterMap > > > Key: MNG-7309 > URL: https://issues.apache.org/jira/browse/MNG-7309 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 4.0.x-candidate, 4.0.0-alpha-1 > > > The class maven-plugin-api:MojoDescriptor contains a list of parameters and a > map of parameters: > https://maven.apache.org/ref/3.8.4/maven-plugin-api/xref/org/apache/maven/plugin/descriptor/MojoDescriptor.html#L58 > The code is broken, in a way that the two – that should contain same things – > may end up not containing same things. > Note: not that anything uses it in such way, as instances of this class are > loaded up from descriptor, but still, it may easily lead to confusion. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MNG-7353) add support for "mvn plugin:version:goal"
Herve Boutemy created MNG-7353:
--
Summary: add support for "mvn plugin:version:goal"
Key: MNG-7353
URL: https://issues.apache.org/jira/browse/MNG-7353
Project: Maven
Issue Type: New Feature
Components: Command Line
Affects Versions: 3.8.4
Reporter: Herve Boutemy
Fix For: 4.0.x-candidate
currently, we can run a simplified form {noformat}mvn wrapper:wrapper{noformat}
but if we want to specify a version, we need to switch to full form:
{noformat}mvn
org.apache.maven.plugins:maven-wrapper-plugin:3.1.0-SNAPSHOT:wrapper{noformat}
it would be nice to be able to write {noformat}mvn
wrapper:3.1.0-SNAPSHOT:wrapper{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MWRAPPER-28) add mvnwDebug* scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454254#comment-17454254 ] Herve Boutemy edited comment on MWRAPPER-28 at 12/6/21, 11:07 PM: -- done in https://github.com/apache/maven-wrapper/commit/96d30b0b96a01e7f60098e963663cea163c4d794 and https://github.com/apache/maven-wrapper/commit/e10ec821fc0e45105ec2e64d2087497bbc8fd145 was (Author: hboutemy): done in https://github.com/apache/maven-wrapper/commit/96d30b0b96a01e7f60098e963663cea163c4d794 > add mvnwDebug* scripts > -- > > Key: MWRAPPER-28 > URL: https://issues.apache.org/jira/browse/MWRAPPER-28 > Project: Maven Wrapper > Issue Type: New Feature > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-27) rework mvnw* scripts to better match mvn* from Maven 3.8
[ https://issues.apache.org/jira/browse/MWRAPPER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-27: -- Issue Type: Improvement (was: Task) > rework mvnw* scripts to better match mvn* from Maven 3.8 > > > Key: MWRAPPER-27 > URL: https://issues.apache.org/jira/browse/MWRAPPER-27 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > there has been much improvement done in recent Maven versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7020) Remove Maven 2 WagonExcluder backward compat code
[ https://issues.apache.org/jira/browse/MNG-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7020: --- Description: Maven includes a Wagon Excluder when Maven 2 artifacts are used with Wagon 1.0.x: https://maven.apache.org/ref/3.8.4/maven-core/xref/org/apache/maven/plugin/internal/WagonExcluder.html This is ancient Maven 2 backward compat. Let's remove it and hope everyone has moved on to Maven 3.x artifacts and Wagon 3.x. was: Maven includes a Wagon Excluder when Maven 2 artifacts are use with Wagon 1.0.x: https://maven.apache.org/ref/3.8.4/maven-core/xref/org/apache/maven/plugin/internal/WagonExcluder.html This is ancient Maven 2 backward compat. Let's remove it and hope everyone has moved on to Maven 3.x artifacts and Wagon 3.x. > Remove Maven 2 WagonExcluder backward compat code > - > > Key: MNG-7020 > URL: https://issues.apache.org/jira/browse/MNG-7020 > Project: Maven > Issue Type: Task > Components: Class Loading, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > Attachments: mng5669-log_post-mng7020.txt, mng5669-log_pre-mng7020.txt > > > Maven includes a Wagon Excluder when Maven 2 artifacts are used with Wagon > 1.0.x: > https://maven.apache.org/ref/3.8.4/maven-core/xref/org/apache/maven/plugin/internal/WagonExcluder.html > This is ancient Maven 2 backward compat. > Let's remove it and hope everyone has moved on to Maven 3.x artifacts and > Wagon 3.x. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7020) Remove Maven 2 WagonExcluder backward compat code
[ https://issues.apache.org/jira/browse/MNG-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7020: --- Description: Maven includes a Wagon Excluder when Maven 2 artifacts are use with Wagon 1.0.x: https://maven.apache.org/ref/3.8.4/maven-core/xref/org/apache/maven/plugin/internal/WagonExcluder.html This is ancient Maven 2 backward compat. Let's remove it and hope everyone has moved on to Maven 3.x artifacts and Wagon 3.x. was:Maven includes a Wagon Excluder when Maven 2 artifacts are use with Wagon 1.0.x. This is ancient Maven 2 backward compat. Let's remove it and hope everyone has moved on to Maven 3.x artifacts and Wagon 3.x. > Remove Maven 2 WagonExcluder backward compat code > - > > Key: MNG-7020 > URL: https://issues.apache.org/jira/browse/MNG-7020 > Project: Maven > Issue Type: Task > Components: Class Loading, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > Attachments: mng5669-log_post-mng7020.txt, mng5669-log_pre-mng7020.txt > > > Maven includes a Wagon Excluder when Maven 2 artifacts are use with Wagon > 1.0.x: > https://maven.apache.org/ref/3.8.4/maven-core/xref/org/apache/maven/plugin/internal/WagonExcluder.html > This is ancient Maven 2 backward compat. > Let's remove it and hope everyone has moved on to Maven 3.x artifacts and > Wagon 3.x. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request #176: Bump doxiaVersion from 1.10 to 1.11.1
dependabot[bot] opened a new pull request #176: URL: https://github.com/apache/maven-dependency-plugin/pull/176 Bumps `doxiaVersion` from 1.10 to 1.11.1. Updates `doxia-sink-api` from 1.10 to 1.11.1 Commits https://github.com/apache/maven-doxia/commit/84c3babdeeadafb546985e00353c1dc71c770344;>84c3bab [maven-release-plugin] prepare release doxia-1.11.1 https://github.com/apache/maven-doxia/commit/88fdae390aef87d540037133177be5f85670;>88fda88 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-doxia/commit/ea9e1c6a54165daebe043067cfd0a72cba7ad91b;>ea9e1c6 [maven-release-plugin] prepare release doxia-1.11 https://github.com/apache/maven-doxia/commit/a5145159ec5d8c993612560fb2bb2ef10b3815ab;>a514515 [DOXIA-629] Deprecate SwfMacro https://github.com/apache/maven-doxia/commit/80e02c5cbf0ada390789af21235d41168ac8874a;>80e02c5 [DOXIA-628] Deprecate SsiMacro https://github.com/apache/maven-doxia/commit/21b3b82f9d74cd329258a1b137048a2205d169e6;>21b3b82 [DOXIA-620] Deprecate Doxia Logging API in favor of SLF4J https://github.com/apache/maven-doxia/commit/05d719a105d1504fe78b72cc204185968c40ee20;>05d719a [DOXIA-627] Deprecate doxia-module-twiki https://github.com/apache/maven-doxia/commit/ca9af5a8ef8298a8f21d6c5de2a3ccc53509b5b8;>ca9af5a [DOXIA-626] Deprecate doxia-module-rtf https://github.com/apache/maven-doxia/commit/37cfeda9607a3aae177171e801c180b94f733ced;>37cfeda [DOXIA-625] Deprecate doxia-module-latex https://github.com/apache/maven-doxia/commit/4df28158c8a291228b30a1bbb2506b7421a6a9fd;>4df2815 [DOXIA-624] Deprecate doxia-module-itext Additional commits viewable in https://github.com/apache/maven-doxia/compare/doxia-1.10...doxia-1.11.1;>compare view Updates `doxia-core` from 1.10 to 1.11.1 Commits https://github.com/apache/maven-doxia/commit/84c3babdeeadafb546985e00353c1dc71c770344;>84c3bab [maven-release-plugin] prepare release doxia-1.11.1 https://github.com/apache/maven-doxia/commit/88fdae390aef87d540037133177be5f85670;>88fda88 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-doxia/commit/ea9e1c6a54165daebe043067cfd0a72cba7ad91b;>ea9e1c6 [maven-release-plugin] prepare release doxia-1.11 https://github.com/apache/maven-doxia/commit/a5145159ec5d8c993612560fb2bb2ef10b3815ab;>a514515 [DOXIA-629] Deprecate SwfMacro https://github.com/apache/maven-doxia/commit/80e02c5cbf0ada390789af21235d41168ac8874a;>80e02c5 [DOXIA-628] Deprecate SsiMacro https://github.com/apache/maven-doxia/commit/21b3b82f9d74cd329258a1b137048a2205d169e6;>21b3b82 [DOXIA-620] Deprecate Doxia Logging API in favor of SLF4J https://github.com/apache/maven-doxia/commit/05d719a105d1504fe78b72cc204185968c40ee20;>05d719a [DOXIA-627] Deprecate doxia-module-twiki https://github.com/apache/maven-doxia/commit/ca9af5a8ef8298a8f21d6c5de2a3ccc53509b5b8;>ca9af5a [DOXIA-626] Deprecate doxia-module-rtf https://github.com/apache/maven-doxia/commit/37cfeda9607a3aae177171e801c180b94f733ced;>37cfeda [DOXIA-625] Deprecate doxia-module-latex https://github.com/apache/maven-doxia/commit/4df28158c8a291228b30a1bbb2506b7421a6a9fd;>4df2815 [DOXIA-624] Deprecate doxia-module-itext Additional commits viewable in https://github.com/apache/maven-doxia/compare/doxia-1.10...doxia-1.11.1;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated
[jira] [Closed] (MWRAPPER-28) add mvnwDebug* scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-28. - Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-wrapper/commit/96d30b0b96a01e7f60098e963663cea163c4d794 > add mvnwDebug* scripts > -- > > Key: MWRAPPER-28 > URL: https://issues.apache.org/jira/browse/MWRAPPER-28 > Project: Maven Wrapper > Issue Type: New Feature > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MWRAPPER-28) add mvnwDebug* scripts
Herve Boutemy created MWRAPPER-28: - Summary: add mvnwDebug* scripts Key: MWRAPPER-28 URL: https://issues.apache.org/jira/browse/MWRAPPER-28 Project: Maven Wrapper Issue Type: New Feature Components: Maven Wrapper Scripts Affects Versions: 0.5.6 Reporter: Herve Boutemy Fix For: 3.1.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MWRAPPER-27) rework mvnw* scripts to better match mvn* from Maven 3.8
[ https://issues.apache.org/jira/browse/MWRAPPER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-27. - Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-wrapper/commit/ec80652844e69675284c9416365910a20b2a0c9d > rework mvnw* scripts to better match mvn* from Maven 3.8 > > > Key: MWRAPPER-27 > URL: https://issues.apache.org/jira/browse/MWRAPPER-27 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > there has been much improvement done in recent Maven versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MWRAPPER-27) rework mvnw* scripts to better match mvn* from Maven 3.8
Herve Boutemy created MWRAPPER-27: - Summary: rework mvnw* scripts to better match mvn* from Maven 3.8 Key: MWRAPPER-27 URL: https://issues.apache.org/jira/browse/MWRAPPER-27 Project: Maven Wrapper Issue Type: Task Components: Maven Wrapper Scripts Affects Versions: 0.5.6 Reporter: Herve Boutemy Fix For: 3.1.0 there has been much improvement done in recent Maven versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MWRAPPER-26) install binary by default to match older user experience
[ https://issues.apache.org/jira/browse/MWRAPPER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-26. - Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-wrapper/commit/3ddb1995b5588eaa75a4ef57b5e06b11f615d62f > install binary by default to match older user experience > > > Key: MWRAPPER-26 > URL: https://issues.apache.org/jira/browse/MWRAPPER-26 > Project: Maven Wrapper > Issue Type: Wish > Components: Maven Wrapper Plugin >Affects Versions: 3.0.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > maven-wrapper-plugin has been written to install script distribution by > default, which leads the user to download maven-wrapper.jar when launching > mvnw > to match previous Takari plugin behaviour, switching to binray distribution > will avoid that: user wll decide to add maven-wrapper.jar to source control > or not -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-22) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MWRAPPER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-22: -- Component/s: Maven Wrapper Scripts > maven-wrapper on windows > > > Key: MWRAPPER-22 > URL: https://issues.apache.org/jira/browse/MWRAPPER-22 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-23) in maven-wrapper, maven user home is not consistent with maven core
[ https://issues.apache.org/jira/browse/MWRAPPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-23: -- Component/s: Maven Wrapper Jar > in maven-wrapper, maven user home is not consistent with maven core > --- > > Key: MWRAPPER-23 > URL: https://issues.apache.org/jira/browse/MWRAPPER-23 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Jar >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > > New maven wrapper guesses the maven user home location via system props, > system envs > and at last the default location (~/.m2). This guessing order is the > convention of the gradle wrapper. > For maven, user home has a fixed location, i.e. ~/.m2, described > [here|https://maven.apache.org/settings.html#Settings_Details] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-13) Unclear how to use maven-wrapper-plugin
[
https://issues.apache.org/jira/browse/MWRAPPER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-13:
--
Component/s: Maven Wrapper Plugin
> Unclear how to use maven-wrapper-plugin
> ---
>
> Key: MWRAPPER-13
> URL: https://issues.apache.org/jira/browse/MWRAPPER-13
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Reporter: Austin Doupnik
>Priority: Major
>
> I have heavily used the takari plugin in the past and am comparing to that.
> The takari plugin documentation is very clear and easy to follow, simply run
> {code:bash}
> mvn -N io.takari:maven:0.7.7:wrapper
> {code}
> I am attempting to follow what is documented
> [here|http://maven.apache.org/plugins/maven-wrapper-plugin/usage.html], but
> running into a number of problems.
> h2. Setup
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn archetype:generate
> -DartifactId=example -DgroupId=example -B
>
> $ cd example
> {code}
> h2. Following the documentation
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn wrapper
>
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< example:example
> >---
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.093 s
> [INFO] Finished at: 2021-05-02T13:52:38-07:00
> [INFO]
>
> [ERROR] Unknown lifecycle phase "wrapper". You must specify a valid lifecycle
> phase or a goal in the format : or
> :[:]:. Available
> lifecycle phases are: validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy, pre-clean,
> clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/LifecyclePhaseNotFoundException
> {code}
> h2. Trying something else
> {code:bash}
> $ ~/Applications/apache-maven-3.8.1/bin/mvn wrapper:wrapper
>
> [INFO] Scanning for projects...
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.4/maven-jar-plugin-2.4.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.4/maven-jar-plugin-2.4.jar
> (34 kB at 76 kB/s)
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
> (43 kB at 682 kB/s)
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.12.4.jar
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.12.4/maven-surefire-plugin-2.12.4.jar
> (30 kB at 725 kB/s)
> [INFO]
> [INFO] --< example:example
> >---
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-wrapper-plugin:3.0.1:wrapper (default-cli) @ example ---
> [WARNING] The POM for org.apache.maven:apache-maven-wrapper:zip:script:3.8.1
> is missing, no dependency information available
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.622 s
> [INFO] Finished at: 2021-05-02T13:54:08-07:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper
[jira] [Updated] (MWRAPPER-21) Arbitrary file write during archive extraction ("Zip Slip") in wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-21:
--
Component/s: Maven Wrapper Jar
> Arbitrary file write during archive extraction ("Zip Slip") in wrapper
> --
>
> Key: MWRAPPER-21
> URL: https://issues.apache.org/jira/browse/MWRAPPER-21
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 0.5.6
>Reporter: Sylwester Lachiewicz
>Assignee: Robert Scholte
>Priority: Major
>
> In Maven Wrapper Installer
> [https://github.com/apache/maven/blob/ef8c95eb397651e10f677763dfcd9c8cea7c27b0/maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java]
>
> {code:java}
> ZipEntry entry = entries.nextElement();
> if ( entry.isDirectory() )
> {
> continue;
> }
> Path targetFile = dest.resolve( entry.getName() );
> // Unsanitized archive entry, which may contain '..', is used in a file
> system operation.
> // prevent Zip Slip
> if ( targetFile.startsWith( dest ) )
> {
>Files.createDirectories( targetFile.getParent() );
>Files.copy( zipFile.getInputStream( entry ), targetFile );
> }
> {code}
>
> Found via LGTM.com scan
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MWRAPPER-16) update mvnw scripts to launch target Maven mvn scripts, to enforce consistency
[ https://issues.apache.org/jira/browse/MWRAPPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-16: -- Component/s: Maven Wrapper Scripts > update mvnw scripts to launch target Maven mvn scripts, to enforce consistency > -- > > Key: MWRAPPER-16 > URL: https://issues.apache.org/jira/browse/MWRAPPER-16 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6, 3.1.0 >Reporter: Herve Boutemy >Priority: Major > > currently, wrapper scripts copied to user project mimic Maven scripts (search > .mvn, and so on), then launch wrapper.jar: at the end, wrapper.jar calls > installed Maven distribution Classworlds bootstrap to run Maven Java code > this may cause a discrepency between features supported by mvnw script vs > what would have been done by installed Maven mvn scripts > for example, when/if [https://github.com/apache/maven/pull/602] is done > To enforce consistency, mvnw should launch installed Maven mvn script at the > end, and let it do its full work as if it had been launched -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-18) using MVNW_REPOURL, wrong Maven version is downloaded
[
https://issues.apache.org/jira/browse/MWRAPPER-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-18:
--
Component/s: Maven Wrapper Jar
> using MVNW_REPOURL, wrong Maven version is downloaded
> -
>
> Key: MWRAPPER-18
> URL: https://issues.apache.org/jira/browse/MWRAPPER-18
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 0.5.6
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> I have configured my project to use Maven 3.8.1: it perfectly works when not
> using MVNW_REPOURL
> But if I configure my local repository with MVNW_REPOURL, the wrong Maven
> version is downloaded and installed (in the directory of Maven 3.8.1)
> {noformat}$
> MVNW_REPOURL=http://localhost:8081/nexus/content/repositories/central
> MVNW_VERBOSE=true ./mvnw -v
> Found .mvn/wrapper/maven-wrapper.jar
> /home/herve/tmp/maven-wrapper
> Takari Maven Wrapper 0.5.6
> Detected MVNW_REPOURL environment variable
> http://localhost:8081/nexus/content/repositories/central
> Downloading Maven binary from
> http://localhost:8081/nexus/content/repositories/central/org/apache/maven/apache-maven/3.6.3/apache-maven-3.6.3-bin.zip
> Downloading
> http://localhost:8081/nexus/content/repositories/central/org/apache/maven/apache-maven/3.6.3/apache-maven-3.6.3-bin.zip
> .
> .
> Unzipping
> /home/herve/.m2/wrapper/dists/apache-maven-3.8.1-bin/2l5mhf2pq2clrde7f7qp1rdt5m/apache-maven-3.8.1-bin.zip
> to
> /home/herve/.m2/wrapper/dists/apache-maven-3.8.1-bin/2l5mhf2pq2clrde7f7qp1rdt5m
> Set executable permissions for:
> /home/herve/.m2/wrapper/dists/apache-maven-3.8.1-bin/2l5mhf2pq2clrde7f7qp1rdt5m/apache-maven-3.6.3/bin/mvn
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home:
> /home/herve/.m2/wrapper/dists/apache-maven-3.8.1-bin/2l5mhf2pq2clrde7f7qp1rdt5m/apache-maven-3.6.3
> Java version: 1.8.0_202, vendor: AdoptOpenJdk, runtime:
> /home/herve/local/.jdk/jdk8u202-b08/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-91-generic", arch: "amd64", family: "unix"
> {noformat}
> as seen in the output, Maven 3.6.3 is downloaded then installed in
> /home/herve/.m2/wrapper/dists/apache-maven-3.8.1-bin
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MWRAPPER-20) Maven Wrapper creates empty file when it fails behind proxy 407
[
https://issues.apache.org/jira/browse/MWRAPPER-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-20:
--
Component/s: Maven Wrapper Scripts
> Maven Wrapper creates empty file when it fails behind proxy 407
> ---
>
> Key: MWRAPPER-20
> URL: https://issues.apache.org/jira/browse/MWRAPPER-20
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 0.5.6
> Environment: Proxy with authentication, http_proxy set without
> authentication
>Reporter: Benjamin Marwell
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> Hi,
>
> when executing `{color:#0747a6}{{./mvnw}}{color}` behind a proxy and the
> proxy authentication does not succeed, {color:#0747a6}{{wget}}{color} will
> still create an empty file {color:#0747a6}{{.mvn/maven-wrapper.jar}}{color}.
>
> Subsequent calls to {color:#0747a6}{{./mvnw}}{color} will see the existing
> (but empty) file and maven-wrapper will not attempt to redownload it. There
> is no clue what is going wrong, the only message is "Main class not found".
>
> Suggested fixes:
> * Check curl/wget return codes and delete the files if they got touched.
> * Even if curl/wget were not invoked, delete empty files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MWRAPPER-24) mvnw calls which(1) which is an external command
[ https://issues.apache.org/jira/browse/MWRAPPER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-24: -- Component/s: Maven Wrapper Scripts > mvnw calls which(1) which is an external command > > > Key: MWRAPPER-24 > URL: https://issues.apache.org/jira/browse/MWRAPPER-24 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > see MNG-7270 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-25) fix installer messages
[
https://issues.apache.org/jira/browse/MWRAPPER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-25:
--
Component/s: Maven Wrapper Jar
> fix installer messages
> --
>
> Key: MWRAPPER-25
> URL: https://issues.apache.org/jira/browse/MWRAPPER-25
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 0.5.6
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> {noformat}$ MVNW_VERBOSE=true ./mvnw -v
> Found .mvn/wrapper/maven-wrapper.jar
> /home/herve/projets/maven/sources/core/maven-wrapper
> Apache Maven Wrapper 3.0.3-SNAPSHOT
> Downloading Maven binary from
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip
> Exception in thread "main" java.lang.RuntimeException: Maven distribution
> 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
> contains too many directories. Expected to find exactly 1 directory.
> at org.apache.maven.wrapper.Installer.createDist(Installer.java:113)
> at
> org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:160)
> at
> org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:69)
> {noformat}
> 2 issues:
> 1. "Downloading Maven binary from ..." when we're not at download but
> installing to local directory
> 2. "RuntimeException: Maven distribution
> 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
> contains too many directories": it's not about download url but local
> installation directory
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MWRAPPER-26) install binary by default to match older user experience
[ https://issues.apache.org/jira/browse/MWRAPPER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-26: -- Component/s: Maven Wrapper Plugin > install binary by default to match older user experience > > > Key: MWRAPPER-26 > URL: https://issues.apache.org/jira/browse/MWRAPPER-26 > Project: Maven Wrapper > Issue Type: Wish > Components: Maven Wrapper Plugin >Affects Versions: 3.0.2 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > maven-wrapper-plugin has been written to install script distribution by > default, which leads the user to download maven-wrapper.jar when launching > mvnw > to match previous Takari plugin behaviour, switching to binray distribution > will avoid that: user wll decide to add maven-wrapper.jar to source control > or not -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWRAPPER-19) maven-wrapper DefaultDownloader does not parse user/password correctly
[
https://issues.apache.org/jira/browse/MWRAPPER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MWRAPPER-19:
--
Component/s: Maven Wrapper Jar
> maven-wrapper DefaultDownloader does not parse user/password correctly
> --
>
> Key: MWRAPPER-19
> URL: https://issues.apache.org/jira/browse/MWRAPPER-19
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 0.5.6
>Reporter: James Z.M. Gao
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.0
>
>
> In wrapper DefaultDownloader, when auth for the http proxy,
> MVNW_{USERNAME,PASSWORD} should be fetched via System.getenv, not
> System.getProperty.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWRAPPER-26) install binary by default to match older user experience
Herve Boutemy created MWRAPPER-26: - Summary: install binary by default to match older user experience Key: MWRAPPER-26 URL: https://issues.apache.org/jira/browse/MWRAPPER-26 Project: Maven Wrapper Issue Type: Wish Affects Versions: 3.0.2 Reporter: Herve Boutemy Fix For: 3.1.0 maven-wrapper-plugin has been written to install script distribution by default, which leads the user to download maven-wrapper.jar when launching mvnw to match previous Takari plugin behaviour, switching to binray distribution will avoid that: user wll decide to add maven-wrapper.jar to source control or not -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MJAVADOC-702) javadoc site creation ignores configuration parameters
Henning Schmiedehausen created MJAVADOC-702:
---
Summary: javadoc site creation ignores configuration parameters
Key: MJAVADOC-702
URL: https://issues.apache.org/jira/browse/MJAVADOC-702
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.3.1
Environment: Apache Maven 3.8.4
(9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
Reporter: Henning Schmiedehausen
how to reproduce:
{{% git clone https://github.com/hgschmie/pg-embedded.git}}
{{% cd pg-embedded}}
{{% ./mvnw clean install site}}
Point a browser at the local target/apidocs folder. The generated javadocs do
not have a HELP menu item on top and references to Guava, JUnit5 etc. have been
resolved and are linked.
Point a browser at target/site/apidocs. The javadocs here do have a HELP menu
item and references to JUnit 5 etc. are fully qualified class names without
links.
The debug log shows that the javadoc-no-fork goal is run with a lot of
configuration options, including multiple duplicates:
{{[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:test-javadoc-no-fork' with
basic configurator -->}}
{{[DEBUG] (f) release = 11}}
{{[DEBUG] (f) source = 11}}
{{[DEBUG] (f) encoding = UTF-8}}
{{[DEBUG] (f) maxmemory = 1024m}}
{{[DEBUG] (f) quiet = true}}
{{[DEBUG] (f) doclint = none}}
{{[DEBUG] (f) show = protected}}
{{[DEBUG] (f) links = [https://junit.org/junit5/docs/5.8.1/api/,
https://javadoc.io/doc/com.google.guava/guava/30.1.1-jre/,
https://javadoc.io/doc/com.github.spotbugs/spotbugs-annotations/4.4.2]}}
{{[DEBUG] (f) author = false}}
{{[DEBUG] (f) detectJavaApiLink = true}}
{{[DEBUG] (f) linksource = true}}
{{[DEBUG] (f) nodeprecated = false}}
{{[DEBUG] (f) nohelp = true}}
{{[DEBUG] (f) skip = false}}
{{[DEBUG] (f) failOnError = true}}
{{[DEBUG] (f) release = 11}}
{{[DEBUG] (f) source = 11}}
{{[DEBUG] (f) encoding = UTF-8}}
{{[DEBUG] (f) maxmemory = 1024m}}
{{[DEBUG] (f) quiet = true}}
{{[DEBUG] (f) doclint = none}}
{{[DEBUG] (f) show = protected}}
{{[DEBUG] (f) links = [https://junit.org/junit5/docs/5.8.1/api/,
https://javadoc.io/doc/com.google.guava/guava/30.1.1-jre/,
https://javadoc.io/doc/com.github.spotbugs/spotbugs-annotations/4.4.2]}}
{{[DEBUG] (f) author = false}}
{{[DEBUG] (f) detectJavaApiLink = true}}
{{[DEBUG] (f) linksource = true}}
{{[DEBUG] (f) nodeprecated = false}}
{{[DEBUG] (f) nohelp = true}}
{{[DEBUG] (f) applyJavadocSecurityFix = true}}
{{[DEBUG] (f) author = true}}
{{[DEBUG] (f) bootclasspathArtifacts = []}}
{{[DEBUG] (f) bottom = Copyright
\{inceptionYear\}\{currentYear\} \{organizationName\}. All rights
reserved.}}
{{[DEBUG] (f) breakiterator = false}}
{{[DEBUG] (f) debug = false}}
{{[DEBUG] (s) destDir = testapidocs}}
{{[DEBUG] (f) detectJavaApiLink = true}}
{{[DEBUG] (f) detectLinks = false}}
{{[DEBUG] (f) detectOfflineLinks = true}}
{{[DEBUG] (f) docencoding = UTF-8}}
{{[DEBUG] (f) docfilessubdirs = false}}
{{[DEBUG] (f) docletArtifact = groupId = 'null' artifactId = 'null' version =
'null' classifier = 'null'}}
{{[DEBUG] (f) docletArtifacts = []}}
{{[DEBUG] (f) doctitle = pg-embedded 4.1-SNAPSHOT API}}
{{[DEBUG] (f) encoding = UTF-8}}
{{[DEBUG] (f) failOnError = true}}
{{[DEBUG] (f) failOnWarnings = false}}
{{[DEBUG] (f) includeDependencySources = false}}
{{[DEBUG] (f) includeTransitiveDependencySources = false}}
{{[DEBUG] (f) isOffline = false}}
{{[DEBUG] (f) javaApiLinks = {}}}
{{[DEBUG] (f) javadocDirectory =
/Users/henning/code/pg-embedded/src/main/javadoc}}
{{[DEBUG] (f) javadocOptionsDir =
/Users/henning/code/pg-embedded/target/javadoc-bundle-options}}
{{[DEBUG] (f) keywords = false}}
{{[DEBUG] (f) links = []}}
{{[DEBUG] (f) linksource = false}}
{{[DEBUG] (f) localRepository = id: local url:
file:///Users/henning/.m2/repository/layout: default snapshots: [enabled =>
true, update => always] releases: [enabled => true, update => always]
blocked: false}}
{{[DEBUG] (f) mojo =
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:test-javadoc-no-fork
\{execution: null\}}}
{{[DEBUG] (f) nocomment = false}}
{{[DEBUG] (f) nodeprecated = false}}
{{[DEBUG] (f) nodeprecatedlist = false}}
{{[DEBUG] (f) nohelp = false}}
{{[DEBUG] (f) noindex = false}}
{{[DEBUG] (f) nonavbar = false}}
{{[DEBUG] (f) nooverview = false}}
{{[DEBUG] (f) nosince = false}}
{{[DEBUG] (f) notimestamp = false}}
{{[DEBUG] (f) notree = false}}
{{[DEBUG] (f) offlineLinks = []}}
{{[DEBUG] (f) old =
[jira] [Updated] (MWRAPPER-16) update mvnw scripts to launch target Maven mvn scripts, to enforce consistency
[ https://issues.apache.org/jira/browse/MWRAPPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-16: -- Summary: update mvnw scripts to launch target Maven mvn scripts, to enforce consistency (was: update mvnw scripts to launch target Maven mvn scripts to enforce consistency) > update mvnw scripts to launch target Maven mvn scripts, to enforce consistency > -- > > Key: MWRAPPER-16 > URL: https://issues.apache.org/jira/browse/MWRAPPER-16 > Project: Maven Wrapper > Issue Type: Improvement >Affects Versions: 0.5.6, 3.1.0 >Reporter: Herve Boutemy >Priority: Major > > currently, wrapper scripts copied to user project mimic Maven scripts (search > .mvn, and so on), then launch wrapper.jar: at the end, wrapper.jar calls > installed Maven distribution Classworlds bootstrap to run Maven Java code > this may cause a discrepency between features supported by mvnw script vs > what would have been done by installed Maven mvn scripts > for example, when/if [https://github.com/apache/maven/pull/602] is done > To enforce consistency, mvnw should launch installed Maven mvn script at the > end, and let it do its full work as if it had been launched -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-6523) System Dependencies Deprecation
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454239#comment-17454239 ] Michael Osipov commented on MNG-6523: - So you rather solve the symptom than the cause? I Personally would let my employer suffer to understand the pain you are going through. I perfectly know this and do this. I currently see no technical problem in your case. > System Dependencies Deprecation > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > Fix For: wontfix-candidate > > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MWRAPPER-25) fix installer messages
[
https://issues.apache.org/jira/browse/MWRAPPER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MWRAPPER-25.
-
Assignee: Herve Boutemy
Resolution: Fixed
done in
https://github.com/apache/maven-wrapper/commit/1e4d39131c9fee5fab60c81924d01741c02c1b2c
{noformat}$ MVNW_VERBOSE=true ./mvnw -v
Found .mvn/wrapper/maven-wrapper.jar
/home/herve/projets/maven/sources/core/maven-wrapper
Apache Maven Wrapper 3.1.0-SNAPSHOT
Installing Maven distribution
/home/herve/.m2/wrapper/dists/apache-maven-3.8.3-bin/5a6n1u8or3307vo2u2jgmkhm0t
Exception in thread "main" java.lang.RuntimeException: Maven distribution
'/home/herve/.m2/wrapper/dists/apache-maven-3.8.3-bin/5a6n1u8or3307vo2u2jgmkhm0t'
contains too many directories. Expected to find exactly 1 directory.
{noformat}
> fix installer messages
> --
>
> Key: MWRAPPER-25
> URL: https://issues.apache.org/jira/browse/MWRAPPER-25
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 0.5.6
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> {noformat}$ MVNW_VERBOSE=true ./mvnw -v
> Found .mvn/wrapper/maven-wrapper.jar
> /home/herve/projets/maven/sources/core/maven-wrapper
> Apache Maven Wrapper 3.0.3-SNAPSHOT
> Downloading Maven binary from
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip
> Exception in thread "main" java.lang.RuntimeException: Maven distribution
> 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
> contains too many directories. Expected to find exactly 1 directory.
> at org.apache.maven.wrapper.Installer.createDist(Installer.java:113)
> at
> org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:160)
> at
> org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:69)
> {noformat}
> 2 issues:
> 1. "Downloading Maven binary from ..." when we're not at download but
> installing to local directory
> 2. "RuntimeException: Maven distribution
> 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
> contains too many directories": it's not about download url but local
> installation directory
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWRAPPER-25) fix installer messages
Herve Boutemy created MWRAPPER-25:
-
Summary: fix installer messages
Key: MWRAPPER-25
URL: https://issues.apache.org/jira/browse/MWRAPPER-25
Project: Maven Wrapper
Issue Type: Bug
Affects Versions: 0.5.6
Reporter: Herve Boutemy
Fix For: 3.1.0
{noformat}$ MVNW_VERBOSE=true ./mvnw -v
Found .mvn/wrapper/maven-wrapper.jar
/home/herve/projets/maven/sources/core/maven-wrapper
Apache Maven Wrapper 3.0.3-SNAPSHOT
Downloading Maven binary from
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip
Exception in thread "main" java.lang.RuntimeException: Maven distribution
'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
contains too many directories. Expected to find exactly 1 directory.
at org.apache.maven.wrapper.Installer.createDist(Installer.java:113)
at
org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:160)
at
org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:69)
{noformat}
2 issues:
1. "Downloading Maven binary from ..." when we're not at download but
installing to local directory
2. "RuntimeException: Maven distribution
'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.zip'
contains too many directories": it's not about download url but local
installation directory
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MDEPLOY-289) No "Content-Type" header in PUT requests when deploying.
[
https://issues.apache.org/jira/browse/MDEPLOY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454200#comment-17454200
]
J.R. Hill edited comment on MDEPLOY-289 at 12/6/21, 8:49 PM:
-
That all sounds reasonable to me. I think the only benefit will be to people
implementing fairly low-level proxies or servers. I think it's a minor use
case, and "just default to {{application/octet-stream}}" might be a best
solution here anyway.
> Well, we don't have the content type and likely will not.
I think it's fine to close this out. We don't have a strong need for this
change, and your explanations are helpful and thorough and point to the right
place to do this kind of change if someone else has a stronger reason for doing
it.
Thanks [~michael-o] for the help and insight!
was (Author: JIRAUSER281198):
That all sounds reasonable to me. I think the only benefit will be to people
implementing fairly low-level proxies or servers. I think it's a minor use
case, and "just default to `application/octet-stream`" might be a best solution
here anyway.
> Well, we don't have the content type and likely will not.
I think it's fine to close this out. We don't have a strong need for this
change, and your explanations are helpful and thorough and point to the right
place to do this kind of change if someone else has a stronger reason for doing
it.
Thanks [~michael-o] for the help and insight!
> No "Content-Type" header in PUT requests when deploying.
>
>
> Key: MDEPLOY-289
> URL: https://issues.apache.org/jira/browse/MDEPLOY-289
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Mac/Linux
>Reporter: J.R. Hill
>Assignee: Michael Osipov
>Priority: Minor
>
> Heya folks!
>
> I work with Amazon/AWS as a build engineer. I'm researching how much effort
> it would take to give our developers the option to build with Apache Maven.
> (opposed to other tools like Gradle)
>
> Right now we are blocked from an easy usage of Apache Maven because no
> "Content-Type" header is sent in requests, and it violates some expectations
> of our proxies. We use clones of maven repositories so we can have some
> governance controls across our codebase and services.
>
> We have ways we could work around around it - we could consider loosening our
> proxies, or adding special handling. We could also build our own plugin that
> does things the way we want. That said, I'd prefer to use off-the-shelf
> tools, and to be able to contribute to open source projects where possible.
>
> I looked a bit into how this plugin is performing deployments. I see it's
> using Aether for the deploy action, and see what looks like some complicated
> history there between Sonatype and Eclipse around the Aether project. I'm not
> sure if this is possible to fix this _in_ the Maven Deploy Plugin or if it'd
> have to go deeper into the Aether code base.
>
> Any pointers? I'd love to take a crack at something here.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6523) System Dependencies Deprecation
[
https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454229#comment-17454229
]
Leonardo Maffei da Silva commented on MNG-6523:
---
[~michael-o] I wil give the use case of the company I am working in: I must
build and maven project; however, the access to internet is quite *complicated*
under the current constraints: the builder can only access {*}intranet{*}.
Specifically in my case, I need a specific version which is not present on the
internal intranet repository, and is not straight forward to just push the
missing artifact so that I can use it (it is quite bureaucratic and
inneficient). Hence I would be very grateful if this feature is not removed.
> System Dependencies Deprecation
> ---
>
> Key: MNG-6523
> URL: https://issues.apache.org/jira/browse/MNG-6523
> Project: Maven
> Issue Type: Wish
>Reporter: Alireza Fattahi
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Please let me know if this is wrong place for discussions about this.
>
> As mentioned in
> [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies]
> the System Dependencies will be depreciated and should not be used.
> Well this feature seems very useful in some cases and must developers find it
> easy to use:
> [https://stackoverflow.com/a/4491469/2648077]
> [https://stackoverflow.com/a/22300875/2648077]
>
> Well I wish it wouldn't be deprecated at all :)
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSCRIPTING-6) Download page link is broken
[ https://issues.apache.org/jira/browse/MSCRIPTING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSCRIPTING-6. -- Fix Version/s: 3.0.1 Assignee: Herve Boutemy Resolution: Fixed fixed in https://github.com/apache/maven-scripting-plugin/commit/314fd6e583bac689db4f650a253b51e5bb317a21 thanks for the report > Download page link is broken > > > Key: MSCRIPTING-6 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-6 > Project: Maven Scripting > Issue Type: Bug >Reporter: Sebb >Assignee: Herve Boutemy >Priority: Critical > Fix For: 3.0.1 > > > The download link should point to a page where the source, KEYS, sigs and > hashes can be obtained. > Instead it points to the top-level of the download mirrors. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-701:
Description:
How to reproduce:
{{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
{{% cd pg-embedded}}
{{% git checkout -b 4.0-branch pg-embedded-4.0}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{module-search-index.js}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
was:
How to reproduce:
{{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
{{% cd pg-embedded}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}}}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> How to reproduce:
>
> {{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
> {{% cd pg-embedded}}
> {{% git checkout -b 4.0-branch
[jira] [Updated] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-701:
Description:
How to reproduce:
{{{}% git clone [https://github.com/hgschmie/pg-embedded.git]{}}}{{{}% {}}}
{{cd pg-embedded}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{{color:#FF}*de.softwareforge.testing.postgres*{color} script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}}}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
was:
How to reproduce:
{{{}% git clone [https://github.com/hgschmie/pg-embedded.git]{}}}{{{}% cd
pg-embedded{}}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{de.softwareforge.testing.postgres script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}{{{}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> How to reproduce:
>
> {{{}% git clone [https://github.com/hgschmie/pg-embedded.git]{}}}{{{}% {}}}
> {{cd pg-embedded}}
> {{% ./mvnw clean site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html jquery-ui.overrides.css script-dir}}
> {{allpackages-index.html legal
[jira] [Updated] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-701:
Description:
How to reproduce:
{{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
{{% cd pg-embedded}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}}}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
was:
How to reproduce:
{{{}% git clone [https://github.com/hgschmie/pg-embedded.git]{}}}{{{}% {}}}
{{cd pg-embedded}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{{color:#FF}*de.softwareforge.testing.postgres*{color} script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}}}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> How to reproduce:
>
> {{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
> {{% cd pg-embedded}}
> {{% ./mvnw clean site}}
> {{% ls target/site/apidocs}}
>
[jira] [Created] (MJAVADOC-701) javadoc site is broken for projects that contain modules
Henning Schmiedehausen created MJAVADOC-701:
---
Summary: javadoc site is broken for projects that contain modules
Key: MJAVADOC-701
URL: https://issues.apache.org/jira/browse/MJAVADOC-701
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.3.1
Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
Reporter: Henning Schmiedehausen
How to reproduce:
{{{}% git clone [https://github.com/hgschmie/pg-embedded.git]{}}}{{{}% cd
pg-embedded{}}}
{{% ./mvnw clean site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html jquery-ui.overrides.css script-dir}}
{{allpackages-index.html legal script.js}}
{{constant-values.html member-search-index.js search.js}}
{{de module-search-index.js src-html}}
{{deprecated-list.html overview-summary.html stylesheet.css}}
{{element-list overview-tree.html tag-search-index.js}}
{{index-all.html package-search-index.js type-search-index.js}}
{{index.html resources}}
{{% ./mvnw clean install site}}
{{% ls target/site/apidocs}}
{{allclasses-index.html overview-tree.html}}
{{allpackages-index.html package-search-index.js}}
{{constant-values.html resources}}
{{de.softwareforge.testing.postgres script-dir}}
{{deprecated-list.html script.js}}
{{element-list search.js}}
{{index-all.html src}}
{{index.html src-html}}
{{jquery-ui.overrides.css stylesheet.css}}
{{legal tag-search-index.js}}
{{member-search-index.js type-search-index.js}}
{{{}module-search-index.js{}}}{{{}{}}}
==> If the build only creates the site (run aggregate-no-fork, javadoc,
javadoc-no-fork), it will not contain the module subfolder
(de.softwareforge.testing.postgres)
==> if the build also runs the "javadoc:jar" goal, the site will contain the
module subfolder
I have looked through the debug output and the options to the maven javadoc
plugin execution but nothing stands out. Just that one builds the module
javadoc correctly and the other does not.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MDEPLOY-289) No "Content-Type" header in PUT requests when deploying.
[ https://issues.apache.org/jira/browse/MDEPLOY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MDEPLOY-289. -- Assignee: Michael Osipov Resolution: Information Provided > No "Content-Type" header in PUT requests when deploying. > > > Key: MDEPLOY-289 > URL: https://issues.apache.org/jira/browse/MDEPLOY-289 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Affects Versions: 2.8.2 > Environment: Mac/Linux >Reporter: J.R. Hill >Assignee: Michael Osipov >Priority: Minor > > Heya folks! > > I work with Amazon/AWS as a build engineer. I'm researching how much effort > it would take to give our developers the option to build with Apache Maven. > (opposed to other tools like Gradle) > > Right now we are blocked from an easy usage of Apache Maven because no > "Content-Type" header is sent in requests, and it violates some expectations > of our proxies. We use clones of maven repositories so we can have some > governance controls across our codebase and services. > > We have ways we could work around around it - we could consider loosening our > proxies, or adding special handling. We could also build our own plugin that > does things the way we want. That said, I'd prefer to use off-the-shelf > tools, and to be able to contribute to open source projects where possible. > > I looked a bit into how this plugin is performing deployments. I see it's > using Aether for the deploy action, and see what looks like some complicated > history there between Sonatype and Eclipse around the Aether project. I'm not > sure if this is possible to fix this _in_ the Maven Deploy Plugin or if it'd > have to go deeper into the Aether code base. > > Any pointers? I'd love to take a crack at something here. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEPLOY-289) No "Content-Type" header in PUT requests when deploying.
[ https://issues.apache.org/jira/browse/MDEPLOY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454200#comment-17454200 ] J.R. Hill commented on MDEPLOY-289: --- That all sounds reasonable to me. I think the only benefit will be to people implementing fairly low-level proxies or servers. I think it's a minor use case, and "just default to `application/octet-stream`" might be a best solution here anyway. > Well, we don't have the content type and likely will not. I think it's fine to close this out. We don't have a strong need for this change, and your explanations are helpful and thorough and point to the right place to do this kind of change if someone else has a stronger reason for doing it. Thanks [~michael-o] for the help and insight! > No "Content-Type" header in PUT requests when deploying. > > > Key: MDEPLOY-289 > URL: https://issues.apache.org/jira/browse/MDEPLOY-289 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Affects Versions: 2.8.2 > Environment: Mac/Linux >Reporter: J.R. Hill >Priority: Minor > > Heya folks! > > I work with Amazon/AWS as a build engineer. I'm researching how much effort > it would take to give our developers the option to build with Apache Maven. > (opposed to other tools like Gradle) > > Right now we are blocked from an easy usage of Apache Maven because no > "Content-Type" header is sent in requests, and it violates some expectations > of our proxies. We use clones of maven repositories so we can have some > governance controls across our codebase and services. > > We have ways we could work around around it - we could consider loosening our > proxies, or adding special handling. We could also build our own plugin that > does things the way we want. That said, I'd prefer to use off-the-shelf > tools, and to be able to contribute to open source projects where possible. > > I looked a bit into how this plugin is performing deployments. I see it's > using Aether for the deploy action, and see what looks like some complicated > history there between Sonatype and Eclipse around the Aether project. I'm not > sure if this is possible to fix this _in_ the Maven Deploy Plugin or if it'd > have to go deeper into the Aether code base. > > Any pointers? I'd love to take a crack at something here. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MSCRIPTING-5) Links on about page not working
[ https://issues.apache.org/jira/browse/MSCRIPTING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte resolved MSCRIPTING-5. - Fix Version/s: 3.0.1 Assignee: Robert Scholte Resolution: Fixed Fixed in [02e462130d300ef04aba10d4d5cd01c217621fab|https://gitbox.apache.org/repos/asf?p=maven-scripting-plugin.git;a=commit;h=02e462130d300ef04aba10d4d5cd01c217621fab] > Links on about page not working > --- > > Key: MSCRIPTING-5 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-5 > Project: Maven Scripting > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Andreas Holtz >Assignee: Robert Scholte >Priority: Minor > Labels: documentation > Fix For: 3.0.1 > > > Most links on About page > ([https://maven.apache.org/plugins/maven-scripting-plugin/index.html)] are > not working: > * usage page - > https://maven.apache.org/plugins/maven-scripting-plugin/usage.html > * mailing list - > https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html > * FAQ - [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] > * mail archive - > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > * issue tracking - > [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > * source repository - > [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] > all point to "Page not found". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763224042 ## File path: maven-caching-extension/src/site/markdown/CACHE-GETTING-STARTED.md ## @@ -0,0 +1,74 @@ + + +## Getting Started + +To on-board incremental Maven you need to complete several steps: + +* Declare caching extension in your project +* Add cache config in `.mvn` (optional) to customize default behavior +* Validate build results and iteratively adjust config to properly reflect project specifics +* Setup remote cache (optional) + +### Declaring cache extension + +```xml + + +org.apache.maven.caching +maven-caching-extension +1.0.0-SNAPSHOT + +``` + +### Adding cache config + +Copy [default config `maven-cache-config.xml`](maven-cache-config.xml) +to [`.mvn/`](https://maven.apache.org/configure.html) dir of your project. +To get overall understanding of cache machinery it is recommended to review the config and read comments. In typical +scenario you need to adjust: + +* remote cache location +* source code files selectors +* plugins reconciliation rules - add critical plugins parameters to reconciliation +* add non-standard source code locations (most of locations discovered automatically from project and plugins config, + but still there might be edge cases) + +### Adjusting cache config + +Having incremental Maven and the config in place you're all set. To run first cacheable build just +execute: `mvn clean install` + +* Ensure that extension is started and the cache config is picked up. Just check log output - you will notice cache Review comment: reworded -- 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] AlexanderAshitkin edited a comment on pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin edited a comment on pull request #631: URL: https://github.com/apache/maven/pull/631#issuecomment-986975111 @michael-o Thanks for the review! Hope it looks better now. -- 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] AlexanderAshitkin commented on pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on pull request #631: URL: https://github.com/apache/maven/pull/631#issuecomment-986975111 @michael-o Thanks for the review! -- 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] AlexanderAshitkin edited a comment on pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin edited a comment on pull request #631: URL: https://github.com/apache/maven/pull/631#issuecomment-986965099 > /CACHE-GETTING-STARTED.md > * All markdown files start with `CACHE`. Since this is in the Cache Extension anyway, what is the need to prefix everything if there is only one prefix? I see it as redundant. `CACHE.md` should be the index file. > * Why are all doc files in uppercase? Please use lowercase as we do in the rest of our documentation pages. Renamed files. Regarding the case - i guess it is a quite common convention to name markdown files in uppercase. For example maven core itself keeps md files in uppercase notation -- 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] AlexanderAshitkin commented on pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on pull request #631: URL: https://github.com/apache/maven/pull/631#issuecomment-986965099 > /CACHE-GETTING-STARTED.md > * All markdown files start with `CACHE`. Since this is in the Cache Extension anyway, what is the need to prefix everything if there is only one prefix? I see it as redundant. `CACHE.md` should be the index file. > * Why are all doc files in uppercase? Please use lowercase as we do in the rest of our documentation pages. Renamed files. Regarding the case - i guess it is a quite common convention to keep markdown files in uppercase. For example maven core itself keeps md files in uppercase notation -- 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] AlexanderAshitkin commented on pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on pull request #631: URL: https://github.com/apache/maven/pull/631#issuecomment-986961788 > What I absolutely dislke that terms like hash and checksums are used interchangeably, but they are _not_. They serve different purposes. Please completely clarify in the code _and_ documentation what you actually need. Read https://security.stackexchange.com/a/194602 Agree, fixed. Streamlined documentation to use 2 terms through doc - cache key and hash -- 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] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763189483 ## File path: maven-caching-extension/src/site/markdown/CACHE-GETTING-STARTED.md ## @@ -0,0 +1,74 @@ + + +## Getting Started + +To on-board incremental Maven you need to complete several steps: + +* Declare caching extension in your project +* Add cache config in `.mvn` (optional) to customize default behavior +* Validate build results and iteratively adjust config to properly reflect project specifics +* Setup remote cache (optional) + +### Declaring cache extension + +```xml + + +org.apache.maven.caching +maven-caching-extension +1.0.0-SNAPSHOT + +``` + +### Adding cache config + +Copy [default config `maven-cache-config.xml`](maven-cache-config.xml) +to [`.mvn/`](https://maven.apache.org/configure.html) dir of your project. +To get overall understanding of cache machinery it is recommended to review the config and read comments. In typical +scenario you need to adjust: + +* remote cache location +* source code files selectors +* plugins reconciliation rules - add critical plugins parameters to reconciliation +* add non-standard source code locations (most of locations discovered automatically from project and plugins config, + but still there might be edge cases) + +### Adjusting cache config + +Having incremental Maven and the config in place you're all set. To run first cacheable build just +execute: `mvn clean install` + +* Ensure that extension is started and the cache config is picked up. Just check log output - you will notice cache + related output or initialization error message. +* Navigate to your local repo directory - there should be sibling next to your local repo named `cache` +* Find `buildinfo.xml` for typical module and review it. Ensure that +* expected source code files are present in build info +* all critical plugins and their critical parameters are covered by config + +Notice - in configuration you should find best working trade-off between fairness and cache efficiency. Adding +unnecessary rules and checks could reduce both performance and cache efficiency (hit rate). + +### Adding caching CI and remote cache + +To leverage remote cache feature you need web server which supports get/put operations +like [Nginx OSS](http://nginx.org/en/) (with fs module) or binary repo in Artifactory. It is recommended to populate Review comment: fixed -- 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] [Updated] (MRESOURCES-275) valid location for directory parameter is always required
[
https://issues.apache.org/jira/browse/MRESOURCES-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MRESOURCES-275:
Fix Version/s: 3.3.0
> valid location for directory parameter is always required
> -
>
> Key: MRESOURCES-275
> URL: https://issues.apache.org/jira/browse/MRESOURCES-275
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Delany
>Priority: Minor
> Fix For: 3.3.0
>
>
> Suppose I remove src/main/resources.
> When I build, default-resources execution logs "skip non existing
> resourceDirectory"
> But when i configure my own execution like so, it throws a null pointer
> exception:
> {code:java}
>
> maven-resources-plugin
> 3.2.0
>
>
> readme-resources
> process-resources
>
> resources
>
>
>
>
>
>
>
>
>
>
> {code}
> Its a bit confusing because the documentation for the goal makes no mention
> of a directory parameter, and its obviously a required parameter, and it must
> be a valid location.
> [https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MRESOURCES-275) valid location for directory parameter is always required
[
https://issues.apache.org/jira/browse/MRESOURCES-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MRESOURCES-275:
---
Assignee: Sylwester Lachiewicz
> valid location for directory parameter is always required
> -
>
> Key: MRESOURCES-275
> URL: https://issues.apache.org/jira/browse/MRESOURCES-275
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Delany
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.3.0
>
>
> Suppose I remove src/main/resources.
> When I build, default-resources execution logs "skip non existing
> resourceDirectory"
> But when i configure my own execution like so, it throws a null pointer
> exception:
> {code:java}
>
> maven-resources-plugin
> 3.2.0
>
>
> readme-resources
> process-resources
>
> resources
>
>
>
>
>
>
>
>
>
>
> {code}
> Its a bit confusing because the documentation for the goal makes no mention
> of a directory parameter, and its obviously a required parameter, and it must
> be a valid location.
> [https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454125#comment-17454125
]
Sylwester Lachiewicz commented on MRESOURCES-237:
-
Please try with updated maven-filtering dependency - should be fixed now
{{ org.apache.maven.plugins}}
{{ maven-resources-plugin}}
{{ 3.2.0}}
{{ }}
{{ }}
{{ org.apache.maven.shared}}
{{ maven-filtering}}
{{ 3.3.0-SNAPSHOT}}
{{ }}
{{ }}
[Edit|https://issues.apache.org/jira/secure/EditComment!default.jspa?id=13337258=17454108]
[Delete|https://issues.apache.org/jira/secure/DeleteComment!default.jspa?id=13337258=17454108]
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763162965 ## File path: maven-caching-extension/src/site/markdown/CACHE.md ## @@ -17,154 +17,110 @@ ## Overview -Idea of Incremental Maven is to specify module inputs and outputs and make them known to standard Maven core. This -allows accurate analysis and determination of out-of-date build artifacts in the build dependencies graph. Making the -dependency graph analysis deterministic leads to improvements in build times by avoiding re-building unnecessary -modules. -Cache does not make any low-level interventions to build process and delegates actual build work to Maven core. This -guarantees that build results are identical to results produced by standard Maven and are fully reproducible. -To achieve accurate input and outputs calculation incremental Maven combines automatic introspection -of [project object model](https://maven.apache.org/pom.html#What_is_the_POM) in conjunction with configuration-driven -rules for fine-grained content and execution control. For content analysis it digests based approach which is more -reliable over widely used file timestamps in tools like Make or Apache Ant. Deterministic build state allows reliably -cache even intermediate outputs of build and share them between teams using remote cache. Deterministic inputs -calculation allows distributed and parallel builds running in heterogeneous environments (like cloud of build agents) -could efficiently reuse cached build artifacts. Therefore incremental Maven is particularly well-suited for large Maven -projects that have significant number of small modules. Remote cache in conjunction with precise input identification -effectively enables "change once - build once" approach. +Build cache is an extension targeted to simplify and make more efficient work with large repositories in Maven. That is +achieved by a combination of features: + +* Incremental builds over the changed project graph part only +* Subtree support in multimodule projects (caches discovered from the larger project) +* Version normalization to support project version agnostic caches +* Project state restoration (partial) to avoid expensive tasks (code generation and similar) + +Large projects usually pose scalability challenges and work with such projects require build tool which scales. Cache +extension addresses that with incremental build execution and ability to efficiently work on sub-parts of a larger +project without building and installing dependencies from the larger project. Though, features implemented in maven +should give noticeable benefits in medium and small sized projects as well. + +### Cache concepts + +Idea of Incremental Maven is to calculate key from module inputs, store outputs in cache and restore them later +transparently to the standard Maven core. In order to calculate the key cache engine analyzes source code, build flow, +plugins and their parameters. This allows to deterministically associate each project state with unique key and restore +up-to-date(not changed) projects from cache and rebuild out-of-date(changed) ones. Restoring artifacts associated with a Review comment: fixed -- 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] [Assigned] (MRESOURCES-265) Resource copying not using specified encoding
[ https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MRESOURCES-265: --- Assignee: Sylwester Lachiewicz > Resource copying not using specified encoding > - > > Key: MRESOURCES-265 > URL: https://issues.apache.org/jira/browse/MRESOURCES-265 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 3.2.0 > Environment: Linux, CentOS 7 > Jenkins 2.251 > Jenkins Maven Integration plugin 3.1.2 > Java 1.8 >Reporter: Duncan Kinnear >Assignee: Sylwester Lachiewicz >Priority: Major > > Overnight our Jenkins builds stopped working. On investigation we found that > maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) > and today it was using 3.2.0. > The stacktrace produced by adding the "e" switch to the maven command line > had the following root cause (truncated for brevity):- > Caused by: java.nio.charset.MalformedInputException: Input length = 1 > at java.nio.charset.CoderResult.throwException (CoderResult.java:281) > at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339) > at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178) > at java.io.InputStreamReader.read (InputStreamReader.java:184) > at java.io.BufferedReader.read1 (BufferedReader.java:210) > at java.io.BufferedReader.read (BufferedReader.java:286) > at java.io.BufferedReader.fill (BufferedReader.java:161) > at java.io.BufferedReader.read (BufferedReader.java:182) > at org.apache.maven.shared.filtering.BoundedReader.read > (BoundedReader.java:85) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197) > at java.io.Reader.read (Reader.java:140) > at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199) > > After a google search told us this was an encoding issue, we added the > following to the maven command line, but this made no difference: > -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8 > > The maven build log has these info messsage just before the error: > [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks — > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Using 'UTF-8' encoding to copy filtered properties files. > [INFO] Copying 430 resources > We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the > projects POM 'pluginManagement' section. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding
[
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454119#comment-17454119
]
Sylwester Lachiewicz commented on MRESOURCES-265:
-
Please try with updated maven-filtering dependency - should be fixed now
{{ org.apache.maven.plugins}}
{{ maven-resources-plugin}}
{{ 3.2.0}}
{{ }}
{{ }}
{{ org.apache.maven.shared}}
{{ maven-filtering}}
{{ 3.3.0-SNAPSHOT}}
{{ }}
{{ }}
[Edit|https://issues.apache.org/jira/secure/EditComment!default.jspa?id=13337258=17454108]
[Delete|https://issues.apache.org/jira/secure/DeleteComment!default.jspa?id=13337258=17454108]
> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine)
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
> at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
> at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
> at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
> at java.io.InputStreamReader.read (InputStreamReader.java:184)
> at java.io.BufferedReader.read1 (BufferedReader.java:210)
> at java.io.BufferedReader.read (BufferedReader.java:286)
> at java.io.BufferedReader.fill (BufferedReader.java:161)
> at java.io.BufferedReader.read (BufferedReader.java:182)
> at org.apache.maven.shared.filtering.BoundedReader.read
> (BoundedReader.java:85)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
> (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
> (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197)
> at java.io.Reader.read (Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199)
>
> After a google search told us this was an encoding issue, we added the
> following to the maven command line, but this made no difference:
> -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8
>
> The maven build log has these info messsage just before the error:
> [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks —
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
> [INFO] Copying 430 resources
> We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the
> projects POM 'pluginManagement' section.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRESOURCES-265) Resource copying not using specified encoding
[ https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MRESOURCES-265: Fix Version/s: 3.3.0 > Resource copying not using specified encoding > - > > Key: MRESOURCES-265 > URL: https://issues.apache.org/jira/browse/MRESOURCES-265 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 3.2.0 > Environment: Linux, CentOS 7 > Jenkins 2.251 > Jenkins Maven Integration plugin 3.1.2 > Java 1.8 >Reporter: Duncan Kinnear >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > > Overnight our Jenkins builds stopped working. On investigation we found that > maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) > and today it was using 3.2.0. > The stacktrace produced by adding the "e" switch to the maven command line > had the following root cause (truncated for brevity):- > Caused by: java.nio.charset.MalformedInputException: Input length = 1 > at java.nio.charset.CoderResult.throwException (CoderResult.java:281) > at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339) > at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178) > at java.io.InputStreamReader.read (InputStreamReader.java:184) > at java.io.BufferedReader.read1 (BufferedReader.java:210) > at java.io.BufferedReader.read (BufferedReader.java:286) > at java.io.BufferedReader.fill (BufferedReader.java:161) > at java.io.BufferedReader.read (BufferedReader.java:182) > at org.apache.maven.shared.filtering.BoundedReader.read > (BoundedReader.java:85) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197) > at java.io.Reader.read (Reader.java:140) > at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199) > > After a google search told us this was an encoding issue, we added the > following to the maven command line, but this made no difference: > -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8 > > The maven build log has these info messsage just before the error: > [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks — > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Using 'UTF-8' encoding to copy filtered properties files. > [INFO] Copying 430 resources > We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the > projects POM 'pluginManagement' section. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763160774 ## File path: maven-caching-extension/src/site/markdown/CACHE-USAGE.md ## @@ -0,0 +1,46 @@ + + +## Normal usage + +Once extension is activated, cache will kick-in automatically on every lifecycle build of phase `package` or higher. + +## Subtree builds + +Build could be invoked on any module in project and will try to discover cache by introspecting dependencies. In order +to identify which dependencies are part of cacheable project the cache engine needs to know: + +* full project root location which must be passed with `-Dmaven.multiModuleProjectDirectory` +* Specify profiles which activate full graph in config: + +``` +TBD +``` + +## Disable cache + +To disable cache just need to remove extension Review comment: fixed -- 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] [Updated] (MRESOURCES-269) Symlinks cause copying resources to fail
[ https://issues.apache.org/jira/browse/MRESOURCES-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MRESOURCES-269: Fix Version/s: 3.3.0 (was: waiting-for-feedback) > Symlinks cause copying resources to fail > > > Key: MRESOURCES-269 > URL: https://issues.apache.org/jira/browse/MRESOURCES-269 > Project: Maven Resources Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: jks >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > Attachments: MRESOURCES-269.tar.gz, log.txt > > > Copying a symlink fails if the target does not exist. If the symlink is > relative the order that the resources are copied matter. If A points to B > but A is copied before B the copying of A will fail with a non-helpful > message "Failed to execute goal ... on project xxx: ". > > This started failing for me on 3.2.0 (and works on 3.1.0) but that might be > because somewhere in the dependencies the traversal order changed somehow. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRESOURCES-269) Symlinks cause copying resources to fail
[ https://issues.apache.org/jira/browse/MRESOURCES-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MRESOURCES-269: --- Assignee: Sylwester Lachiewicz > Symlinks cause copying resources to fail > > > Key: MRESOURCES-269 > URL: https://issues.apache.org/jira/browse/MRESOURCES-269 > Project: Maven Resources Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: jks >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: waiting-for-feedback > > Attachments: MRESOURCES-269.tar.gz, log.txt > > > Copying a symlink fails if the target does not exist. If the symlink is > relative the order that the resources are copied matter. If A points to B > but A is copied before B the copying of A will fail with a non-helpful > message "Failed to execute goal ... on project xxx: ". > > This started failing for me on 3.2.0 (and works on 3.1.0) but that might be > because somewhere in the dependencies the traversal order changed somehow. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOURCES-269) Symlinks cause copying resources to fail
[
https://issues.apache.org/jira/browse/MRESOURCES-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454108#comment-17454108
]
Sylwester Lachiewicz commented on MRESOURCES-269:
-
Please try with updated maven-filtering dependency - should be fixed now
{{ org.apache.maven.plugins}}
{{ maven-resources-plugin}}
{{ 3.2.0}}
{{ }}
{{ }}
{{ org.apache.maven.shared}}
{{ maven-filtering}}
{{ 3.3.0-SNAPSHOT}}
{{ }}
{{ }}
> Symlinks cause copying resources to fail
>
>
> Key: MRESOURCES-269
> URL: https://issues.apache.org/jira/browse/MRESOURCES-269
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: jks
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: MRESOURCES-269.tar.gz, log.txt
>
>
> Copying a symlink fails if the target does not exist. If the symlink is
> relative the order that the resources are copied matter. If A points to B
> but A is copied before B the copying of A will fail with a non-helpful
> message "Failed to execute goal ... on project xxx: ".
>
> This started failing for me on 3.2.0 (and works on 3.1.0) but that might be
> because somewhere in the dependencies the traversal order changed somehow.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MRESOURCES-268) java.nio.charset.MalformedInputException: Input length = 1
[
https://issues.apache.org/jira/browse/MRESOURCES-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MRESOURCES-268.
---
Resolution: Fixed
> java.nio.charset.MalformedInputException: Input length = 1
> --
>
> Key: MRESOURCES-268
> URL: https://issues.apache.org/jira/browse/MRESOURCES-268
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Sebastian T
>Assignee: Sylwester Lachiewicz
>Priority: Blocker
> Attachments: MRESOURCES-268.zip
>
>
> Resource filtering in 3.2.0 seems to be broken. We are getting the following
> error when upgrading the plugin:
> {noformat}
> > mvn package -e
> >
> >
> [INFO] Error stacktraces are turned on.
>
>
> [INFO] Scanning for projects...
>
>
> [INFO]
>
>
> [INFO] -< test:test
> >--
>
>
> [INFO] Building test 1.0.0-SNAPSHOT
>
>
> [INFO] [ jar
> ]-
>
>
> [INFO]
>
>
> [INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ test
> ---
>
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>
>
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>
>
> [INFO] Copying 1 resource
>
>
> [INFO]
>
>
>
> [INFO] BUILD FAILURE
>
>
> [INFO]
>
>
>
> [INFO] Total time: 0.601 s
>
>
> [INFO] Finished at: 2020-10-21T15:07:55+02:00
>
>
> [INFO]
>
>
>
> [ERROR] Failed to execute goal
>
[jira] [Updated] (MRESOURCES-268) java.nio.charset.MalformedInputException: Input length = 1
[
https://issues.apache.org/jira/browse/MRESOURCES-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MRESOURCES-268:
Fix Version/s: 3.3.0
> java.nio.charset.MalformedInputException: Input length = 1
> --
>
> Key: MRESOURCES-268
> URL: https://issues.apache.org/jira/browse/MRESOURCES-268
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Sebastian T
>Assignee: Sylwester Lachiewicz
>Priority: Blocker
> Fix For: 3.3.0
>
> Attachments: MRESOURCES-268.zip
>
>
> Resource filtering in 3.2.0 seems to be broken. We are getting the following
> error when upgrading the plugin:
> {noformat}
> > mvn package -e
> >
> >
> [INFO] Error stacktraces are turned on.
>
>
> [INFO] Scanning for projects...
>
>
> [INFO]
>
>
> [INFO] -< test:test
> >--
>
>
> [INFO] Building test 1.0.0-SNAPSHOT
>
>
> [INFO] [ jar
> ]-
>
>
> [INFO]
>
>
> [INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ test
> ---
>
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>
>
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>
>
> [INFO] Copying 1 resource
>
>
> [INFO]
>
>
>
> [INFO] BUILD FAILURE
>
>
> [INFO]
>
>
>
> [INFO] Total time: 0.601 s
>
>
> [INFO] Finished at: 2020-10-21T15:07:55+02:00
>
>
> [INFO]
>
>
>
> [ERROR] Failed to execute goal
>
[jira] [Updated] (MRESOURCES-268) java.nio.charset.MalformedInputException: Input length = 1
[
https://issues.apache.org/jira/browse/MRESOURCES-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MRESOURCES-268:
Priority: Minor (was: Blocker)
> java.nio.charset.MalformedInputException: Input length = 1
> --
>
> Key: MRESOURCES-268
> URL: https://issues.apache.org/jira/browse/MRESOURCES-268
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Sebastian T
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: MRESOURCES-268.zip
>
>
> Resource filtering in 3.2.0 seems to be broken. We are getting the following
> error when upgrading the plugin:
> {noformat}
> > mvn package -e
> >
> >
> [INFO] Error stacktraces are turned on.
>
>
> [INFO] Scanning for projects...
>
>
> [INFO]
>
>
> [INFO] -< test:test
> >--
>
>
> [INFO] Building test 1.0.0-SNAPSHOT
>
>
> [INFO] [ jar
> ]-
>
>
> [INFO]
>
>
> [INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ test
> ---
>
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>
>
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>
>
> [INFO] Copying 1 resource
>
>
> [INFO]
>
>
>
> [INFO] BUILD FAILURE
>
>
> [INFO]
>
>
>
> [INFO] Total time: 0.601 s
>
>
> [INFO] Finished at: 2020-10-21T15:07:55+02:00
>
>
> [INFO]
>
>
>
> [ERROR] Failed to execute goal
[jira] [Commented] (MRESOURCES-268) java.nio.charset.MalformedInputException: Input length = 1
[
https://issues.apache.org/jira/browse/MRESOURCES-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454102#comment-17454102
]
Sylwester Lachiewicz commented on MRESOURCES-268:
-
Logging added with
[https://gitbox.apache.org/repos/asf?p=maven-filtering.git;a=commit;h=aee34275d8064803f133e02cf9655c1a46a803c7]
> java.nio.charset.MalformedInputException: Input length = 1
> --
>
> Key: MRESOURCES-268
> URL: https://issues.apache.org/jira/browse/MRESOURCES-268
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Sebastian T
>Priority: Blocker
> Attachments: MRESOURCES-268.zip
>
>
> Resource filtering in 3.2.0 seems to be broken. We are getting the following
> error when upgrading the plugin:
> {noformat}
> > mvn package -e
> >
> >
> [INFO] Error stacktraces are turned on.
>
>
> [INFO] Scanning for projects...
>
>
> [INFO]
>
>
> [INFO] -< test:test
> >--
>
>
> [INFO] Building test 1.0.0-SNAPSHOT
>
>
> [INFO] [ jar
> ]-
>
>
> [INFO]
>
>
> [INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ test
> ---
>
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>
>
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>
>
> [INFO] Copying 1 resource
>
>
> [INFO]
>
>
>
> [INFO] BUILD FAILURE
>
>
> [INFO]
>
>
>
> [INFO] Total time: 0.601 s
>
>
> [INFO] Finished at: 2020-10-21T15:07:55+02:00
>
>
> [INFO]
>
>
>
[jira] [Reopened] (MRESOURCES-268) java.nio.charset.MalformedInputException: Input length = 1
[
https://issues.apache.org/jira/browse/MRESOURCES-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reopened MRESOURCES-268:
-
Assignee: Sylwester Lachiewicz
> java.nio.charset.MalformedInputException: Input length = 1
> --
>
> Key: MRESOURCES-268
> URL: https://issues.apache.org/jira/browse/MRESOURCES-268
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Sebastian T
>Assignee: Sylwester Lachiewicz
>Priority: Blocker
> Attachments: MRESOURCES-268.zip
>
>
> Resource filtering in 3.2.0 seems to be broken. We are getting the following
> error when upgrading the plugin:
> {noformat}
> > mvn package -e
> >
> >
> [INFO] Error stacktraces are turned on.
>
>
> [INFO] Scanning for projects...
>
>
> [INFO]
>
>
> [INFO] -< test:test
> >--
>
>
> [INFO] Building test 1.0.0-SNAPSHOT
>
>
> [INFO] [ jar
> ]-
>
>
> [INFO]
>
>
> [INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ test
> ---
>
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>
>
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
>
>
> [INFO] Copying 1 resource
>
>
> [INFO]
>
>
>
> [INFO] BUILD FAILURE
>
>
> [INFO]
>
>
>
> [INFO] Total time: 0.601 s
>
>
> [INFO] Finished at: 2020-10-21T15:07:55+02:00
>
>
> [INFO]
>
>
>
> [ERROR] Failed to execute goal
>
[GitHub] [maven-filtering] slachiewicz closed pull request #15: [MRESOURCES-268] - Report path of offending file on copy/filter error.
slachiewicz closed pull request #15: URL: https://github.com/apache/maven-filtering/pull/15 -- 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] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454099#comment-17454099 ] Sylwester Lachiewicz commented on MRESOURCES-250: - Done in [6fc8bb7df111d799c333837d2e9c0dd1a13eba6a|https://gitbox.apache.org/repos/asf?p=maven-filtering.git;a=commit;h=6fc8bb7df111d799c333837d2e9c0dd1a13eba6a] > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MRESOURCES-250. --- Resolution: Fixed > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-filtering] slachiewicz closed pull request #4: [MRESOURCES-250] - Add ability to flatten folder structure into target directory when copying resources
slachiewicz closed pull request #4: URL: https://github.com/apache/maven-filtering/pull/4 -- 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] [Updated] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MRESOURCES-250: Fix Version/s: 3.3.0 > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Priority: Major > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MRESOURCES-250: --- Assignee: Sylwester Lachiewicz > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MSHARED-1003) Require Maven 3.2.5+
[ https://issues.apache.org/jira/browse/MSHARED-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-1003: - Assignee: Sylwester Lachiewicz > Require Maven 3.2.5+ > > > Key: MSHARED-1003 > URL: https://issues.apache.org/jira/browse/MSHARED-1003 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer, maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MSHARED-1003) Require Maven 3.2.5+
[ https://issues.apache.org/jira/browse/MSHARED-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-1003: -- Fix Version/s: maven-filtering-3.3.0 > Require Maven 3.2.5+ > > > Key: MSHARED-1003 > URL: https://issues.apache.org/jira/browse/MSHARED-1003 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer, maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-filtering-3.3.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763123384 ## File path: maven-caching-extension/src/site/markdown/CACHE-USAGE.md ## @@ -0,0 +1,46 @@ + + +## Normal usage + +Once extension is activated, cache will kick-in automatically on every lifecycle build of phase `package` or higher. + +## Subtree builds + +Build could be invoked on any module in project and will try to discover cache by introspecting dependencies. In order +to identify which dependencies are part of cacheable project the cache engine needs to know: + +* full project root location which must be passed with `-Dmaven.multiModuleProjectDirectory` Review comment: Indeed, this is an implementation detail which must be satisfied in order to make this functionality work correctly. So it is unavoidably required in this implementation and in particular for subtree feature, when build could be started at any module within project. Maybe there is a better way to implement this, but so far this is required by implementation -- 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] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763120731 ## File path: maven-caching-extension/src/site/markdown/CACHE-REMOTE.md ## @@ -17,23 +17,42 @@ # Overview -This document describes generic approach to cache setup. The process require expertise in Maven equivalent to expertise -required to author and Maven your project build, it implies good knowledge of both Maven and the project. Due to Maven -model limitation the process is manual, but allows you to achieve sufficient control and transparency over caching -logic. +This document describes generic approach to remote cache setup. The process implies good knowledge of both Maven and the +project. Due to Maven model limitation the process is semi-manual, but allows you to achieve sufficient control and +transparency over caching logic. + +## Before you start + +Before you start, please keep in mind basic principles: + +* Cache is key based, the key is produced by HashTree-like technique. The key is produced by hashing every configured + source code file, every dependency and effective pom (including plugin parameters) should match into a single key. +* There is no built-in normalization of line endings in this implementation, file checksums calculation is raw bytes + based. The most obvious implication could be illustrated by a simple Git checkout. By default, git will check out + source code with CRLF line endings on win and LF on Linux. Because of that builds over same commit on a Linux agent + and local build on Windows workstation will yield different checksums. +* Parameters of plugins are reconciled in runtime. For example to avoid of accidentally reusing builds which never run + tests ensure that critical surefire parameters are tracked (`skipTests` and similar) in config. The same applies for + all over plugins. # Step-By-Step +## Minimize number of moving parts + +* Run build with single threaded builder to make sure logs from different modules do not interfere +* Use the same branch which no-one else commits to +* Designate single agent/node for CI builds +* Preferably use the same OS between CI and local machine + ## Fork branch for cache setup purposes -It is recommended to fork branch for cache setup purposes as you might need to do changes to project build as long as -you go. +Fork stable code branch for cache setup purposes as you will need source code which doesn't change over time of setup. +Also, you likely will need to do code changes as long as you go. ## Setup http server to store artifacts -In order to share build results you need shared storage. Basically any http server which supports http PUT/GET/HEAD -operations will work. In our case it is a Nginx OSS with file system module. Add the url to config and -change `remote@enabled` to true: +In order to share build results cache needs a shared storage. Basically any http server which supports http PUT/GET/HEAD Review comment: added few lines about wagon -- 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] AlexanderAshitkin commented on a change in pull request #631: [MNG-7129] Maven cache docs updates
AlexanderAshitkin commented on a change in pull request #631: URL: https://github.com/apache/maven/pull/631#discussion_r763114785 ## File path: maven-caching-extension/src/site/markdown/CACHE-PERFORMANCE.md ## @@ -0,0 +1,107 @@ + + +# Performance Tuning + +Various setup options which affect cache performance. + +## General notes + +Tuning of cache performance could reduce both resources consumption and build execution time but that is not guaranteed. +In many scenarios build time of invalidated (changed) projects could be dominating in overall build time. Performance +wins achieved by a faster cache engine might not correlate with final build times in straightforward way. As usual with +performance, effect of performance optimizations should be carefully measured in real build like scenarios. + +## Hash algorithm selection + +By default, cache uses SHA-256 algorithm which is sufficiently fast and provides negligible probability of hash +collisions. In projects with large codebase, performance of hash algorithms becomes more important and in such +scenarios [XX](https://cyan4973.github.io/xxHash/) or XXMM (memory mapped files) hashing algorithms provide better +performance. + +```xml + +XX +``` + +or + +```xml + +XXMM +``` + +## Filter out unnecessary/huge artifacts + +Price of uploading and downloading from cache of huge artifacts could be significant. In many scenarios assembling war +or zip archive could be done more efficiently locally from cached jars than storing bundles. In order to filter out +artifacts add configuration section: + +```xml + + + + +.*\.zip + + + +``` + +## Use lazy restore + +By default, cache tries to restore all artifacts for a project preemptively. Lazy restore could give a significant time +and resources wins for remote cache by avoiding requesting and downloading unnecessary artifacts from cache. Use command +line flag: + +``` +-Dremote.cache.lazyRestore=true"; +``` + +Note: In case of cache corruption lazy cache cannot fallback to normal execution, it will fail instead. To heal the +corrupted cache need to force rewrite of the cache or remove corrupted cache entries manually + +## Disable project files restoration + +By default, cache support partial restore of source code state from cached generated sources (and potentially more, +depending on configuration). This could be helpful in local environment, but likely unnecessary and adds overhead in +continuous integration. To disable add command line flag + +``` +-Dremote.cache.restoreGeneratedSources=false"; +``` + +## Disable post-processing of archives(jars, wars, etc) META-INF Review comment: fixed -- 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-filtering] dependabot[bot] commented on pull request #23: Bump mockito-core from 2.28.2 to 4.1.0
dependabot[bot] commented on pull request #23: URL: https://github.com/apache/maven-filtering/pull/23#issuecomment-986884070 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-filtering] dependabot[bot] commented on pull request #20: Bump org.eclipse.sisu.plexus from 0.0.0.M2a to 0.3.5
dependabot[bot] commented on pull request #20: URL: https://github.com/apache/maven-filtering/pull/20#issuecomment-986883963 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-filtering] slachiewicz closed pull request #23: Bump mockito-core from 2.28.2 to 4.1.0
slachiewicz closed pull request #23: URL: https://github.com/apache/maven-filtering/pull/23 -- 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-filtering] dependabot[bot] commented on pull request #19: Bump maven-shared-utils from 3.3.3 to 3.3.4
dependabot[bot] commented on pull request #19: URL: https://github.com/apache/maven-filtering/pull/19#issuecomment-986883686 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-filtering] slachiewicz closed pull request #20: Bump org.eclipse.sisu.plexus from 0.0.0.M2a to 0.3.5
slachiewicz closed pull request #20: URL: https://github.com/apache/maven-filtering/pull/20 -- 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-filtering] slachiewicz closed pull request #21: Bump commons-io from 2.6 to 2.11.0
slachiewicz closed pull request #21: URL: https://github.com/apache/maven-filtering/pull/21 -- 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-filtering] dependabot[bot] commented on pull request #21: Bump commons-io from 2.6 to 2.11.0
dependabot[bot] commented on pull request #21: URL: https://github.com/apache/maven-filtering/pull/21#issuecomment-986883592 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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-filtering] slachiewicz closed pull request #19: Bump maven-shared-utils from 3.3.3 to 3.3.4
slachiewicz closed pull request #19: URL: https://github.com/apache/maven-filtering/pull/19 -- 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
