[GitHub] [maven-assembly-plugin] roxspring opened a new pull request #32: [MASSEMBLY-939] - Line Aggregation Handlers support
roxspring opened a new pull request #32: URL: https://github.com/apache/maven-assembly-plugin/pull/32 - Add test for line aggregating behaviour - Line aggregating handler uses latest lastModified date and supporting `` - FileSelectors are always passed PlexusIoResource instances so that lastModified date is available Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MASSEMBLY) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MASSEMBLY-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MASSEMBLY-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MASSEMBLY-939) META-INF services aggregating invalidates updateOnly
Robert James Oxspring created MASSEMBLY-939: --- Summary: META-INF services aggregating invalidates updateOnly Key: MASSEMBLY-939 URL: https://issues.apache.org/jira/browse/MASSEMBLY-939 Project: Maven Assembly Plugin Issue Type: Bug Reporter: Robert James Oxspring When aggregating META-INF/services/ entries the merged entry effectively has a lastModified date of now. Consequently the logic always sees the sources as newer than the destination, and triggers unnecessary overwriting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRESOURCES-262) Update parent POM to 34
Elliotte Rusty Harold created MRESOURCES-262: Summary: Update parent POM to 34 Key: MRESOURCES-262 URL: https://issues.apache.org/jira/browse/MRESOURCES-262 Project: Maven Resources Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRESOURCES-261) Make Maven 3.1.0 the minimum version
Elliotte Rusty Harold created MRESOURCES-261: Summary: Make Maven 3.1.0 the minimum version Key: MRESOURCES-261 URL: https://issues.apache.org/jira/browse/MRESOURCES-261 Project: Maven Resources Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] michael-o commented on pull request #76: avoid trailing whitespace
michael-o commented on pull request #76: URL: https://github.com/apache/maven-dependency-plugin/pull/76#issuecomment-659041083 Completely forgot this. Please ping me by Friday. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158696#comment-17158696 ] Aaron Digulla commented on MRESOURCES-171: -- Another idea: Can we use the actual Properties class to load properties files? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPIR-397) dependency-management report fails on managed dependencies with 'null' version
[
https://issues.apache.org/jira/browse/MPIR-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158681#comment-17158681
]
Michael Osipov commented on MPIR-397:
-
Patches welcome!
> dependency-management report fails on managed dependencies with 'null' version
> --
>
> Key: MPIR-397
> URL: https://issues.apache.org/jira/browse/MPIR-397
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.7, 2.9, 3.0.0, 3.1.0
> Environment: Microsoft Windows 10, Maven 3.5.4, Azul OpenJDK8 or Azul
> OpenJDK7
>Reporter: Carsten Rohde
>Priority: Major
> Attachments: pirbug-aggregator.zip
>
>
> Maven allows to have managed dependencies without a version. This can be very
> useful, because this way you can change the scope of a transitive dependency
> without affecting the resolved version.
> The dependency-management report however fails under such circumstances:
> {code:java}
> Error generating
> maven-project-info-reports-plugin:3.1.0:dependency-management report: For
> artifact {pirbugdemo:pirbug-transitive:null:jar}: The version cannot be empty
> {code}
> There has been a similar issue with the versions-maven-plugin:
> https://github.com/mojohaus/versions-maven-plugin/issues/114
>
> The example mainly consists of a "consumer" module with a dependency to a
> "dependency" module wich in turn has a dependency to a third module
> "transitive". In the consumer module, the "transitive" dependency is managed
> without setting the version.
> If there is a workaround, please let me know.
>
> Thanks a lot!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-war-plugin] slachiewicz commented on pull request #18: [MWAR-438] update minimum Maven version to 3.1.0
slachiewicz commented on pull request #18: URL: https://github.com/apache/maven-war-plugin/pull/18#issuecomment-658973182 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MWAR-438) Make Maven 3.1.0 the minimum version
[ https://issues.apache.org/jira/browse/MWAR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MWAR-438. -- > Make Maven 3.1.0 the minimum version > > > Key: MWAR-438 > URL: https://issues.apache.org/jira/browse/MWAR-438 > Project: Maven WAR Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MWAR-438) Make Maven 3.1.0 the minimum version
[ https://issues.apache.org/jira/browse/MWAR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MWAR-438. Resolution: Fixed > Make Maven 3.1.0 the minimum version > > > Key: MWAR-438 > URL: https://issues.apache.org/jira/browse/MWAR-438 > Project: Maven WAR Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-war-plugin] elharo merged pull request #18: [MWAR-438] update minimum Maven version to 3.1.0
elharo merged pull request #18: URL: https://github.com/apache/maven-war-plugin/pull/18 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MEAR-282) Support data-source element
[
https://issues.apache.org/jira/browse/MEAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joeren Haag updated MEAR-282:
-
Description:
Since Version 6 and up to the latest Version of Java/Jakarta EE the data-source
element is defined in the Schema of the {{application.xml}} ([#1]). So it would
be nice to support the data-source element also in the configuration of the
maven-ear-plugin. Here is my actual workaround:
# enable the generation of {{application.xml}}
# move the generated {{application.xml}} to the source folder
{{src/main/application}}
# disable the generation of {{application.xml}}
# add the data-source configuration to {{application.xm}}
Here is a "simple example" of the data-source element (the example is based on
Version 8 of Java EE), like it's look in the {{application.xml}}:
{code:xml}
{code}
---
* {anchor:1} 1: application-schema for Java EE version 6 -
https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_6.xsd
was:
Since Version 6 and up to the latest Version of Java/Jakarta EE the data-source
element is defined in the Schema of the {{application.xml}} ([#1]). So it would
be nice to support the data-source element also in the configuration of the
maven-ear-plugin. Here is my actual workaround:
# enable the generation of {{application.xml}}
# move the generated {{application.xml}} to the source folder
{{src/main/application}}
# disable the generation of {{application.xml}}
Here is a "simple example" of the data-source element (the example is based on
Version 8 of Java EE), like it's look in the {{application.xml}}:
{code:xml}
{code}
---
* {anchor:1} 1: application-schema for Java EE version 6 -
https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_6.xsd
> Support data-source element
> ---
>
> Key: MEAR-282
> URL: https://issues.apache.org/jira/browse/MEAR-282
> Project: Maven Ear Plugin
> Issue Type: Wish
>Reporter: Joeren Haag
>Priority: Major
>
> Since Version 6 and up to the latest Version of Java/Jakarta EE the
> data-source element is defined in the Schema of the {{application.xml}}
> ([#1]). So it would be nice to support the data-source element also in the
> configuration of the maven-ear-plugin. Here is my actual workaround:
> # enable the generation of {{application.xml}}
> # move the generated {{application.xml}} to the source folder
> {{src/main/application}}
> # disable the generation of {{application.xml}}
> # add the data-source configuration to {{application.xm}}
> Here is a "simple example" of the data-source element (the example is based
> on Version 8 of Java EE), like it's look in the {{application.xml}}:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ---
> * {anchor:1} 1: application-schema for Java EE version 6 -
> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_6.xsd
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158636#comment-17158636
]
Hudson commented on MNG-5760:
-
Build succeeded in Jenkins: Maven TLP » maven » master #446
See https://builds.apache.org/job/maven-box/job/maven/job/master/446/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158617#comment-17158617 ] Dennis Lundberg commented on MRESOURCES-171: Great feedback guys! We are really getting closer to the best possible solution to a rather complicated situation. As [~afloom] points out the default for encoding ResourceBundles changed in Java 9 to UTF-8. But the Properties class still uses ISO-8859-1 when reading or writing properties files. https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Properties.html This means that we cannot base the plugin behavior on which version of java is being used, because it depends... Properties files for ResourceBundle should have one encoding and regular properties files should have another. No way we can automate the guesswork for that. I feel that [~digulla]s second approach is the best solution we can find, given the complexities at hand. I will go ahead with my original intent to add a new property called propertiesEncoding. If it is not set I will add a suitable WARNING in the log that it will be defaulting to whatever the encoding parameter is set to, because we want to be backwards compatible. I'll also link to a new page in the plugin site where I will try to describe the different scenarios possible when it comes to encoding and properties files, and how to configure the plugin properly. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] ThStock commented on pull request #76: avoid trailing whitespace
ThStock commented on pull request #76: URL: https://github.com/apache/maven-dependency-plugin/pull/76#issuecomment-658934157 Can I help in some way? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] MartinKanters commented on pull request #67: [MNG-5760] --resume feature (part 2)
MartinKanters commented on pull request #67: URL: https://github.com/apache/maven-integration-testing/pull/67#issuecomment-658933481 Merged in [2f1a9ef3a205dfe89c4a53c419c8f3f6c27c2f96](https://github.com/apache/maven-integration-testing/commit/2f1a9ef3a205dfe89c4a53c419c8f3f6c27c2f96) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] MartinKanters closed pull request #67: [MNG-5760] --resume feature (part 2)
MartinKanters closed pull request #67: URL: https://github.com/apache/maven-integration-testing/pull/67 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on pull request #363: [MNG-5760] --resume feature (part 2)
MartinKanters commented on pull request #363: URL: https://github.com/apache/maven/pull/363#issuecomment-658932830 Merged in [117cfde44e34a45f2b38929aa164e61650681aeb](https://github.com/apache/maven/commit/117cfde44e34a45f2b38929aa164e61650681aeb) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] MartinKanters closed pull request #363: [MNG-5760] --resume feature (part 2)
MartinKanters closed pull request #363: URL: https://github.com/apache/maven/pull/363 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MEAR-282) Support data-source element
Joeren Haag created MEAR-282:
Summary: Support data-source element
Key: MEAR-282
URL: https://issues.apache.org/jira/browse/MEAR-282
Project: Maven Ear Plugin
Issue Type: Wish
Reporter: Joeren Haag
Since Version 6 and up to the latest Version of Java/Jakarta EE the data-source
element is defined in the Schema of the {{application.xml}} ([#1]). So it would
be nice to support the data-source element also in the configuration of the
maven-ear-plugin. Here is my actual workaround:
# enable the generation of {{application.xml}}
# move the generated {{application.xml}} to the source folder
{{src/main/application}}
# disable the generation of {{application.xml}}
Here is a "simple example" of the data-source element (the example is based on
Version 8 of Java EE), like it's look in the {{application.xml}}:
{code:xml}
{code}
---
* {anchor:1} 1: application-schema for Java EE version 6 -
https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_6.xsd
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-909) Update maven-shared-utils 0.3 -> 3.2.1
[ https://issues.apache.org/jira/browse/MSHARED-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MSHARED-909. Resolution: Fixed > Update maven-shared-utils 0.3 -> 3.2.1 > -- > > Key: MSHARED-909 > URL: https://issues.apache.org/jira/browse/MSHARED-909 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-script-interpreter-1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-909) Update maven-shared-utils 0.3 -> 3.2.1
[ https://issues.apache.org/jira/browse/MSHARED-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158557#comment-17158557 ] Sylwester Lachiewicz commented on MSHARED-909: -- Done in [e75fb410551afd150942b16a8ae572cf19cba474|https://gitbox.apache.org/repos/asf?p=maven-script-interpreter.git;a=commit;h=e75fb410551afd150942b16a8ae572cf19cba474] > Update maven-shared-utils 0.3 -> 3.2.1 > -- > > Key: MSHARED-909 > URL: https://issues.apache.org/jira/browse/MSHARED-909 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-script-interpreter-1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-909) Update maven-shared-utils 0.3 -> 3.2.1
[ https://issues.apache.org/jira/browse/MSHARED-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-909: - Fix Version/s: maven-script-interpreter-1.3 > Update maven-shared-utils 0.3 -> 3.2.1 > -- > > Key: MSHARED-909 > URL: https://issues.apache.org/jira/browse/MSHARED-909 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-script-interpreter-1.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-910) Redundant option failOnException
[
https://issues.apache.org/jira/browse/MSHARED-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158555#comment-17158555
]
Sylwester Lachiewicz commented on MSHARED-910:
--
+1 please prepare PR
> Redundant option failOnException
>
>
> Key: MSHARED-910
> URL: https://issues.apache.org/jira/browse/MSHARED-910
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> In code of {{ScriptRunner}} we have:
> {code:java}
> if ( failOnException )
> {
> throw new RunFailureException( "The " + scriptDescription + " did not
> succeed. " + msg, stage );
> }
> else
> {
> throw new RunErrorException( "The " + scriptDescription + " did not
> succeed. " + msg, stage, t );
> }
> {code}
> This cause to only throw different exception, but in client code we should
> catch exception regardless of this option.
> I think that this complicate code of this class and code on client with
> process many exceptions.
> My proposition:
> - remove option {{failOnException}}
> - remove exceptions: {{RunFailureException}} and {{RunErrorException}}
> - throw by methods run, executeRun - {{ScriptEvaluationException}}
> I can do it - after your approval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHARED-909) Update maven-shared-utils 0.3 -> 3.2.1
[ https://issues.apache.org/jira/browse/MSHARED-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-909: Assignee: Sylwester Lachiewicz > Update maven-shared-utils 0.3 -> 3.2.1 > -- > > Key: MSHARED-909 > URL: https://issues.apache.org/jira/browse/MSHARED-909 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-script-interpreter >Reporter: Slawomir Jaranowski >Assignee: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-914) Detailed message from failed script evaluation shouldn't be propagated
[
https://issues.apache.org/jira/browse/MSHARED-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MSHARED-914.
Resolution: Fixed
> Detailed message from failed script evaluation shouldn't be propagated
> --
>
> Key: MSHARED-914
> URL: https://issues.apache.org/jira/browse/MSHARED-914
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> In class ScriptRunner when exception occur during script evaluate message
> from cause exception is propagated to generated exception.
> For groovy we have many details in message so if client library logs message
> from exception it is redundant.
> This datailed is stored in log file from execution. So if somebody also print
> content of logs, as maven-infoker with streamLogs, we have duplicated
> messages.
> This details is stored in log file from execution. So if somebody also print
> content of logs, as maven-invoker-plugin does with streamsLogs options, we
> have duplicate messages.
>
> Code to change:
> {code:java}
> catch ( ScriptEvaluationException e )
> {
> Throwable t = ( e.getCause() != null ) ? e.getCause() : e;
> String msg = ( t.getMessage() != null ) ? t.getMessage() : t.toString();
> if ( LOG.isDebugEnabled() )
> {
> String errorMessage = "Error evaluating " + scriptDescription + " " +
> scriptFile.getPath() + ", " + t;
> LOG.debug( errorMessage, t );
> }
> if ( logger != null )
> {
> t.printStackTrace( logger.getPrintStream() );
> }
> if ( failOnException )
> {
> throw new RunFailureException( "The " + scriptDescription + " did not
> succeed. " + msg, stage );
> }
> else
> {
> throw new RunErrorException( "The " + scriptDescription + " did not
> succeed. " + msg, stage, t );
> }
> } {code}
> {{msg}} variable and her usage should be removed.
>
> This resolve MINVOKER-265
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-914) Detailed message from failed script evaluation shouldn't be propagated
[
https://issues.apache.org/jira/browse/MSHARED-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MSHARED-914:
-
Fix Version/s: maven-script-interpreter-1.3
> Detailed message from failed script evaluation shouldn't be propagated
> --
>
> Key: MSHARED-914
> URL: https://issues.apache.org/jira/browse/MSHARED-914
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> In class ScriptRunner when exception occur during script evaluate message
> from cause exception is propagated to generated exception.
> For groovy we have many details in message so if client library logs message
> from exception it is redundant.
> This datailed is stored in log file from execution. So if somebody also print
> content of logs, as maven-infoker with streamLogs, we have duplicated
> messages.
> This details is stored in log file from execution. So if somebody also print
> content of logs, as maven-invoker-plugin does with streamsLogs options, we
> have duplicate messages.
>
> Code to change:
> {code:java}
> catch ( ScriptEvaluationException e )
> {
> Throwable t = ( e.getCause() != null ) ? e.getCause() : e;
> String msg = ( t.getMessage() != null ) ? t.getMessage() : t.toString();
> if ( LOG.isDebugEnabled() )
> {
> String errorMessage = "Error evaluating " + scriptDescription + " " +
> scriptFile.getPath() + ", " + t;
> LOG.debug( errorMessage, t );
> }
> if ( logger != null )
> {
> t.printStackTrace( logger.getPrintStream() );
> }
> if ( failOnException )
> {
> throw new RunFailureException( "The " + scriptDescription + " did not
> succeed. " + msg, stage );
> }
> else
> {
> throw new RunErrorException( "The " + scriptDescription + " did not
> succeed. " + msg, stage, t );
> }
> } {code}
> {{msg}} variable and her usage should be removed.
>
> This resolve MINVOKER-265
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-914) Detailed message from failed script evaluation shouldn't be propagated
[
https://issues.apache.org/jira/browse/MSHARED-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158552#comment-17158552
]
Sylwester Lachiewicz commented on MSHARED-914:
--
Done in
[a58c5d5c9f751ce6a2369396d03c40e79c0f4a3b|https://gitbox.apache.org/repos/asf?p=maven-script-interpreter.git;a=commit;h=a58c5d5c9f751ce6a2369396d03c40e79c0f4a3b]
> Detailed message from failed script evaluation shouldn't be propagated
> --
>
> Key: MSHARED-914
> URL: https://issues.apache.org/jira/browse/MSHARED-914
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> In class ScriptRunner when exception occur during script evaluate message
> from cause exception is propagated to generated exception.
> For groovy we have many details in message so if client library logs message
> from exception it is redundant.
> This datailed is stored in log file from execution. So if somebody also print
> content of logs, as maven-infoker with streamLogs, we have duplicated
> messages.
> This details is stored in log file from execution. So if somebody also print
> content of logs, as maven-invoker-plugin does with streamsLogs options, we
> have duplicate messages.
>
> Code to change:
> {code:java}
> catch ( ScriptEvaluationException e )
> {
> Throwable t = ( e.getCause() != null ) ? e.getCause() : e;
> String msg = ( t.getMessage() != null ) ? t.getMessage() : t.toString();
> if ( LOG.isDebugEnabled() )
> {
> String errorMessage = "Error evaluating " + scriptDescription + " " +
> scriptFile.getPath() + ", " + t;
> LOG.debug( errorMessage, t );
> }
> if ( logger != null )
> {
> t.printStackTrace( logger.getPrintStream() );
> }
> if ( failOnException )
> {
> throw new RunFailureException( "The " + scriptDescription + " did not
> succeed. " + msg, stage );
> }
> else
> {
> throw new RunErrorException( "The " + scriptDescription + " did not
> succeed. " + msg, stage, t );
> }
> } {code}
> {{msg}} variable and her usage should be removed.
>
> This resolve MINVOKER-265
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-914) Detailed message from failed script evaluation shouldn't be propagated
[
https://issues.apache.org/jira/browse/MSHARED-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158551#comment-17158551
]
Hudson commented on MSHARED-914:
Build succeeded in Jenkins: Maven TLP » maven-script-interpreter » master #43
See
https://builds.apache.org/job/maven-box/job/maven-script-interpreter/job/master/43/
> Detailed message from failed script evaluation shouldn't be propagated
> --
>
> Key: MSHARED-914
> URL: https://issues.apache.org/jira/browse/MSHARED-914
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> In class ScriptRunner when exception occur during script evaluate message
> from cause exception is propagated to generated exception.
> For groovy we have many details in message so if client library logs message
> from exception it is redundant.
> This datailed is stored in log file from execution. So if somebody also print
> content of logs, as maven-infoker with streamLogs, we have duplicated
> messages.
> This details is stored in log file from execution. So if somebody also print
> content of logs, as maven-invoker-plugin does with streamsLogs options, we
> have duplicate messages.
>
> Code to change:
> {code:java}
> catch ( ScriptEvaluationException e )
> {
> Throwable t = ( e.getCause() != null ) ? e.getCause() : e;
> String msg = ( t.getMessage() != null ) ? t.getMessage() : t.toString();
> if ( LOG.isDebugEnabled() )
> {
> String errorMessage = "Error evaluating " + scriptDescription + " " +
> scriptFile.getPath() + ", " + t;
> LOG.debug( errorMessage, t );
> }
> if ( logger != null )
> {
> t.printStackTrace( logger.getPrintStream() );
> }
> if ( failOnException )
> {
> throw new RunFailureException( "The " + scriptDescription + " did not
> succeed. " + msg, stage );
> }
> else
> {
> throw new RunErrorException( "The " + scriptDescription + " did not
> succeed. " + msg, stage, t );
> }
> } {code}
> {{msg}} variable and her usage should be removed.
>
> This resolve MINVOKER-265
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-script-interpreter] asfgit closed pull request #6: [MSHARED-914] Detailed message from failed script shouldn't be propagated
asfgit closed pull request #6: URL: https://github.com/apache/maven-script-interpreter/pull/6 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158539#comment-17158539 ] Aaron Digulla commented on MRESOURCES-171: -- [~afloom] Thanks for the update. (screaming and cursing in the background). Ahem. Seems like a bad situation got worse. One way to attack this: Determine Java version and set the default accordingly (ISO for < Java 9, UTF-8 for everything later). Log the setting to the console so developers notice that something is happening. But a better approach would be to add a new property and print a warning when it's not set (that's what happening when source encoding is missing, IIRC). That would allow us to print a link to a web page with instructions. I think the last option is best: It makes the problem obvious (especially for those so far oblivious to it), it will help those who have installed workarounds and we can explain what's going on AND give suggestions for common cases. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-917) Remove dependency to plexus-component-annotations
[
https://issues.apache.org/jira/browse/MSHARED-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MSHARED-917.
Resolution: Fixed
> Remove dependency to plexus-component-annotations
> -
>
> Key: MSHARED-917
> URL: https://issues.apache.org/jira/browse/MSHARED-917
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> We have defined as plexus component:
> - {{BeanShellScriptInterpreter}}
> - {{GroovyScriptInterpreter}}
> But class {{ScriptRunner}} isn't plexus component.
> I have searched github for using of this classes:
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.BeanShellScriptInterpreter%22=Code
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter%22=Code
> And seems like nobody use this in direct way.
> In more I think that this class should be private for project.
> Those are used internally for wrap specific interpreter.
> I'm waiting for opinion / approve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-917) Remove dependency to plexus-component-annotations
[
https://issues.apache.org/jira/browse/MSHARED-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158535#comment-17158535
]
Hudson commented on MSHARED-917:
Build succeeded in Jenkins: Maven TLP » maven-script-interpreter » master #42
See
https://builds.apache.org/job/maven-box/job/maven-script-interpreter/job/master/42/
> Remove dependency to plexus-component-annotations
> -
>
> Key: MSHARED-917
> URL: https://issues.apache.org/jira/browse/MSHARED-917
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> We have defined as plexus component:
> - {{BeanShellScriptInterpreter}}
> - {{GroovyScriptInterpreter}}
> But class {{ScriptRunner}} isn't plexus component.
> I have searched github for using of this classes:
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.BeanShellScriptInterpreter%22=Code
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter%22=Code
> And seems like nobody use this in direct way.
> In more I think that this class should be private for project.
> Those are used internally for wrap specific interpreter.
> I'm waiting for opinion / approve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-917) Remove dependency to plexus-component-annotations
[
https://issues.apache.org/jira/browse/MSHARED-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158528#comment-17158528
]
Sylwester Lachiewicz commented on MSHARED-917:
--
Done in
[1ed8fe2210adf1ab0f323dbc6567138233ae61a2|https://gitbox.apache.org/repos/asf?p=maven-script-interpreter.git;a=commit;h=1ed8fe2210adf1ab0f323dbc6567138233ae61a2]
> Remove dependency to plexus-component-annotations
> -
>
> Key: MSHARED-917
> URL: https://issues.apache.org/jira/browse/MSHARED-917
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> We have defined as plexus component:
> - {{BeanShellScriptInterpreter}}
> - {{GroovyScriptInterpreter}}
> But class {{ScriptRunner}} isn't plexus component.
> I have searched github for using of this classes:
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.BeanShellScriptInterpreter%22=Code
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter%22=Code
> And seems like nobody use this in direct way.
> In more I think that this class should be private for project.
> Those are used internally for wrap specific interpreter.
> I'm waiting for opinion / approve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-script-interpreter] slachiewicz merged pull request #5: [MSHARED-917] Remove dependency to plexus-component-annotations
slachiewicz merged pull request #5: URL: https://github.com/apache/maven-script-interpreter/pull/5 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-917) Remove dependency to plexus-component-annotations
[
https://issues.apache.org/jira/browse/MSHARED-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MSHARED-917:
-
Fix Version/s: maven-script-interpreter-1.3
> Remove dependency to plexus-component-annotations
> -
>
> Key: MSHARED-917
> URL: https://issues.apache.org/jira/browse/MSHARED-917
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-script-interpreter-1.3
>
>
> We have defined as plexus component:
> - {{BeanShellScriptInterpreter}}
> - {{GroovyScriptInterpreter}}
> But class {{ScriptRunner}} isn't plexus component.
> I have searched github for using of this classes:
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.BeanShellScriptInterpreter%22=Code
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter%22=Code
> And seems like nobody use this in direct way.
> In more I think that this class should be private for project.
> Those are used internally for wrap specific interpreter.
> I'm waiting for opinion / approve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHARED-917) Remove dependency to plexus-component-annotations
[
https://issues.apache.org/jira/browse/MSHARED-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MSHARED-917:
Assignee: Sylwester Lachiewicz
> Remove dependency to plexus-component-annotations
> -
>
> Key: MSHARED-917
> URL: https://issues.apache.org/jira/browse/MSHARED-917
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> We have defined as plexus component:
> - {{BeanShellScriptInterpreter}}
> - {{GroovyScriptInterpreter}}
> But class {{ScriptRunner}} isn't plexus component.
> I have searched github for using of this classes:
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.BeanShellScriptInterpreter%22=Code
> https://github.com/search?q=%22org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter%22=Code
> And seems like nobody use this in direct way.
> In more I think that this class should be private for project.
> Those are used internally for wrap specific interpreter.
> I'm waiting for opinion / approve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOURCES-260) copy-resources goal copies directories, but not files
[
https://issues.apache.org/jira/browse/MRESOURCES-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158512#comment-17158512
]
Alan Czajkowski edited comment on MRESOURCES-260 at 7/15/20, 4:38 PM:
--
[~hboutemy] you are correct, i did hit the MWAR-433 bug, and upgrading the WAR
plugin to 3.3.1 did resolve the issue
was (Author: alan-czajkowski):
[~hboutemy] you are correct, i did hit the
[MWAR-433|https://issues.apache.org/jira/browse/MWAR-433] bug, and upgrading
the WAR plugin to 3.3.1 did resolve the issue
> copy-resources goal copies directories, but not files
> -
>
> Key: MRESOURCES-260
> URL: https://issues.apache.org/jira/browse/MRESOURCES-260
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Assignee: Herve Boutemy
>Priority: Major
>
> h2. Background
> the sample application source code can be found here:
> https://gitlab.com/openease/java-microservice-example
> this is a peculiar bug that is confusing me because the functionality works
> sometimes, but not always
> my machine:
> {code:bash}
> $ mvn -v
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
> {code}
> The project, mentioned above, is a multi-module project that does a lot of
> things. One of the modules builds a Spring Boot WAR bundled _together_ with a
> NPM application:
>
> [https://gitlab.com/openease/java-microservice-example/-/blob/master/service/www/pom.xml]
> the contents of the NPM build output is copied into the WAR package with the
> following execution:
> {code:xml}
>
> copy-javascript-build-output-to-webapp
> prepare-package
>
> copy-resources
>
>
>
>
> ${project.build.directory}/javascript/build
> false
>
> **/*.css*
> **/*.htm*
> **/*.js*
> **/*.png*
> **/*.svg*
> **/*.txt*
>
>
>
>
> ${project.build.directory}/${project.build.finalName}/WEB-INF/classes/public
>
>
> {code}
> h2. Problem
> This execution works fine when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean prepare-package
> {code}
> it copies over all of the NPM build output contents (directories and files)
> but this execution fails when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean install
> {code}
> it copies over only the directory structure, but no files:
> {code}
> target/
> java-microservice-example-service-www-1.0.0-SNAPSHOT/
> WEB-INF/
> classes/
> public/ (no files)
> static/
> css/ (no files)
> js/ (no files)
> media/ (no files)
> {code}
> I believe the other executions defined in the {{pom.xml}} don't seem to have
> a problem, just this one ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-260) copy-resources goal copies directories, but not files
[
https://issues.apache.org/jira/browse/MRESOURCES-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158512#comment-17158512
]
Alan Czajkowski commented on MRESOURCES-260:
[~hboutemy] you are correct, i did hit the
[MWAR-433|https://issues.apache.org/jira/browse/MWAR-433] bug, and upgrading
the WAR plugin to 3.3.1 did resolve the issue
> copy-resources goal copies directories, but not files
> -
>
> Key: MRESOURCES-260
> URL: https://issues.apache.org/jira/browse/MRESOURCES-260
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Assignee: Herve Boutemy
>Priority: Major
>
> h2. Background
> the sample application source code can be found here:
> https://gitlab.com/openease/java-microservice-example
> this is a peculiar bug that is confusing me because the functionality works
> sometimes, but not always
> my machine:
> {code:bash}
> $ mvn -v
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
> {code}
> The project, mentioned above, is a multi-module project that does a lot of
> things. One of the modules builds a Spring Boot WAR bundled _together_ with a
> NPM application:
>
> [https://gitlab.com/openease/java-microservice-example/-/blob/master/service/www/pom.xml]
> the contents of the NPM build output is copied into the WAR package with the
> following execution:
> {code:xml}
>
> copy-javascript-build-output-to-webapp
> prepare-package
>
> copy-resources
>
>
>
>
> ${project.build.directory}/javascript/build
> false
>
> **/*.css*
> **/*.htm*
> **/*.js*
> **/*.png*
> **/*.svg*
> **/*.txt*
>
>
>
>
> ${project.build.directory}/${project.build.finalName}/WEB-INF/classes/public
>
>
> {code}
> h2. Problem
> This execution works fine when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean prepare-package
> {code}
> it copies over all of the NPM build output contents (directories and files)
> but this execution fails when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean install
> {code}
> it copies over only the directory structure, but no files:
> {code}
> target/
> java-microservice-example-service-www-1.0.0-SNAPSHOT/
> WEB-INF/
> classes/
> public/ (no files)
> static/
> css/ (no files)
> js/ (no files)
> media/ (no files)
> {code}
> I believe the other executions defined in the {{pom.xml}} don't seem to have
> a problem, just this one ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-258) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MRESOURCES-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158482#comment-17158482
]
Robert James Oxspring commented on MRESOURCES-258:
--
Note that this is effectively fixed by the commit below, but we need to release
maven-shared-utils, bump maven-filtering to use that and release, bump
maven-resources-plugin to use that.
https://github.com/apache/maven-shared-utils/commit/e57180309a64758e161513d80f1185e13dc84826
> Only overwrite filtered resources when contents differ
> --
>
> Key: MRESOURCES-258
> URL: https://issues.apache.org/jira/browse/MRESOURCES-258
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Robert James Oxspring
>Priority: Major
>
> When using {{mvn resources:copy-resources}} with filtering enabled, the
> destination file should only be overwritten if the contents have changed.
> Given a {{mvn resources:copy-resources}} call with filtering configured
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should remain unmodified
> Given a {{mvn resources:copy-resources}} call with filtering configured and
> {{overwrite}} set {{true}}
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should be overwritten
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-884) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MSHARED-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158481#comment-17158481
]
Robert James Oxspring commented on MSHARED-884:
---
Note that this is fixed in master and just awaiting a release:
https://github.com/apache/maven-shared-utils/commit/e57180309a64758e161513d80f1185e13dc84826
> Only overwrite filtered resources when contents differ
> --
>
> Key: MSHARED-884
> URL: https://issues.apache.org/jira/browse/MSHARED-884
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
>
> When filtering files with the {{MavenFileFilter.copyFile}} method, the
> destination file should only be overwritten if the contents have changed.
> Currently we unconditionally overwrite the contents in this situation,
> potentially leading to unnecessary downstream work. When the {{overwrite}}
> parameter is {{true}} then overwriting should overwrite as it does now.
> Given a {{copyFile}} call
> When an identical {{copyFile}} operation is performed
> Then the destination file should remain unmodified
> Given a {{copyFile}} call with {{overwrite}} set {{true}}
> When an identical {{copyFile}} operation is performed
> Then the destination file should be overwritten
> The [linked pull request|https://github.com/apache/maven-filtering/pull/5]
> meets these requirements by writing the filtered resource to a temporary file
> and then comparing the temporary contents to the content of a previously
> written target file. If the contents match then the temporary file is
> deleted, otherwise it's renamed over the top of the target file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-258) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MRESOURCES-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert James Oxspring updated MRESOURCES-258:
-
Affects Version/s: 3.1.0
> Only overwrite filtered resources when contents differ
> --
>
> Key: MRESOURCES-258
> URL: https://issues.apache.org/jira/browse/MRESOURCES-258
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Robert James Oxspring
>Priority: Major
>
> When using {{mvn resources:copy-resources}} with filtering enabled, the
> destination file should only be overwritten if the contents have changed.
> Given a {{mvn resources:copy-resources}} call with filtering configured
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should remain unmodified
> Given a {{mvn resources:copy-resources}} call with filtering configured and
> {{overwrite}} set {{true}}
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should be overwritten
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPIR-397) dependency-management report fails on managed dependencies with 'null' version
Carsten Rohde created MPIR-397:
--
Summary: dependency-management report fails on managed
dependencies with 'null' version
Key: MPIR-397
URL: https://issues.apache.org/jira/browse/MPIR-397
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-management
Affects Versions: 3.1.0, 3.0.0, 2.9, 2.7
Environment: Microsoft Windows 10, Maven 3.5.4, Azul OpenJDK8 or Azul
OpenJDK7
Reporter: Carsten Rohde
Attachments: pirbug-aggregator.zip
Maven allows to have managed dependencies without a version. This can be very
useful, because this way you can change the scope of a transitive dependency
without affecting the resolved version.
The dependency-management report however fails under such circumstances:
{code:java}
Error generating maven-project-info-reports-plugin:3.1.0:dependency-management
report: For artifact {pirbugdemo:pirbug-transitive:null:jar}: The version
cannot be empty
{code}
There has been a similar issue with the versions-maven-plugin:
https://github.com/mojohaus/versions-maven-plugin/issues/114
The example mainly consists of a "consumer" module with a dependency to a
"dependency" module wich in turn has a dependency to a third module
"transitive". In the consumer module, the "transitive" dependency is managed
without setting the version.
If there is a workaround, please let me know.
Thanks a lot!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1821) Broken junit report when parallel and rerunFailingTestsCount configureation is used
[
https://issues.apache.org/jira/browse/SUREFIRE-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pustovoyt updated SUREFIRE-1821:
--
Component/s: Junit 4.7+ (parallel) support
> Broken junit report when parallel and rerunFailingTestsCount configureation
> is used
> ---
>
> Key: SUREFIRE-1821
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1821
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.2, 3.0.0-M5
>Reporter: Pavel Pustovoyt
>Priority: Major
>
> *Description:*
> When using *parallel* configuration with *rerunFailingTestsCount* bad xml
> report is generated for a failing test.
> *How to reproduce:*
> 1. Configure forkCount, parallel and rerun count:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
>
> test
>
>
>
>
> 1
> 1
> 1
> all
> true
>
>
> {code}
> 2. Create a failing test that outputs more than 1m characters:
> {code:java}
> public class AppTest {
> @Test
> public void testBug() {
> for(int i = 0; i < 10; i++){
> System.out.println("Some output longer than 10 character");
> }
> throw new NullPointerException();
> }
> }
> {code}
> 3. Run the test and check the report - you will see unexpected end of xml
> file:
> {code:java}
> ...
>
>
>
>
> type="java.lang.NullPointerException">
>
[jira] [Commented] (ARCHETYPE-443) User defined properties are asked for in alphabetical order
[ https://issues.apache.org/jira/browse/ARCHETYPE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158175#comment-17158175 ] Michael Osipov commented on ARCHETYPE-443: -- Provide the easy fix, please. > User defined properties are asked for in alphabetical order > --- > > Key: ARCHETYPE-443 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-443 > Project: Maven Archetype > Issue Type: Bug > Components: Generator > Environment: Maven 3.0.5 >Reporter: Mikael Ståldal >Priority: Minor > > I have an archetype with some properties which Maven asks for > when instantiating the archetype. From archetype-metadata.xml: > > > > > > The problem is that it asks for the properties in another order than > specified in the file, it seems to be in alphabetical order. > I expect it to ask for the properties in the same order as specified in > archetype-metadata.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158174#comment-17158174 ] Anders Hammar commented on MRESOURCES-171: -- [~digulla] Starting with Java 9, UTF-8 is the default for property files used with resource bundles. See Oracle's documentation [https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-974CF488-23E8-4963-A322-82006A7A14C7]. So we can't just assume that a file with the .properties extension should be ISO-8859-1. (A file used with the Properties class should typically be ISO-8859-1 though.) > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-443) User defined properties are asked for in alphabetical order
[ https://issues.apache.org/jira/browse/ARCHETYPE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158166#comment-17158166 ] Chris McFarland commented on ARCHETYPE-443: --- This is a significant but w/ an easy fix. Why close it? You will be doing the community a great service by knocking this bug out. > User defined properties are asked for in alphabetical order > --- > > Key: ARCHETYPE-443 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-443 > Project: Maven Archetype > Issue Type: Bug > Components: Generator > Environment: Maven 3.0.5 >Reporter: Mikael Ståldal >Priority: Minor > > I have an archetype with some properties which Maven asks for > when instantiating the archetype. From archetype-metadata.xml: > > > > > > The problem is that it asks for the properties in another order than > specified in the file, it seems to be in alphabetical order. > I expect it to ask for the properties in the same order as specified in > archetype-metadata.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158151#comment-17158151 ] Dennis Lundberg commented on MRESOURCES-171: [~afloom] While I agree that convention over configuration is good, I feel that automatic detection is out of scope for this particular issue. This issue currently affects anyone having project.build.sourceEncoding=UTF-8 and filtering properties files (encoded in ISO-8859-1) containing non-ascii content. Thanks for your feedback [~digulla]. Are you suggesting that the proposed new parameter "propertiesEncoding" should default to ISO-8859-1 instead of project.build.sourceEncoding? That would be good for those who haven't yet discovered that their properties files are being mangled if filtered. It also means that we are changing the behavior of the plugin, but to a more correct one. Those who have implemented their own UTF-8-aware properties file handling will need to change manually set propertiesEncoding to UTF-8. But I suspect those are in minority here. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MGPG-79) plugin hangs on first run on Windows Git Bash with Kleopatra
[
https://issues.apache.org/jira/browse/MGPG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158150#comment-17158150
]
Leonhardt Wille commented on MGPG-79:
-
I hope you're all well! Is there any progress on this matter? I couldn't find
any further communication about restarting the release vote after closing
MGPG-78.
> plugin hangs on first run on Windows Git Bash with Kleopatra
>
>
> Key: MGPG-79
> URL: https://issues.apache.org/jira/browse/MGPG-79
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0 (cancelled)
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.0.2
>
> Attachments: gpg_jstack.log, procexplr.PNG
>
>
> found during release 3.0.0 vote:
> [https://lists.apache.org/thread.html/r855a3f8d4b161da297191e5a7ce0e7e5be81895e60fe5b7be16cc604%40%3Cdev.maven.apache.org%3E]
> {quote}the plugin simply hangs and does not continue if I use 3.0.0 after
> starting Kleopatra (https://docs.kde.org/stable5/en/pim/kleopatra/).
> When I first use 1.6 of the plugin after starting Kleopatra, the
> password dialog pops up (as ususal), the files are signed *and after
> this I am able to use 3.0.0 just fine!*
> So with 3.0.0 the initial communication with the agent seems to be broken...
> $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\_dev\Maven\latest
> Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\latest
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> $ gpg --version
> gpg (GnuPG) 2.2.19-unknown
> libgcrypt 1.8.5
> Git Bash.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158128#comment-17158128 ] Aaron Digulla commented on MRESOURCES-171: -- Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1821) Broken junit report when parallel and rerunFailingTestsCount configureation is used
[
https://issues.apache.org/jira/browse/SUREFIRE-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pustovoyt updated SUREFIRE-1821:
--
Summary: Broken junit report when parallel and rerunFailingTestsCount
configureation is used (was: Broken junit report when parallel and
rerunFailingTestsCount is used)
> Broken junit report when parallel and rerunFailingTestsCount configureation
> is used
> ---
>
> Key: SUREFIRE-1821
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1821
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.2, 3.0.0-M5
>Reporter: Pavel Pustovoyt
>Priority: Major
>
> *Description:*
> When using *parallel* configuration with *rerunFailingTestsCount* bad xml
> report is generated for a failing test.
> *How to reproduce:*
> 1. Configure forkCount, parallel and rerun count:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
>
> test
>
>
>
>
> 1
> 1
> 1
> all
> true
>
>
> {code}
> 2. Create a failing test that outputs more than 1m characters:
> {code:java}
> public class AppTest {
> @Test
> public void testBug() {
> for(int i = 0; i < 10; i++){
> System.out.println("Some output longer than 10 character");
> }
> throw new NullPointerException();
> }
> }
> {code}
> 3. Run the test and check the report - you will see unexpected end of xml
> file:
> {code:java}
> ...
>
>
>
>
> type="java.lang.NullPointerException">
>
[jira] [Created] (SUREFIRE-1821) Broken junit report when parallel and rerunFailingTestsCount is used
Pavel Pustovoyt created SUREFIRE-1821:
-
Summary: Broken junit report when parallel and
rerunFailingTestsCount is used
Key: SUREFIRE-1821
URL: https://issues.apache.org/jira/browse/SUREFIRE-1821
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 3.0.0-M5, 2.22.2, 2.20.1
Reporter: Pavel Pustovoyt
*Description:*
When using *parallel* configuration with *rerunFailingTestsCount* bad xml
report is generated for a failing test.
*How to reproduce:*
1. Configure forkCount, parallel and rerun count:
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M5
test
1
1
1
all
true
{code}
2. Create a failing test that outputs more than 1m characters:
{code:java}
public class AppTest {
@Test
public void testBug() {
for(int i = 0; i < 10; i++){
System.out.println("Some output longer than 10 character");
}
throw new NullPointerException();
}
}
{code}
3. Run the test and check the report - you will see unexpected end of xml file:
{code:java}
...
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158128#comment-17158128 ] Aaron Digulla edited comment on MRESOURCES-171 at 7/15/20, 12:40 PM: - Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. Frankly, even many developers in Europe don't understand the problem (just look at the comments here where people argue UFT-8 is good/better/valid when it's clearly not). ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. If people really don't like it, they can stay with the old version of the plugin. That's just a two minute change in the POM. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? was (Author: digulla): Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >
[jira] [Commented] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158130#comment-17158130
]
Dennis Lundberg commented on MRESOURCES-232:
Could you please add a reference to where in the documentation it states that
encoding can be changed during filtering, so that we can correct that. With the
current implementation that is not possible.
Do you have a use case where you want the source-resources to be one encoding
and the target-resources be another encoding?
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
> Labels: maven
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] elharo commented on pull request #52: update surefire
elharo commented on pull request #52: URL: https://github.com/apache/maven-archetype/pull/52#issuecomment-658735844 You'd have to ask whoever wrote this originally. This PR simply updates the version. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6949) As a developer on Maven Core I would like to verify my build before merge
[ https://issues.apache.org/jira/browse/MNG-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158113#comment-17158113 ] Hudson commented on MNG-6949: - Build succeeded in Jenkins: Maven TLP » maven » master #445 See https://builds.apache.org/job/maven-box/job/maven/job/master/445/ > As a developer on Maven Core I would like to verify my build before merge > - > > Key: MNG-6949 > URL: https://issues.apache.org/jira/browse/MNG-6949 > Project: Maven > Issue Type: Improvement >Reporter: Martin Kanters >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > > One of the requirements before providing a pull request to Maven is that you > have to run `mvn verify` and the integration tests. This is to ensure that > the PR that is delivered is of good quality. I do not disagree with this > approach, but it can be easy to forget to run this, especially in the case of > processing (small) review comments. > For me it already happened a couple of times that a failing test was found at > the time when the pull request was getting merged in master. By utilizing > GitHub Actions we can ensure that the PR's requirements are fulfilled. This > is meant as an addition on top of local tests and the CI job on Jenkins tests > that commiters execute during merger, not a replacement. > > I have implemented this last weekend and would like to propose this. It is > based on another Maven project's GitHub Action workflow, but has been > extended. It features the following: > # mvn verify on Ubuntu, Windows and MacOS machines, with Java 8, 11, 14. > # integration tests against the new Maven build (from step 1). > By default it will run against the latest master version of > apache/maven-integration-testing. > However, if the developer has a branch with the same name as the maven PR on > a forked maven-integration-testing project, it will check that out instead. > Link to the pull request: [https://github.com/apache/maven/pull/365]. > Currently the action is not running on the PR itself, I guess that is due to > settings in the apache/maven project. > It is running on the branch of our fork, though: > [https://github.com/infosupport/maven/actions/runs/150771674]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158106#comment-17158106
]
Aaron Digulla commented on MRESOURCES-171:
--
[~afloom] and others: The encoding of property files is defined by the Java TCK
and the default *MUST BE ISO-8859-1.* UTF-8 or anything else IS NOT VALID.
That's what this bug is about: *The Java standard* *says ISO-8859-1* (which is
a bad choice IMHO but that's what it is). This is true for ALL JAVA versions
from 1.0 to 11. A lot of people are suprised by this but there is really no way
around it.
[From the docs
(again)|https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html]:
{quote}the input/output stream is encoded in ISO 8859-1 character encoding.
{quote}
Note: this is not true when you use XML to serialize the properties, only for
the old *.properties files. If you want UTF-8, I suggest you load/save as XML,
that avoids a whole load of trouble plus has some nice features like nesting
paths and comments everywhere.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158089#comment-17158089 ] Anders Hammar commented on MRESOURCES-171: -- I very much like convention over configuration, so it would be nice if we just handled properties files (and other files like xml files) correctly without user configuration. But, we should also strive for backwards compatibility. So what I'm thinking is, does it make sense to change the encoding of a file during filtering? If we can figure out the encoding of the original file, shouldn't we use that encoding when writing the filtered (output) file and not use some configured value (that could be used a fall-back if not possible to decide)? I'm thinking about a solution similar to JEP 226 (as we should support Java 8 as well we can't use that impl). So, treat *.properties as UTF-8 but if we get a MalformedInputException or an UnmappableCharacterException we use ISO-8859-1. Something like that. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-253) Convention over configuration of filtered resources
[
https://issues.apache.org/jira/browse/MRESOURCES-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158083#comment-17158083
]
Hüseyin Kartal commented on MRESOURCES-253:
---
I agree your assumption.
> Convention over configuration of filtered resources
> ---
>
> Key: MRESOURCES-253
> URL: https://issues.apache.org/jira/browse/MRESOURCES-253
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Hüseyin Kartal
>Priority: Major
>
> We would appreciate if there would be a convention for a resource folder that
> is filtered by convention. Like "resources-filtered" for main and test
> resources. Just omit bloated configurations.
> {{}}
> {{ }}
> {{ ${project.basedir}/src/main/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/main/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ ${project.basedir}/src/test/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/test/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MWRAPPER-5) Hardcoded maven-wrapper.jar path
Jorge Solorzano created MWRAPPER-5:
--
Summary: Hardcoded maven-wrapper.jar path
Key: MWRAPPER-5
URL: https://issues.apache.org/jira/browse/MWRAPPER-5
Project: Maven Wrapper
Issue Type: Wish
Affects Versions: 3.0.1
Environment: Linux
Reporter: Jorge Solorzano
Not sure how it will work on 3.7.0, but the current Takari maven wrapper has
the jar path hardcoded in the script and in the download java class:
{color:#c586c0}if{color}{color:#d4d4d4} [ -r
{color}{color:#ce9178}"{color}{color:#9cdcfe}$BASE_DIR{color}{color:#ce9178}/.mvn/wrapper/maven-wrapper.jar"{color}{color:#d4d4d4}
]; {color}{color:#c586c0}then{color}
This has the problem in projects that prohibit checking binary data, the
strange thing is that when Maven is being downloaded the extracted zip goes to
\{user.home}/.m2/wrapper/dists/...
So what I propose is that the maven-wrapper.jar can also be downloaded in that
directory avoiding to download that jar in every project and also be able to
change that directory with properties or env variables like how is now possible
with MAVEN_USER_HOME=.m2/, this would definitely help with caching in CI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158027#comment-17158027 ] Dennis Lundberg commented on MRESOURCES-171: We have the need at my dayjob to get this fixed. I will be working on a solution for this starting now. Currently I am reading up on what has already been written in this and other related issues. My initial instinct is to add a configuration parameter to be able to specify the encoding for properties-files only. The default value for it can be discussed, but to keep backwards compatibility it should default to the value of the regular encoding parameter. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-253) Convention over configuration of filtered resources
[
https://issues.apache.org/jira/browse/MRESOURCES-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17157997#comment-17157997
]
Dennis Lundberg commented on MRESOURCES-253:
Am I correct in assuming that the fix for MNG-2478 resolves this issue?
> Convention over configuration of filtered resources
> ---
>
> Key: MRESOURCES-253
> URL: https://issues.apache.org/jira/browse/MRESOURCES-253
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Hüseyin Kartal
>Priority: Major
>
> We would appreciate if there would be a convention for a resource folder that
> is filtered by convention. Like "resources-filtered" for main and test
> resources. Just omit bloated configurations.
> {{}}
> {{ }}
> {{ ${project.basedir}/src/main/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/main/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ ${project.basedir}/src/test/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/test/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-integration-testing] MartinKanters commented on a change in pull request #67: [MNG-5760] --resume feature (part 2)
MartinKanters commented on a change in pull request #67:
URL:
https://github.com/apache/maven-integration-testing/pull/67#discussion_r454879619
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5760ResumeFeatureTest.java
##
@@ -40,19 +40,26 @@
* @author Martin Kanters
*/
public class MavenITmng5760ResumeFeatureTest extends
AbstractMavenIntegrationTestCase {
-private final File testDir;
+private final File parentDependentTestDir;
+private final File parentIndependentTestDir;
+private final File noProjectTestDir;
public MavenITmng5760ResumeFeatureTest() throws IOException {
super( "[3.7.0,)" );
-this.testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-5760-resume-feature" );
+this.parentDependentTestDir =
ResourceExtractor.simpleExtractResources( getClass(),
+"/mng-5760-resume-feature/parent-dependent" );
+this.parentIndependentTestDir =
ResourceExtractor.simpleExtractResources( getClass(),
+"/mng-5760-resume-feature/parent-independent" );
+this.noProjectTestDir = ResourceExtractor.simpleExtractResources(
getClass(),
+"/mng-5760-resume-feature/no-project" );
Review comment:
I think we are missing these files.
After squashing and merging this branch to Apache, the GitHub Actions
pipeline was failing:
https://github.com/apache/maven/runs/872356902?check_suite_focus=true
`testShouldSkipSuccessfulProjects (java.lang.IllegalArgumentException:
Resource not found: /mng-5760-resume-feature/no-project`
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Moved] (ARCHETYPE-603) on archetype:create-from-project does not copying .gitignore file to archetype
[ https://issues.apache.org/jira/browse/ARCHETYPE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MRESOURCES-238 to ARCHETYPE-603: -- Key: ARCHETYPE-603 (was: MRESOURCES-238) Affects Version/s: (was: 3.0.2) (was: 3.0.1) (was: 3.0.0) 3.0.0 3.0.1 Project: Maven Archetype (was: Maven Resources Plugin) > on archetype:create-from-project does not copying .gitignore file to archetype > -- > > Key: ARCHETYPE-603 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-603 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 3.0.1, 3.0.0 >Reporter: Ebuzer taha kanat >Priority: Major > > false > or > > > > > > .*ignore > > > > > not solving the problem either -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-714) runtime dependencies reported as unused
[
https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17157965#comment-17157965
]
Michael Osipov commented on MDEP-714:
-
This has always be a problem, for instance when used in Spring {{beans.xml}}. I
wouldn't generally remove this, but either improve it or document this issue.
> runtime dependencies reported as unused
> ---
>
> Key: MDEP-714
> URL: https://issues.apache.org/jira/browse/MDEP-714
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Typical output when analyzing the maven-archetype-plugin:
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime
> However since this is needed at runtime, possibly via reflection, it seems
> likely that it is used but the dependency analyzer can't figure this out.
> Confirm and consider whether the plugin should simply never report runtime
> dependencies as unused.
> This is tricky because it's certainly possible that a runtime dependency is
> unused, but in practice it seems more likely than not to be a false positive.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOURCES-260) copy-resources goal copies directories, but not files
[
https://issues.apache.org/jira/browse/MRESOURCES-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MRESOURCES-260.
Assignee: Herve Boutemy
Resolution: Invalid
looks like you are hit by MWAR-433
please upgrade maven-war-plugin to 3.3.1 and the issue should be gone
> copy-resources goal copies directories, but not files
> -
>
> Key: MRESOURCES-260
> URL: https://issues.apache.org/jira/browse/MRESOURCES-260
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Assignee: Herve Boutemy
>Priority: Major
>
> h2. Background
> the sample application source code can be found here:
> https://gitlab.com/openease/java-microservice-example
> this is a peculiar bug that is confusing me because the functionality works
> sometimes, but not always
> my machine:
> {code:bash}
> $ mvn -v
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 11.0.7, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
> {code}
> The project, mentioned above, is a multi-module project that does a lot of
> things. One of the modules builds a Spring Boot WAR bundled _together_ with a
> NPM application:
>
> [https://gitlab.com/openease/java-microservice-example/-/blob/master/service/www/pom.xml]
> the contents of the NPM build output is copied into the WAR package with the
> following execution:
> {code:xml}
>
> copy-javascript-build-output-to-webapp
> prepare-package
>
> copy-resources
>
>
>
>
> ${project.build.directory}/javascript/build
> false
>
> **/*.css*
> **/*.htm*
> **/*.js*
> **/*.png*
> **/*.svg*
> **/*.txt*
>
>
>
>
> ${project.build.directory}/${project.build.finalName}/WEB-INF/classes/public
>
>
> {code}
> h2. Problem
> This execution works fine when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean prepare-package
> {code}
> it copies over all of the NPM build output contents (directories and files)
> but this execution fails when you run:
> {code:bash}
> $ cd service/www/
> $ mvn clean install
> {code}
> it copies over only the directory structure, but no files:
> {code}
> target/
> java-microservice-example-service-www-1.0.0-SNAPSHOT/
> WEB-INF/
> classes/
> public/ (no files)
> static/
> css/ (no files)
> js/ (no files)
> media/ (no files)
> {code}
> I believe the other executions defined in the {{pom.xml}} don't seem to have
> a problem, just this one ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
