[jira] [Resolved] (MWAR-450) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MWAR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg resolved MWAR-450.
--
Assignee: Dennis Lundberg
Resolution: Fixed
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MWAR-450
> URL: https://issues.apache.org/jira/browse/MWAR-450
> Project: Maven WAR Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.3.2
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.4.0
>
>
> This issue is similar to
> https://issues.apache.org/jira/browse/MRESOURCES-171, but for filtering web
> resources in maven-war-plugin.
> We add properties files that have ISO-8859-1 encoding, as per the Java 8
> requirements, as web resources in a war project. When these resources are
> filtered they get converted to the encoding specified by the
> project.build.sourceEncoding. There is a parameter resourceEncoding that can
> be used to change the encoding for web reources, but it applies to all web
> resource files which is not always what you want.
> Here is the configuration used:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 3.3.2
>
>
>
> WEB-INF/classes
> true
> src/main/webapp/WEB-INF/classes
>
>
>
>
>
>
> {code}
> We propose to add a new parameter propertiesEncoding to the AbstractWarMojo.
> If the value of this parameter is set and filtering is enabled and a web
> resource file is a properties file, then the value of the parameter is used
> as encoding when filtering the file.
> If the parameter is not specified it defaults to
> project.build.sourceEncoding, thus keeping the current behavior of the plugin
> unchanged.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (MWAR-444) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MWAR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg resolved MWAR-444. -- Resolution: Fixed > Update plugin (requires Maven 3.2.5+) > - > > Key: MWAR-444 > URL: https://issues.apache.org/jira/browse/MWAR-444 > Project: Maven WAR Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.4.0 > > > Update plugin > * require Maven 3.2.5+ > * set maven bits to provided scope > * get rid of old baggage, update dependencies -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MWAR-448) packaging dependencies fails with "mvn install" but not "mvn package"
[ https://issues.apache.org/jira/browse/MWAR-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525438#comment-17525438 ] Dennis Lundberg edited comment on MWAR-448 at 4/25/22 1:14 PM: --- In my opinion what you have described above is working as intended. If you add a dependency on some-parent and don't specify the type, Maven and its plugins will assume that some-parent produces a jar artifact. If some-parent does not produce a jar artifact (as is the case) then some plugins will fail if they cannot find that jar artifact. So for things to work properly you must specify type=pom in some-parent, as well as any other place that uses some-parent as a dependency. was (Author: dennisl): In my opinion what you have described above is working as intended. If you add a dependency on some-parent and don't specify the type, Maven and its plugins will assume that some-parent produces a jar artifact. If some-parent does not produce a jar artifact (as is the case) then som plugins will fail if they cannot find that jar artifact. So for things to work properly you must specify type=pom in some-parent, as well as any other place that uses some-parent as a dependency. > packaging dependencies fails with "mvn install" but not "mvn package" > - > > Key: MWAR-448 > URL: https://issues.apache.org/jira/browse/MWAR-448 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 3.3.2 > Environment: maven 3.6.3 ( later versions have bugs which we can't > take in) >Reporter: Kari J. Niemi >Priority: Minor > Fix For: waiting-for-feedback > > > I think we discovered a minor odd difference with war-packaging between "mvn > package" or "mvn install". We would expect that only difference between the > two is that the latter also installs the produced stuff in the local maven > repository. > > We are packaging a few jars to a war. We have a parent pom with some modules, > and that is defined as a dependency in the pom.xml that produces a > war-package. Like this: > my-war-thingie:pom.xml (packaging:war) > * dependency: some-parent > some-parent:pom.xml (packaging:pom) > * module1 (packaging:jar) > * module2 (packaging:jar) > Earlier we had a different structure and everything was just fine: we did not > the have the child-modules but the parent-pom produced the jar. When we > changed the structure to the one described above: our CI was still OK, some > developers building OK as well -but some developers had failing maven builds > because of missing "some-parent.jar". > > It was bit of devastating hunt, but finally we discovered that "mvn package" > was building OK, but "mvn install" looks for "some-parent.jar". > We don't actually mind if the above scenario would fail in both cases, or if > it was successful - we would just expect that it works the same way for both. > If this is intended behaviour, it would be nice to have it documented. > FWIW: in our case, we anyway wanted to define direct dependencies from the > war-packaging to the child-modules. So actually, we are OK wih our builds > already. But the difference caused so may doubts about our builds > reproducibility - and also, it seems like a bug - so I wanted to be good > citizen and report the problem. > Edit: further note from our troubleshooting sessions: we don't have the > "type" for the dependency at all in my-war-thingie:pom.xml. Yesterday, we did > experiment setting the type as "pom" -and as a consequence, both "mvn > package" and "mvn install" were successful. The default as we know, > should/would be "jar". Maybe the missing dependency type is for some odd > reason resolved differently for "maven package" and "maven install"? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MWAR-450) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MWAR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-450:
-
Fix Version/s: 3.4.0
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MWAR-450
> URL: https://issues.apache.org/jira/browse/MWAR-450
> Project: Maven WAR Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.3.2
>Reporter: Dennis Lundberg
>Priority: Major
> Fix For: 3.4.0
>
>
> This issue is similar to
> https://issues.apache.org/jira/browse/MRESOURCES-171, but for filtering web
> resources in maven-war-plugin.
> We add properties files that have ISO-8859-1 encoding, as per the Java 8
> requirements, as web resources in a war project. When these resources are
> filtered they get converted to the encoding specified by the
> project.build.sourceEncoding. There is a parameter resourceEncoding that can
> be used to change the encoding for web reources, but it applies to all web
> resource files which is not always what you want.
> Here is the configuration used:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 3.3.2
>
>
>
> WEB-INF/classes
> true
> src/main/webapp/WEB-INF/classes
>
>
>
>
>
>
> {code}
> We propose to add a new parameter propertiesEncoding to the AbstractWarMojo.
> If the value of this parameter is set and filtering is enabled and a web
> resource file is a properties file, then the value of the parameter is used
> as encoding when filtering the file.
> If the parameter is not specified it defaults to
> project.build.sourceEncoding, thus keeping the current behavior of the plugin
> unchanged.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MWAR-444) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MWAR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525439#comment-17525439 ] Dennis Lundberg commented on MWAR-444: -- I saw some other other recent plugin release that also used Maven 3.2.5, so I'll go ahead and merge the existing pull request. We can always update again at a later date. > Update plugin (requires Maven 3.2.5+) > - > > Key: MWAR-444 > URL: https://issues.apache.org/jira/browse/MWAR-444 > Project: Maven WAR Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.3.3 > > > Update plugin > * require Maven 3.2.5+ > * set maven bits to provided scope > * get rid of old baggage, update dependencies -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWAR-448) packaging dependencies fails with "mvn install" but not "mvn package"
[ https://issues.apache.org/jira/browse/MWAR-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525438#comment-17525438 ] Dennis Lundberg commented on MWAR-448: -- In my opinion what you have described above is working as intended. If you add a dependency on some-parent and don't specify the type, Maven and its plugins will assume that some-parent produces a jar artifact. If some-parent does not produce a jar artifact (as is the case) then som plugins will fail if they cannot find that jar artifact. So for things to work properly you must specify type=pom in some-parent, as well as any other place that uses some-parent as a dependency. > packaging dependencies fails with "mvn install" but not "mvn package" > - > > Key: MWAR-448 > URL: https://issues.apache.org/jira/browse/MWAR-448 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 3.3.2 > Environment: maven 3.6.3 ( later versions have bugs which we can't > take in) >Reporter: Kari J. Niemi >Priority: Minor > Fix For: waiting-for-feedback > > > I think we discovered a minor odd difference with war-packaging between "mvn > package" or "mvn install". We would expect that only difference between the > two is that the latter also installs the produced stuff in the local maven > repository. > > We are packaging a few jars to a war. We have a parent pom with some modules, > and that is defined as a dependency in the pom.xml that produces a > war-package. Like this: > my-war-thingie:pom.xml (packaging:war) > * dependency: some-parent > some-parent:pom.xml (packaging:pom) > * module1 (packaging:jar) > * module2 (packaging:jar) > Earlier we had a different structure and everything was just fine: we did not > the have the child-modules but the parent-pom produced the jar. When we > changed the structure to the one described above: our CI was still OK, some > developers building OK as well -but some developers had failing maven builds > because of missing "some-parent.jar". > > It was bit of devastating hunt, but finally we discovered that "mvn package" > was building OK, but "mvn install" looks for "some-parent.jar". > We don't actually mind if the above scenario would fail in both cases, or if > it was successful - we would just expect that it works the same way for both. > If this is intended behaviour, it would be nice to have it documented. > FWIW: in our case, we anyway wanted to define direct dependencies from the > war-packaging to the child-modules. So actually, we are OK wih our builds > already. But the difference caused so may doubts about our builds > reproducibility - and also, it seems like a bug - so I wanted to be good > citizen and report the problem. > Edit: further note from our troubleshooting sessions: we don't have the > "type" for the dependency at all in my-war-thingie:pom.xml. Yesterday, we did > experiment setting the type as "pom" -and as a consequence, both "mvn > package" and "mvn install" were successful. The default as we know, > should/would be "jar". Maybe the missing dependency type is for some odd > reason resolved differently for "maven package" and "maven install"? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MWAR-440) When it is necessary to build more than one WAR archive at the same time, it fails to set different web.xml
[
https://issues.apache.org/jira/browse/MWAR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MWAR-440.
Resolution: Not A Problem
> When it is necessary to build more than one WAR archive at the same time, it
> fails to set different web.xml
> ---
>
> Key: MWAR-440
> URL: https://issues.apache.org/jira/browse/MWAR-440
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.2.0, 3.2.2
>Reporter: Tuzhilkin Mikhail
>Priority: Major
>
> In an assembly, I need to create 2 WAR archives with different web.xml files
> at a time.
> For this I use the following plugin setting:
> {code:xml}
>
> maven-war-plugin
> 3.2.2
>
> web?.xml
> true
>
>
>
> 1
> package
>
> war
>
>
> false
> src/main/webapp/web1.xml
> web1
>
>
>
> 2
> package
>
> war
>
>
> false
> src/main/webapp/web2.xml
> web2
>
>
>
>
> {code}
> {code}
> Project structure:
> src/main/webapp/web1.xml
> src/main/webapp/web2.xml
> pom.xml
> {code}
> {code:xml}
>
>
>
>
> {code}
> {code:xml}
>
>
>
>
> {code}
> But the first of the specified files gets into both archives, despite the
> different paths .
> {code}
> $ unzip -p web1.war WEB-INF/web.xml
>
>
>
> $ unzip -p web2.war WEB-INF/web.xml
>
>
>
> {code}
> Example project: [https://github.com/tuzhms/mwar-bug-example]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MWAR-440) When it is necessary to build more than one WAR archive at the same time, it fails to set different web.xml
[
https://issues.apache.org/jira/browse/MWAR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524872#comment-17524872
]
Dennis Lundberg edited comment on MWAR-440 at 4/20/22 10:43 AM:
The reason for this seems to be that the time stamp of the two web.xml files
are identical.
In the first run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web1.xml.
During the second run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web2.xml. But, here it realizes that
the target fil target/mwar-bug-example/WEB-INF/web.xml has an identical file
name and time stamp. Therefor it skips that file. This can be seen in the log
if you run Maven with the -X option. Here are the output from the first run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] + WEB-INF/web.xml has been copied.
[INFO] Webapp assembled in [316 msecs]{noformat}
And here is the output from the second run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] * WEB-INF/web.xml is up to date.
[INFO] Webapp assembled in [266 msecs] {noformat}
was (Author: dennisl):
The reason for this seems to be that the time stamp of the two web.xml files
are identical.
In the first run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web1.xml.
During the second run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web2.xml. But, here it realizes that
the target fil target/mwar-bug-example/WEB-INF/web.xml has an identical file
name and time stamp. Therefor it skips that file. This can be seen in the log
if you run Maven with the -X option. Here are the output from the first run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] * WEB-INF/web.xml is up to date.
[INFO] Webapp assembled in [266 msecs]{noformat}
And here is the output from the second run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] * WEB-INF/web.xml is up to date.
[INFO] Webapp assembled in [266 msecs] {noformat}
> When it is necessary to build more than one WAR archive at the same time, it
> fails to set different web.xml
> ---
>
> Key: MWAR-440
> URL: https://issues.apache.org/jira/browse/MWAR-440
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.2.0, 3.2.2
>Reporter: Tuzhilkin Mikhail
>Priority: Major
>
> In an assembly, I need to create 2 WAR archives with different web.xml files
> at a time.
> For this I use the following plugin setting:
> {code:xml}
>
> maven-war-plugin
> 3.2.2
>
> web?.xml
> true
>
>
>
> 1
> package
>
> war
>
>
> false
> src/main/webapp/web1.xml
> web1
>
>
>
> 2
> package
>
> war
>
>
> false
> src/main/webapp/web2.xml
> web2
>
>
>
>
> {code}
> {code}
> Project structure:
> src/main/webapp/web1.xml
> src/main/webapp/web2.xml
> pom.xml
> {code}
> {code:xml}
>
>
>
>
> {code}
> {code:xml}
>
>
>
>
> {code}
> But the first of the specified files gets into both archives, despite the
> different paths .
> {code}
> $ unzip -p web1.war WEB-INF/web.xml
>
>
>
> $ unzip -p web2.war WEB-INF/web.xml
>
>
>
> {code}
> Example project: [https://github.com/tuzhms/mwar-bug-example]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MWAR-444) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MWAR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524873#comment-17524873 ] Dennis Lundberg commented on MWAR-444: -- [~cstamas] I was refering to the discussion in the pull request on GitHub here: https://github.com/apache/maven-war-plugin/pull/20 > Update plugin (requires Maven 3.2.5+) > - > > Key: MWAR-444 > URL: https://issues.apache.org/jira/browse/MWAR-444 > Project: Maven WAR Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.3.3 > > > Update plugin > * require Maven 3.2.5+ > * set maven bits to provided scope > * get rid of old baggage, update dependencies -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWAR-440) When it is necessary to build more than one WAR archive at the same time, it fails to set different web.xml
[
https://issues.apache.org/jira/browse/MWAR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524872#comment-17524872
]
Dennis Lundberg commented on MWAR-440:
--
The reason for this seems to be that the time stamp of the two web.xml files
are identical.
In the first run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web1.xml.
During the second run the war plugin copies files into
target/mwar-bug-example/WEB-INF/ including web2.xml. But, here it realizes that
the target fil target/mwar-bug-example/WEB-INF/web.xml has an identical file
name and time stamp. Therefor it skips that file. This can be seen in the log
if you run Maven with the -X option. Here are the output from the first run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] * WEB-INF/web.xml is up to date.
[INFO] Webapp assembled in [266 msecs]{noformat}
And here is the output from the second run:
{noformat}
[INFO] Processing war project
[INFO] Copying webapp resources
[C:\Users\dlg01\Downloads\mwar-bug-example-master\src\main\webapp]
[DEBUG] + web1.xml has been copied.
[DEBUG] + web2.xml has been copied.
[DEBUG] Dump of the current build pathSet content -->
[DEBUG] web1.xml
[DEBUG] web2.xml
[DEBUG] -- end of dump --
[DEBUG] * WEB-INF/web.xml is up to date.
[INFO] Webapp assembled in [266 msecs] {noformat}
> When it is necessary to build more than one WAR archive at the same time, it
> fails to set different web.xml
> ---
>
> Key: MWAR-440
> URL: https://issues.apache.org/jira/browse/MWAR-440
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.2.0, 3.2.2
>Reporter: Tuzhilkin Mikhail
>Priority: Major
>
> In an assembly, I need to create 2 WAR archives with different web.xml files
> at a time.
> For this I use the following plugin setting:
> {code:xml}
>
> maven-war-plugin
> 3.2.2
>
> web?.xml
> true
>
>
>
> 1
> package
>
> war
>
>
> false
> src/main/webapp/web1.xml
> web1
>
>
>
> 2
> package
>
> war
>
>
> false
> src/main/webapp/web2.xml
> web2
>
>
>
>
> {code}
> {code}
> Project structure:
> src/main/webapp/web1.xml
> src/main/webapp/web2.xml
> pom.xml
> {code}
> {code:xml}
>
>
>
>
> {code}
> {code:xml}
>
>
>
>
> {code}
> But the first of the specified files gets into both archives, despite the
> different paths .
> {code}
> $ unzip -p web1.war WEB-INF/web.xml
>
>
>
> $ unzip -p web2.war WEB-INF/web.xml
>
>
>
> {code}
> Example project: [https://github.com/tuzhms/mwar-bug-example]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MWAR-420) build failure in lifecycle deploy: 'Could not copy webapp sources'
[
https://issues.apache.org/jira/browse/MWAR-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MWAR-420.
Fix Version/s: 3.3.0
Resolution: Fixed
This seems to have been resolved in Maven War Plugin 3.3.0.
> build failure in lifecycle deploy: 'Could not copy webapp sources'
> --
>
> Key: MWAR-420
> URL: https://issues.apache.org/jira/browse/MWAR-420
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Bruno Marti
>Priority: Major
> Fix For: 3.3.0
>
> Attachments: build-error.log, testWarPlugin.zip
>
>
> Since version 3.2.x there is a build failure in maven-war-plugin on lifecycle
> 'deploy'.
> {code:java}
> mvn package package -e{code}
> If you build sample webapp (see attachement: [^testWarPlugin.zip]) with
> version 3.2.2 following error occurs:
> {code:java}
> [INFO] --- maven-war-plugin:3.2.2:war (default-war) @ testWarPlugin ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [testWarPlugin] in
> [C:\TEMP\testWarPlugin\target\testWarPlugin-1.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources [C:\TEMP\testWarPlugin\src\main\webapp]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 5.106 s
> [INFO] Finished at: 2018-11-07T10:11:58+01:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-war-plugin:3.2.2:war (default-war) on project
> testWarPlugin: Could not copy webapp sources
> [C:\TEMP\testWarPlugin\target\testWarPlugin-1.0-SNAPSHOT]:
> C:\TEMP\testWarPlugin\target\testWarPlugin-1.0-SNAPSHOT\images\ajaxloading.gif
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-war-plugin:3.2.2:war (default-war) on
> project testWarPlugin: Could not copy webapp sources
> [C:\TEMP\testWarPlugin\target\testWarPlugin-1.0-SNAPSHOT]
> ...
> Caused by: java.nio.file.AccessDeniedException:
> C:\TEMP\testWarPlugin\target\testWarPlugin-1.0-SNAPSHOT\images\ajaxloading.gif
> at sun.nio.fs.WindowsException.translateToIOException
> (WindowsException.java:83)
> at sun.nio.fs.WindowsException.rethrowAsIOException
> (WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException
> (WindowsException.java:102)
> at sun.nio.fs.WindowsFileCopy.copy (WindowsFileCopy.java:165)
> at sun.nio.fs.WindowsFileSystemProvider.copy
> (WindowsFileSystemProvider.java:278)
> at java.nio.file.Files.copy (Files.java:1274)
> {code}
> It only occurs on {color:#ff}windows{color} and with
> maven-war-plugin{color:#ff} 3.2.x{color}. Fullstacktrace here:
> [^build-error.log]
> Version {color:#14892c}3.1.0 and older{color} works fine
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MWAR-444) Update plugin (requires Maven 3.2.5+)
[ https://issues.apache.org/jira/browse/MWAR-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524812#comment-17524812 ] Dennis Lundberg commented on MWAR-444: -- I'm working on MWAR-450 and would like to make a release of that , when it is finished. Should this issue be included in the next version? There seems to be disagreement on GitHub regarding which version och Maven to require. > Update plugin (requires Maven 3.2.5+) > - > > Key: MWAR-444 > URL: https://issues.apache.org/jira/browse/MWAR-444 > Project: Maven WAR Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.3.3 > > > Update plugin > * require Maven 3.2.5+ > * set maven bits to provided scope > * get rid of old baggage, update dependencies -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWAR-450) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MWAR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518665#comment-17518665
]
Dennis Lundberg commented on MWAR-450:
--
We have a working implementation now, and will continue to write some tests to
verify the old and new behavior.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MWAR-450
> URL: https://issues.apache.org/jira/browse/MWAR-450
> Project: Maven WAR Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.3.2
>Reporter: Dennis Lundberg
>Priority: Major
>
> This issue is similar to
> https://issues.apache.org/jira/browse/MRESOURCES-171, but for filtering web
> resources in maven-war-plugin.
> We add properties files that have ISO-8859-1 encoding, as per the Java 8
> requirements, as web resources in a war project. When these resources are
> filtered they get converted to the encoding specified by the
> project.build.sourceEncoding. There is a parameter resourceEncoding that can
> be used to change the encoding for web reources, but it applies to all web
> resource files which is not always what you want.
> Here is the configuration used:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 3.3.2
>
>
>
> WEB-INF/classes
> true
> src/main/webapp/WEB-INF/classes
>
>
>
>
>
>
> {code}
> We propose to add a new parameter propertiesEncoding to the AbstractWarMojo.
> If the value of this parameter is set and filtering is enabled and a web
> resource file is a properties file, then the value of the parameter is used
> as encoding when filtering the file.
> If the parameter is not specified it defaults to
> project.build.sourceEncoding, thus keeping the current behavior of the plugin
> unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWAR-451) ISO8859-1 properties files get changed into UTF-8 when filtered
Dennis Lundberg created MWAR-451:
Summary: ISO8859-1 properties files get changed into UTF-8 when
filtered
Key: MWAR-451
URL: https://issues.apache.org/jira/browse/MWAR-451
Project: Maven WAR Plugin
Issue Type: New Feature
Components: filtering
Affects Versions: 3.3.2
Reporter: Dennis Lundberg
This issue is similar to https://issues.apache.org/jira/browse/MRESOURCES-171,
but for filtering web resources in maven-war-plugin.
We add properties files that have ISO-8859-1 encoding, as per the Java 8
requirements, as web resources in a war project. When these resources are
filtered they get converted to the encoding specified by the
project.build.sourceEncoding. There is a parameter resourceEncoding that can be
used to change the encoding for web reources, but it applies to all web
resource files which is not always what you want.
Here is the configuration used:
{code:xml}
org.apache.maven.plugins
maven-war-plugin
3.3.2
WEB-INF/classes
true
src/main/webapp/WEB-INF/classes
{code}
We propose to add a new parameter propertiesEncoding to the AbstractWarMojo. If
the value of this parameter is set and filtering is enabled and a web resource
file is a properties file, then the value of the parameter is used as encoding
when filtering the file.
If the parameter is not specified it defaults to project.build.sourceEncoding,
thus keeping the current behavior of the plugin unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWAR-450) ISO8859-1 properties files get changed into UTF-8 when filtered
Dennis Lundberg created MWAR-450:
Summary: ISO8859-1 properties files get changed into UTF-8 when
filtered
Key: MWAR-450
URL: https://issues.apache.org/jira/browse/MWAR-450
Project: Maven WAR Plugin
Issue Type: Improvement
Components: filtering
Affects Versions: 3.3.2
Reporter: Dennis Lundberg
This issue is similar to https://issues.apache.org/jira/browse/MRESOURCES-171,
but for filtering web resources in maven-war-plugin.
We add properties files that have ISO-8859-1 encoding, as per the Java 8
requirements, as web resources in a war project. When these resources are
filtered they get converted to the encoding specified by the
project.build.sourceEncoding. There is a parameter resourceEncoding that can be
used to change the encoding for web reources, but it applies to all web
resource files which is not always what you want.
Here is the configuration used:
{code:xml}
org.apache.maven.plugins
maven-war-plugin
3.3.2
WEB-INF/classes
true
src/main/webapp/WEB-INF/classes
{code}
We propose to add a new parameter propertiesEncoding to the AbstractWarMojo. If
the value of this parameter is set and filtering is enabled and a web resource
file is a properties file, then the value of the parameter is used as encoding
when filtering the file.
If the parameter is not specified it defaults to project.build.sourceEncoding,
thus keeping the current behavior of the plugin unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWAR-449) ISO8859-1 properties files get changed into UTF-8 when filtered
Dennis Lundberg created MWAR-449:
Summary: ISO8859-1 properties files get changed into UTF-8 when
filtered
Key: MWAR-449
URL: https://issues.apache.org/jira/browse/MWAR-449
Project: Maven WAR Plugin
Issue Type: Improvement
Components: filtering
Affects Versions: 3.3.2
Reporter: Dennis Lundberg
This issue is similar to https://issues.apache.org/jira/browse/MRESOURCES-171,
but for filtering web resources in maven-war-plugin.
We add properties files that have ISO-8859-1 encoding, as per the Java 8
requirements, as web resources in a war project. When these resources are
filtered they get converted to the encoding specified by the
project.build.sourceEncoding. There is a parameter resourceEncoding that can be
used to change the encoding for web reources, but it applies to all web
resource files which is not always what you want.
Here is the configuration used:
{code:xml}
org.apache.maven.plugins
maven-war-plugin
3.3.2
WEB-INF/classes
true
src/main/webapp/WEB-INF/classes
{code}
We propose to add a new parameter propertiesEncoding to the AbstractWarMojo. If
the value of this parameter is set and filtering is enabled and a web resource
file is a properties file, then the value of the parameter is used as encoding
when filtering the file.
If the parameter is not specified it defaults to project.build.sourceEncoding,
thus keeping the current behavior of the plugin unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding
[
https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177787#comment-17177787
]
Dennis Lundberg commented on MRESOURCES-265:
Thanks for configuration and the extended logs.
Your issue seems to be related to the issue MRESOURCES-258 that was fixed in
the 3.2.0 release.
While we continue to investigate this and try to fix it, there is one other
thing you can do to get past this. Since a keystore file is a binary file you
shouldn't really filter it. To exclude keystore files from filtering you can
add the following configuration to maven-resource-plugin in your pom.xml:
{code:xml}
jks
{code}
> Resource copying not using specified encoding
> -
>
> Key: MRESOURCES-265
> URL: https://issues.apache.org/jira/browse/MRESOURCES-265
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.2.0
> Environment: Linux, CentOS 7
> Jenkins 2.251
> Jenkins Maven Integration plugin 3.1.2
> Java 1.8
>Reporter: Duncan Kinnear
>Priority: Major
>
> Overnight our Jenkins builds stopped working. On investigation we found that
> maven-resources-plugin version used yesterday was 3.1.0 (which worked fine)
> and today it was using 3.2.0.
> The stacktrace produced by adding the "e" switch to the maven command line
> had the following root cause (truncated for brevity):-
> Caused by: java.nio.charset.MalformedInputException: Input length = 1
> at java.nio.charset.CoderResult.throwException (CoderResult.java:281)
> at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339)
> at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
> at java.io.InputStreamReader.read (InputStreamReader.java:184)
> at java.io.BufferedReader.read1 (BufferedReader.java:210)
> at java.io.BufferedReader.read (BufferedReader.java:286)
> at java.io.BufferedReader.fill (BufferedReader.java:161)
> at java.io.BufferedReader.read (BufferedReader.java:182)
> at org.apache.maven.shared.filtering.BoundedReader.read
> (BoundedReader.java:85)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
> (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read
> (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197)
> at java.io.Reader.read (Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199)
>
> After a google search told us this was an encoding issue, we added the
> following to the maven command line, but this made no difference:
> -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8
>
> The maven build log has these info messsage just before the error:
> [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks —
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Using 'UTF-8' encoding to copy filtered properties files.
> [INFO] Copying 430 resources
> We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the
> projects POM 'pluginManagement' section.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-265) Resource copying not using specified encoding
[ https://issues.apache.org/jira/browse/MRESOURCES-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176836#comment-17176836 ] Dennis Lundberg commented on MRESOURCES-265: Thanks for your report [~DuncanKinnear]. Were you able to determine which file caused the error, and the content and encoding of that file? That would help us to debug your problem. It would be great if you could attach that file to the issue, if possible. Also it would help if you can cut-and-paste the section of maven-resources-plugin and the / section of your POM. > Resource copying not using specified encoding > - > > Key: MRESOURCES-265 > URL: https://issues.apache.org/jira/browse/MRESOURCES-265 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 3.2.0 > Environment: Linux, CentOS 7 > Jenkins 2.251 > Jenkins Maven Integration plugin 3.1.2 > Java 1.8 >Reporter: Duncan Kinnear >Priority: Major > > Overnight our Jenkins builds stopped working. On investigation we found that > maven-resources-plugin version used yesterday was 3.1.0 (which worked fine) > and today it was using 3.2.0. > The stacktrace produced by adding the "e" switch to the maven command line > had the following root cause (truncated for brevity):- > Caused by: java.nio.charset.MalformedInputException: Input length = 1 > at java.nio.charset.CoderResult.throwException (CoderResult.java:281) > at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:339) > at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178) > at java.io.InputStreamReader.read (InputStreamReader.java:184) > at java.io.BufferedReader.read1 (BufferedReader.java:210) > at java.io.BufferedReader.read (BufferedReader.java:286) > at java.io.BufferedReader.fill (BufferedReader.java:161) > at java.io.BufferedReader.read (BufferedReader.java:182) > at org.apache.maven.shared.filtering.BoundedReader.read > (BoundedReader.java:85) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:235) > at > org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read > (MultiDelimiterInterpolatorFilterReaderLineEnding.java:197) > at java.io.Reader.read (Reader.java:140) > at org.apache.maven.shared.utils.io.IOUtil.copy (IOUtil.java:199) > > After a google search told us this was an encoding issue, we added the > following to the maven command line, but this made no difference: > -Dproject.build.sourceEncoding=UTF-8 -Dproject.reporting.outputEncoding=UTF-8 > > The maven build log has these info messsage just before the error: > [INFO] — maven-resources-plugin:3.2.0:resources (default-cli) @ uniworks — > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Using 'UTF-8' encoding to copy filtered properties files. > [INFO] Copying 430 resources > We only 'fixed' the problem by specifying version 3.1.0 of the plugin in the > projects POM 'pluginManagement' section. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MNG-6967:
-
Fix Version/s: 3.7.0
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.7.0
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus {{->}}.
> I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It respresents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MNG-6964.
Fix Version/s: 3.7.0
Resolution: Fixed
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.7.0
>
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARCHETYPE-606) There is no way to include .gitignore files for the jar goal
[
https://issues.apache.org/jira/browse/ARCHETYPE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated ARCHETYPE-606:
--
Summary: There is no way to include .gitignore files for the jar goal
(was: Parameter addDefaultExcludes with false does not copy .gitignore)
> There is no way to include .gitignore files for the jar goal
>
>
> Key: ARCHETYPE-606
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-606
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.0
> Environment: CentOS 7 64bits, OpenJDK 11.0.7, Maven 3.6.3, Maven
> Archetype Plugin 3.2.0
>Reporter: Joël Royer
>Priority: Major
>
> In a Maven archetype, I'm using the resource plugin to copy some files like a
> .gitignore template. But this file is not copied when I generate a project
> from this artefact.
> Here is my config for the resource plugin in my artefact:
> {code:java}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 3.1.0
>
>
>
> false
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Moved] (ARCHETYPE-606) Parameter addDefaultExcludes with false does not copy .gitignore
[
https://issues.apache.org/jira/browse/ARCHETYPE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg moved MRESOURCES-264 to ARCHETYPE-606:
--
Component/s: (was: copy)
Plugin
Key: ARCHETYPE-606 (was: MRESOURCES-264)
Affects Version/s: (was: 3.1.0)
3.2.0
Project: Maven Archetype (was: Maven Resources Plugin)
> Parameter addDefaultExcludes with false does not copy .gitignore
>
>
> Key: ARCHETYPE-606
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-606
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.0
> Environment: CentOS 7 64bits, OpenJDK 11.0.7, Maven 3.6.3, Maven
> Archetype Plugin 3.2.0
>Reporter: Joël Royer
>Priority: Major
>
> In a Maven archetype, I'm using the resource plugin to copy some files like a
> .gitignore template. But this file is not copied when I generate a project
> from this artefact.
> Here is my config for the resource plugin in my artefact:
> {code:java}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 3.1.0
>
>
>
> false
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-264) Parameter addDefaultExcludes with false does not copy .gitignore
[
https://issues.apache.org/jira/browse/MRESOURCES-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172389#comment-17172389
]
Dennis Lundberg commented on MRESOURCES-264:
Thank you for the example project [~joelroyer].
I have tried it and can verify that maven-resources-plugin in fact does copy
the .gitignore file to target/classes/archetype-resources. So
maven-resources-plugin does what you have told it to do.
After that maven-archetype-plugin takes over and packages your archetype with
the jar goal, using your supplied archetype-metadata.xml file. That plugin
however does NOT include the .gitignore file. I haven't looked at the code, but
I assume that the copying of a fileSet also has some kind of default ignores.
What you need is a way to tell maven-archetype-plugin to not exclude such
files. I'm going to move this issue over to the JIRA project for
maven-archetype.
> Parameter addDefaultExcludes with false does not copy .gitignore
>
>
> Key: MRESOURCES-264
> URL: https://issues.apache.org/jira/browse/MRESOURCES-264
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.1.0
> Environment: CentOS 7 64bits, OpenJDK 11.0.7, Maven 3.6.3, Maven
> Archetype Plugin 3.2.0
>Reporter: Joël Royer
>Priority: Major
>
> In a Maven archetype, I'm using the resource plugin to copy some files like a
> .gitignore template. But this file is not copied when I generate a project
> from this artefact.
> Here is my config for the resource plugin in my artefact:
> {code:java}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 3.1.0
>
>
>
> false
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOURCES-263) Update to maven-filtering 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-263. -- Resolution: Fixed > Update to maven-filtering 3.2.0 > --- > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-263) Update to maven-filtering 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171597#comment-17171597 ] Dennis Lundberg commented on MRESOURCES-263: I'm releasing both of these at the same time, so the failure is to be expected. > Update to maven-filtering 3.2.0 > --- > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MRESOURCES-237:
---
Fix Version/s: (was: 3.2.0)
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-263) Update to maven-filtering 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-263: --- Summary: Update to maven-filtering 3.2.0 (was: Use non-shapshot maven-filtering) > Update to maven-filtering 3.2.0 > --- > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-263) Update to maven-filtering 3.2.0
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-263. -- Resolution: Fixed > Update to maven-filtering 3.2.0 > --- > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-937) Demote log statement to debug
[
https://issues.apache.org/jira/browse/MSHARED-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170839#comment-17170839
]
Dennis Lundberg commented on MSHARED-937:
-
I have a different opinion on this.
The first line (143-144) is done once for each build/resources/resource, so for
a normal project it would be once or twice for main and maybe once for test. I
don't think that is a lot. This is also useful information to the user, so that
they know which encoding is being used.
The other line (which is now at 260) is done once for each filtered resource
file. So it makes sense to log that at the DEBUG level, instead of INFO level,
because there could be a lot of resource files in a project.
> Demote log statement to debug
> -
>
> Key: MSHARED-937
> URL: https://issues.apache.org/jira/browse/MSHARED-937
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> In line 144 of DefaultMavenResourcesFiltering we have:
> {{else
> {
> getLogger().info( "Using '" +
> mavenResourcesExecution.getEncoding()
> + "' encoding to copy filtered resources." );
> }}}
> This produces a lot of log junk and is inconsistent with most other locations
> in the file such as line 237 where similar messages are logged at DEBUG
> level. This message should be debug too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-946) Update to maven-shared-utils 3.3.3
[ https://issues.apache.org/jira/browse/MSHARED-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSHARED-946. --- Resolution: Fixed > Update to maven-shared-utils 3.3.3 > -- > > Key: MSHARED-946 > URL: https://issues.apache.org/jira/browse/MSHARED-946 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Major > Fix For: maven-filtering-3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHARED-946) Update to maven-shared-utils 3.3.3
Dennis Lundberg created MSHARED-946: --- Summary: Update to maven-shared-utils 3.3.3 Key: MSHARED-946 URL: https://issues.apache.org/jira/browse/MSHARED-946 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Reporter: Dennis Lundberg Assignee: Dennis Lundberg Fix For: maven-filtering-3.2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNGSITE-422) Sending announcement using Maven Changes Plugin fails when promoting a Maven release
Dennis Lundberg created MNGSITE-422: --- Summary: Sending announcement using Maven Changes Plugin fails when promoting a Maven release Key: MNGSITE-422 URL: https://issues.apache.org/jira/browse/MNGSITE-422 Project: Maven Project Web Site Issue Type: Improvement Reporter: Dennis Lundberg While releasing Maven Shared Utils 3.3.3 I followed the instructions at: https://maven.apache.org/developers/release/maven-project-release-procedure.html When doing the announcement a 5.a. it failed for me with this error: Failed to execute goal org.apache.maven.plugins:maven-changes-plugin:2.12.1:announcement-generate (announcement-generate) on project maven-shared-utils: Failed to extract issues from JIRA. Invalid browse URL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-419) The instructions for creating a Maven project release need to be updated
[
https://issues.apache.org/jira/browse/MNGSITE-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168900#comment-17168900
]
Dennis Lundberg commented on MNGSITE-419:
-
According to VCS history 3.2.3 is the first version which defaults to use https
for central.
Java 7 and TLS 1.2 is a great example. There is not a definitive yes or no
answer to this issue. There are options and opinions, and we should gather them
here and discuss them.
> The instructions for creating a Maven project release need to be updated
>
>
> Key: MNGSITE-419
> URL: https://issues.apache.org/jira/browse/MNGSITE-419
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Dennis Lundberg
>Priority: Major
>
> When I released maven-shared-utils I stumbled across a couple of things in
> our instructions that needs to be updated.
> https://maven.apache.org/developers/release/maven-project-release-procedure.html
> The examples below are run using an empty local repository.
> *You cannot use Maven 3.0.5 any longer, because Maven central requires HTTPS*
> https://blog.sonatype.com/central-repository-moving-to-https
> {noformat}
> G:\git\apache\maven-filtering>mvn -version
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
> 14:51:28+0100)
> Maven home: C:\Program Files\apache-maven-3.0.5
> Java version: 1.8.0_202, vendor: AdoptOpenJdk
> ...
> {noformat}
> {noformat}
> G:\git\apache\maven-filtering>mvn clean
> [INFO] Scanning for projects...
> Downloading:
> http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
> (G:\git\apache\maven-filtering\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not transfer artifact
> org.apache.maven.shared:maven-shared-components:pom:34 from/to central
> (http://repo.maven.apache.org/maven2): Failed to transfer file:
> http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom.
> Return code is: 501 , ReasonPhrase:HTTPS Required. and 'parent.relativePath'
> points at wrong local POM @ line 23, column 11 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {noformat}
> Solution
> I used Maven 3.3.9. According to VCS history 3.2.3+ should work.
> *You cannot use Java 7, because Maven central requires TLS 1.2+*
> https://blog.sonatype.com/enhancing-ssl-security-and-http/2-support-for-central
> https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
> {noformat}
> G:\git\apache\maven-filtering>mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.7.0_79, vendor: Oracle Corporation
> ...
> {noformat}
> {noformat}
> G:\git\apache\maven-filtering>mvn clean
> [INFO] Scanning for projects...
> Downloading:
> https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
> artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to
> central (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version and 'parent.relativePath' points at wrong local POM @ line
> 23, column 11
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
> (G:\git\apache\maven-filtering\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for
> org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
> artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to
> central (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version and 'parent.relativePath' points at wrong local POM @ line
> 23, column 11 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to
[jira] [Commented] (MRESOURCES-264) Parameter addDefaultExcludes with false does not copy .gitignore
[
https://issues.apache.org/jira/browse/MRESOURCES-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167155#comment-17167155
]
Dennis Lundberg commented on MRESOURCES-264:
Hi,
We have an integration test in place that test this functionality and it is
working. Could you please have a look at it and let us know how your project
differs from our test?
[https://github.com/apache/maven-resources-plugin/tree/maven-resources-plugin-3.1.0/src/it/include-git-ignore]
Note that the .gitignore files in the integration test are created by the
script setup.sh.
> Parameter addDefaultExcludes with false does not copy .gitignore
>
>
> Key: MRESOURCES-264
> URL: https://issues.apache.org/jira/browse/MRESOURCES-264
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.1.0
> Environment: CentOS 7 64bits, OpenJDK 11.0.7, Maven 3.6.3, Maven
> Archetype Plugin 3.2.0
>Reporter: Joël Royer
>Priority: Major
>
> In a Maven archetype, I'm using the resource plugin to copy some files like a
> .gitignore template. But this file is not copied when I generate a project
> from this artefact.
> Here is my config for the resource plugin in my artefact:
> {code:java}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 3.1.0
>
>
>
> false
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6970) Mvn -v in cmd shows Syntax of the command is incorrect
[
https://issues.apache.org/jira/browse/MNG-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167079#comment-17167079
]
Dennis Lundberg commented on MNG-6970:
--
If the above command fails, then I think that your Maven installation has been
broken somehow. Could you please download Maven 3.3.9 and install it using the
instructions mentioned before.
What output do you get if you run this command?
{noformat}
java -version
{noformat}
> Mvn -v in cmd shows Syntax of the command is incorrect
> ---
>
> Key: MNG-6970
> URL: https://issues.apache.org/jira/browse/MNG-6970
> Project: Maven
> Issue Type: Bug
>Reporter: vignesh GOVINDARAJ
>Priority: Major
> Labels: Maven, configuration, installation, or
> Fix For: wontfix-candidate
>
>
> I configured maven in Windows 10 machine, while verifying configuration mvn
> -v or mvn -version in cmd it shows Syntax of the command is incorrect
>
> I tried navigating to the maven repository still same error,
> Java - version
> 1.8.0
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-419) The instructions for creating a Maven project release need to be updated
[
https://issues.apache.org/jira/browse/MNGSITE-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MNGSITE-419:
Description:
When I released maven-shared-utils I stumbled across a couple of things in our
instructions that needs to be updated.
https://maven.apache.org/developers/release/maven-project-release-procedure.html
The examples below are run using an empty local repository.
*You cannot use Maven 3.0.5 any longer, because Maven central requires HTTPS*
https://blog.sonatype.com/central-repository-moving-to-https
{noformat}
G:\git\apache\maven-filtering>mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: C:\Program Files\apache-maven-3.0.5
Java version: 1.8.0_202, vendor: AdoptOpenJdk
...
{noformat}
{noformat}
G:\git\apache\maven-filtering>mvn clean
[INFO] Scanning for projects...
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
(G:\git\apache\maven-filtering\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not transfer artifact
org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(http://repo.maven.apache.org/maven2): Failed to transfer file:
http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom.
Return code is: 501 , ReasonPhrase:HTTPS Required. and 'parent.relativePath'
points at wrong local POM @ line 23, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{noformat}
Solution
I used Maven 3.3.9. According to VCS history 3.2.3+ should work.
*You cannot use Java 7, because Maven central requires TLS 1.2+*
https://blog.sonatype.com/enhancing-ssl-security-and-http/2-support-for-central
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
{noformat}
G:\git\apache\maven-filtering>mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files\apache-maven-3.3.9
Java version: 1.7.0_79, vendor: Oracle Corporation
...
{noformat}
{noformat}
G:\git\apache\maven-filtering>mvn clean
[INFO] Scanning for projects...
Downloading:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version
and 'parent.relativePath' points at wrong local POM @ line 23, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
(G:\git\apache\maven-filtering\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version
and 'parent.relativePath' points at wrong local POM @ line 23, column 11 ->
[Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{noformat}
Solution 1
Use Java 8 with toolchains
mvn release:prepare -Pjdk-toolchain
Solution 2
Add protocols on the command line
mvn release:prepare -Dhttps.protocols=TLSv1.2
*No instructions for using toolchains*
For my release I went with solution 1, and it took me a while to figure out
which combination of command line switches to use. Here's what finally worked
for me.
{noformat}
mvn release:prepare -Pjdk-toolchain
mvn release:perform -DreleaseProfiles=apache-release,jdk-toolchain
-Papache-release,jdk-toolchain
[jira] [Created] (MNGSITE-419) The instructions for creating a Maven project release need to be updated
Dennis Lundberg created MNGSITE-419:
---
Summary: The instructions for creating a Maven project release
need to be updated
Key: MNGSITE-419
URL: https://issues.apache.org/jira/browse/MNGSITE-419
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Dennis Lundberg
When I released maven-shared-utils I stumbled across a couple of things in our
instructions that needs to be updated.
https://maven.apache.org/developers/release/maven-project-release-procedure.html
The examples below are run using an empty local repository.
*You cannot use Maven 3.0.5 any longer, because Maven central requires HTTPS*
https://blog.sonatype.com/central-repository-moving-to-https
{noformat}
G:\git\apache\maven-filtering>mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: C:\Program Files\apache-maven-3.0.5
Java version: 1.8.0_202, vendor: AdoptOpenJdk
...
{noformat}
{noformat}
G:\git\apache\maven-filtering>mvn clean
[INFO] Scanning for projects...
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
(G:\git\apache\maven-filtering\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not transfer artifact
org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(http://repo.maven.apache.org/maven2): Failed to transfer file:
http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom.
Return code is: 501 , ReasonPhrase:HTTPS Required. and 'parent.relativePath'
points at wrong local POM @ line 23, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{noformat}
Solution
Use Maven 3.3.9, maybe earlier, we need to check that
*You cannot use Java 7, because Maven central requires TLS 1.2+*
https://blog.sonatype.com/enhancing-ssl-security-and-http/2-support-for-central
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
{noformat}
G:\git\apache\maven-filtering>mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files\apache-maven-3.3.9
Java version: 1.7.0_79, vendor: Oracle Corporation
...
{noformat}
{noformat}
G:\git\apache\maven-filtering>mvn clean
[INFO] Scanning for projects...
Downloading:
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/34/maven-shared-components-34.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version
and 'parent.relativePath' points at wrong local POM @ line 23, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT
(G:\git\apache\maven-filtering\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
org.apache.maven.shared:maven-filtering:3.2.0-SNAPSHOT: Could not transfer
artifact org.apache.maven.shared:maven-shared-components:pom:34 from/to central
(https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version
and 'parent.relativePath' points at wrong local POM @ line 23, column 11 ->
[Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{noformat}
Solution 1
Use Java 8 with toolchains
mvn release:prepare -Pjdk-toolchain
Solution 2
Add protocols on the command line
mvn release:prepare -Dhttps.protocols=TLSv1.2
*No instructions for using toolchains*
For my release I went with solution 1, and it took me a while to figure out
which combination of command line switches to use. Here's what
[jira] [Commented] (MNG-6970) Mvn -v in cmd shows Syntax of the command is incorrect
[
https://issues.apache.org/jira/browse/MNG-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166212#comment-17166212
]
Dennis Lundberg commented on MNG-6970:
--
Did you follow the guide to installing Maven here?
https://maven.apache.org/install.html
The error message comes from Windows. I found this link when searching the web:
https://www.computerhope.com/issues/ch001336.htm
Can you please try running this command, including the " characters:
{noformat}
"C:\Program Files\maven\apache-maven-3.3.1\bin\mvn" -version
{noformat}
> Mvn -v in cmd shows Syntax of the command is incorrect
> ---
>
> Key: MNG-6970
> URL: https://issues.apache.org/jira/browse/MNG-6970
> Project: Maven
> Issue Type: Bug
>Reporter: vignesh GOVINDARAJ
>Priority: Major
> Labels: Maven, configuration, installation, or
> Fix For: wontfix-candidate
>
>
> I configured maven in Windows 10 machine, while verifying configuration mvn
> -v or mvn -version in cmd it shows Syntax of the command is incorrect
>
> I tried navigating to the maven repository still same error,
> Java - version
> 1.8.0
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASFRES-37) Mvn -v in cmd shows Syntax of the command is incorrect
[
https://issues.apache.org/jira/browse/MASFRES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165527#comment-17165527
]
Dennis Lundberg commented on MASFRES-37:
This is what I get on my Windows 10 from cmd prompt.
What does your output look like?
{noformat}
C:\Program Files>mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files (x86)\apache-maven-3.3.9
Java version: 1.8.0_242, vendor: AdoptOpenJDK
Java home: C:\Program Files\Java\jdk-8.0.242.08-hotspot\jre
Default locale: sv_SE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
C:\Program Files>mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files (x86)\apache-maven-3.3.9
Java version: 1.8.0_242, vendor: AdoptOpenJDK
Java home: C:\Program Files\Java\jdk-8.0.242.08-hotspot\jre
Default locale: sv_SE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
{noformat}
> Mvn -v in cmd shows Syntax of the command is incorrect
> ---
>
> Key: MASFRES-37
> URL: https://issues.apache.org/jira/browse/MASFRES-37
> Project: Apache Maven Resource Bundles
> Issue Type: Bug
>Reporter: vignesh GOVINDARAJ
>Priority: Major
> Labels: Maven, configuration, installation, or
>
> I configured maven in Windows 10 machine, while verifying configuration mvn
> -v or mvn -version in cmd it shows Syntax of the command is incorrect
>
> I tried navigating to the maven repository still same error,
> Java - version
> 1.8.0
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6969) mvn clean install fails for helloworld projects with java-11
[ https://issues.apache.org/jira/browse/MNG-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165475#comment-17165475 ] Dennis Lundberg commented on MNG-6969: -- Hi, If you target Java 9 or higher you might need to specify a newer version of maven-compiler-plugin. Read more here: https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html#java-9-or-later > mvn clean install fails for helloworld projects with java-11 > > > Key: MNG-6969 > URL: https://issues.apache.org/jira/browse/MNG-6969 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: solo turn >Priority: Major > > mvn clean install fails for hello world projects with java-11 with an error > caused by using a too old compiler plugin: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) > on project deploy-at-end-one: Compilation failure: Compilation failure: > [ERROR] Source option 5 is no longer supported. Use 6 or later. > [ERROR] Target option 1.5 is no longer supported. Use 1.6 or later. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > [http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASFRES-37) Mvn -v in cmd shows Syntax of the command is incorrect
[ https://issues.apache.org/jira/browse/MASFRES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165470#comment-17165470 ] Dennis Lundberg commented on MASFRES-37: Hi, we need more information to debug your issue. Please provide information about what you are trying to do, what maven command you are using, what you expect to happen and finally the error message you get. > Mvn -v in cmd shows Syntax of the command is incorrect > --- > > Key: MASFRES-37 > URL: https://issues.apache.org/jira/browse/MASFRES-37 > Project: Apache Maven Resource Bundles > Issue Type: Bug >Reporter: vignesh GOVINDARAJ >Priority: Major > Labels: Maven, configuration, installation, or > > I configured maven in Windows 10 machine, while verifying configuration mvn > -v or mvn -version in cmd it shows Syntax of the command is incorrect > > I tried navigating to the maven repository still same error, > Java - version > 1.8.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162755#comment-17162755
]
Dennis Lundberg commented on MNG-6965:
--
My guess is that the components.xml file used to declare Plexus components,
somehow has a (runtime?) dependency on plexus-utils. We need someone who knows
Plexus to answer this.
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Priority: Major
> Labels: archetype
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg reassigned MNG-6964:
Assignee: Dennis Lundberg
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Assignee: Dennis Lundberg
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162638#comment-17162638
]
Dennis Lundberg commented on MNG-6964:
--
There was a bug in the comparison logic. This was triggered for qualifiers that
starting with "-0.". Thanks for reporting this!
I've committed a fix with accompanying test cases. I'd be great if someone
could review it.
https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=4f193b3fc26c2ccf2a1b7a34917faccedac1ea0e
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6967) Improve the command line output from maven-artifact
[ https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162620#comment-17162620 ] Dennis Lundberg commented on MNG-6967: -- I've committed a fix for this. Please review. https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=51c0399030dcb0b88080a7f9e50c3d09c6913dda If this is accepted, we need to update the example on the site to reflect the new output, when the next version has been released. > Improve the command line output from maven-artifact > --- > > Key: MNG-6967 > URL: https://issues.apache.org/jira/browse/MNG-6967 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Major > > As is documented here > https://maven.apache.org/pom.html#version-order-testing > you can use the maven-artifact JAR file to test version numbers and their > relative order. > Unfortunately the output does not match what is used in > https://maven.apache.org/pom.html#version-order-specification > when describing the "Trimming Examples". It's matter of "==" versus "->". I > prefer the one used in the documentation, so I'd like to change > maven-artifact to use "->". It respresents a transformation (trimming in this > case) - not a an equality test. > Another problem is that it does not show you the list of tokens that are the > result of parsing the version numbers. This can be quite useful when trying > to figure out why you are getting the results you are. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6967) Improve the command line output from maven-artifact
[ https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MNG-6967: Assignee: Dennis Lundberg > Improve the command line output from maven-artifact > --- > > Key: MNG-6967 > URL: https://issues.apache.org/jira/browse/MNG-6967 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Major > > As is documented here > https://maven.apache.org/pom.html#version-order-testing > you can use the maven-artifact JAR file to test version numbers and their > relative order. > Unfortunately the output does not match what is used in > https://maven.apache.org/pom.html#version-order-specification > when describing the "Trimming Examples". It's matter of "==" versus "->". I > prefer the one used in the documentation, so I'd like to change > maven-artifact to use "->". It respresents a transformation (trimming in this > case) - not a an equality test. > Another problem is that it does not show you the list of tokens that are the > result of parsing the version numbers. This can be quite useful when trying > to figure out why you are getting the results you are. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6967) Improve the command line output from maven-artifact
Dennis Lundberg created MNG-6967: Summary: Improve the command line output from maven-artifact Key: MNG-6967 URL: https://issues.apache.org/jira/browse/MNG-6967 Project: Maven Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 3.6.3 Reporter: Dennis Lundberg As is documented here https://maven.apache.org/pom.html#version-order-testing you can use the maven-artifact JAR file to test version numbers and their relative order. Unfortunately the output does not match what is used in https://maven.apache.org/pom.html#version-order-specification when describing the "Trimming Examples". It's matter of "==" versus "->". I prefer the one used in the documentation, so I'd like to change maven-artifact to use "->". It respresents a transformation (trimming in this case) - not a an equality test. Another problem is that it does not show you the list of tokens that are the result of parsing the version numbers. This can be quite useful when trying to figure out why you are getting the results you are. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162072#comment-17162072
]
Dennis Lundberg commented on MNG-6964:
--
Well then I'm sorry if I came across as passive aggressive. I am sincerely only
trying to help here.
Since I am not familiar with the code, I'd like to make sure I understand the
problem before I dive into any code. To do so I ask questions. That is not
meant to question anyone's knowledge. I did give a reference to the
specification, in case the reporter had not read it or could not find it.
Now we know it was a typo and what the problematic version strings do look
like. That is progress. I am currently digging through the code and have found
the class that handles most of this:
org/apache/maven/artifact/versioning/ComparableVersion.java
Tomorrow I will check the tests to see if I can find any omissions in the
comparison logic.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162032#comment-17162032
]
Dennis Lundberg commented on MNG-6964:
--
I'm sorry for trying to understand the problem.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162026#comment-17162026
]
Dennis Lundberg commented on MRESOURCES-254:
Thanks for clarifying. That certainly looks like a valid use case.
I am not a developer on Maven core, but I don't see any other way for than to
duplicate that property. Once using @@ for maven-resources-plugin and another
using ${} for other plugin configuration in the POM.
You can read about model interpolation here:
[https://maven.apache.org/ref/3.6.3/maven-model-builder/]
That describes when the replacement of ${...} in the POM occurs.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test-updated.zip, test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162012#comment-17162012
]
Dennis Lundberg commented on MNG-6964:
--
I think that you are missing my point. The version numbers that you have used
in your console example are very odd, and also they do not conform to the
semver specification. If I make a guess as to what you want to compare, it
would look like this, using more usual version numbers:
{noformat}
$ java -jar maven-artifact-3.6.3.jar 1.0-alpha 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0-alpha == 1-alpha
1.0-alpha < 1
2. 1 == 1
$ java -jar maven-artifact-3.6.3.jar 1.0-beta 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0-beta == 1-beta
1.0-beta < 1
2. 1 == 1
$ java -jar maven-artifact-3.6.3.jar 1.0-beta 1.0-alpha
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0-beta == 1-beta
1.0-beta > 1.0-alpha
2. 1.0-alpha == 1-alpha
{noformat}
As you can see these results are different than yours, and inline with your
expectations.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161976#comment-17161976
]
Dennis Lundberg commented on MRESOURCES-254:
Thanks for the example [~andrebrait]. Now I understand what you mean.
Properties that are created by plugins like buildnumber-maven-plugin are
available automatically in the POM. You don't need to assign them to a property
yourself in the section. In your example you can just use
${buildNumber} in the last argument for exec-maven-plugin, like this:
{code:xml}
prop8=${buildNumber}.
{code}
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test-updated.zip, test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161889#comment-17161889
]
Dennis Lundberg commented on MNG-6965:
--
I can confirm that plexus-utils:1.1 gets downloaded using Maven 3.6.3 with a
clean repo and the command line:
mvn clean
for the attached project.
However I have not been able to establish why.
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Priority: Major
> Labels: archetype
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization, meaning such a pom always fails.
> {{http://maven.apache.org/POM/4.0.0"}}
> {{xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
> {{xsi:schemaLocation="http://maven.apache.org/POM/4.0.0}}
> {{[http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{4.0.0}}
> {{test}}
> {{test}}
> {{0.0.1-SNAPSHOT}}
> {{maven-archetype}}
> {{test}}
> {{}}
> {{ }}
> {{}}
> {{org.apache.maven.archetype}}
> {{archetype-packaging}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{org.apache.maven.plugins}}
> {{maven-archetype-plugin}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
>
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {{[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}}}
> {{[DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:}}
> {{[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime}}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161836#comment-17161836
]
Dennis Lundberg edited comment on MNG-6965 at 7/21/20, 7:56 AM:
I guess that the reason it is banned is because of vulnerabilities?
[https://snyk.io/vuln/maven:org.codehaus.plexus%3Aplexus-utils]
A good way to find out from where a dependency is pulled in is to use this
command on the project that is pulling the dependency in question. In this case
archetype-packaging:
{noformat}
mvn dependency:tree
{noformat}
was (Author: dennisl):
I guess that the reason it is banned because of vulnerabilities?
https://snyk.io/vuln/maven:org.codehaus.plexus%3Aplexus-utils
A good way to find out from where a dependency is pulled in is to use this
command on the project that is pulling the dependency in question. In this case
archetype-packaging:
{noformat}
mvn dependency:tree
{noformat}
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Priority: Major
> Labels: archetype
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization, meaning such a pom always fails.
> {{http://maven.apache.org/POM/4.0.0"}}
> {{xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
> {{xsi:schemaLocation="http://maven.apache.org/POM/4.0.0}}
> {{[http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{4.0.0}}
> {{test}}
> {{test}}
> {{0.0.1-SNAPSHOT}}
> {{maven-archetype}}
> {{test}}
> {{}}
> {{ }}
> {{}}
> {{org.apache.maven.archetype}}
> {{archetype-packaging}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{org.apache.maven.plugins}}
> {{maven-archetype-plugin}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
>
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {{[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}}}
> {{[DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:}}
> {{[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime}}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161836#comment-17161836
]
Dennis Lundberg commented on MNG-6965:
--
I guess that the reason it is banned because of vulnerabilities?
https://snyk.io/vuln/maven:org.codehaus.plexus%3Aplexus-utils
A good way to find out from where a dependency is pulled in is to use this
command on the project that is pulling the dependency in question. In this case
archetype-packaging:
{noformat}
mvn dependency:tree
{noformat}
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Priority: Major
> Labels: archetype
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization, meaning such a pom always fails.
> {{http://maven.apache.org/POM/4.0.0"}}
> {{xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
> {{xsi:schemaLocation="http://maven.apache.org/POM/4.0.0}}
> {{[http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{4.0.0}}
> {{test}}
> {{test}}
> {{0.0.1-SNAPSHOT}}
> {{maven-archetype}}
> {{test}}
> {{}}
> {{ }}
> {{}}
> {{org.apache.maven.archetype}}
> {{archetype-packaging}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{org.apache.maven.plugins}}
> {{maven-archetype-plugin}}
> {{3.1.2}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
>
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {{[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}}}
> {{[DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:}}
> {{[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime}}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161830#comment-17161830
]
Dennis Lundberg commented on MNG-6964:
--
You can read about how the sorting of versions work here:
https://maven.apache.org/pom.html#version-order-specification
It seems that you are mixing dots '.' and hyphen '-' as if they are
interchangeable, but they are not. They have an important meaning when parsing
a version number. It says on the above page:
_"This gives a sequence of version numbers (numeric tokens) and version
qualifiers (non-numeric tokens) with "." or "-" prefixes."_
In your first console example you use the versions 1-0.beta and 1-0.alpha, but
in your conclusion you use 1-0.beta and 1.0.alpha. Note that the difference
between dots and hyphens. 1-0.alpha is not the same as 1.0.alpha.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1.0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161244#comment-17161244
]
Dennis Lundberg commented on MRESOURCES-254:
I'm not sure that I understand.
Could you give an example?
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-132) Copying of files with permissions broken
[
https://issues.apache.org/jira/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161231#comment-17161231
]
Dennis Lundberg commented on MRESOURCES-132:
MRESOURCES-236 has been fixed and will be included in the upcoming version
3.2.0.
If you have the possiblility, please try 3.2.0-SNAPSHOT.
If you have comments, please do so in MRESOURCES-236.
> Copying of files with permissions broken
>
>
> Key: MRESOURCES-132
> URL: https://issues.apache.org/jira/browse/MRESOURCES-132
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> Files with permissions are not copied with the permissions as illustrated
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find .
> -name *perm*`
> -rwxr--r-- 1 root root 8 2010-12-09 20:48
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root 8 2010-12-09 22:56
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-263) Use non-shapshot maven-filtering
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-263: --- Fix Version/s: 3.2.0 > Use non-shapshot maven-filtering > > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161213#comment-17161213
]
Dennis Lundberg commented on MRESOURCES-254:
Okay I figured this out now.
maven-resource-plugin filters the files that needs to be filtered using the
filtering properties that it knows about. When doing that it is using the
delimiters specified. The defined in the pom.xml are given to the
plugin exactly as they are specified in the POM, except that properties used
inside another property are interpolated.
This means that in your project prop2="1-2" and prop3="1-${buildNumber}". These
are then passed to the resources plugin.
In your project the plugin will try to filter anything that matches the
delimiters @@. Even though there exists a filtering property called
buildNumber, it will not be used because prop3 does not have "@buildNumber@" in
it. It does however have "@{buildNumber}, but that is a no-op because the
default delimiters have been disabled.
The solution to your problem is that you need to use the same delimiters in the
values of the in the POM that you have configured the resource
plugin to use. You need to replace ${buildNumber} in the POM with
@buildNumber@, and then it will work.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161177#comment-17161177
]
Dennis Lundberg edited comment on MRESOURCES-254 at 7/20/20, 12:47 PM:
---
Good example to test!
That fails as well.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
was (Author: dennisl):
Good example to test! But it actually works fine.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161177#comment-17161177
]
Dennis Lundberg commented on MRESOURCES-254:
Good example to test! But it actually works fine.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161120#comment-17161120
]
Dennis Lundberg commented on MRESOURCES-254:
Hi,
I can confirm the results in your test project.
However if I add this property to the pom.xml
{code:xml}
${prop1}-${prop2}
{code}
and this to src/main/resources/someText.txt
{noformat}
But this does: @prop6@
{noformat}
the output for prop6 is correct, even when I set useDefaultDelimiters to false.
So maven-resources-plugin does have support for compound properties.
This makes me suspect that it might have something to do with
buildnumber-maven-plugin, but I haven't investigated that.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRESOURCES-263) Use non-shapshot maven-filtering
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MRESOURCES-263: -- Assignee: Dennis Lundberg > Use non-shapshot maven-filtering > > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-210) copy-resources erases file permissions
[ https://issues.apache.org/jira/browse/MRESOURCES-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-210. -- Fix Version/s: 3.2.0 Assignee: Olivier Lamy Resolution: Fixed > copy-resources erases file permissions > -- > > Key: MRESOURCES-210 > URL: https://issues.apache.org/jira/browse/MRESOURCES-210 > Project: Maven Resources Plugin > Issue Type: Bug >Reporter: Volodymyr Kyrychenko >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > > rwx posix permission should be kept. There is possibility to do that now: > java.nio.file.Files.setPosixFilePermissions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOURCES-236) Copying of files with permissions broken
[ https://issues.apache.org/jira/browse/MRESOURCES-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-236: --- Fix Version/s: 3.2.0 > Copying of files with permissions broken > > > Key: MRESOURCES-236 > URL: https://issues.apache.org/jira/browse/MRESOURCES-236 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 2.4.3 >Reporter: Gili >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > > Please reopen MRESOURCES-132 as multiple reporters indicate that the bug > still exists (some provided more concrete repro steps). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-253) Convention over configuration of filtered resources
[
https://issues.apache.org/jira/browse/MRESOURCES-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MRESOURCES-253.
--
Resolution: Won't Fix
This needs to be fixed in maven core. See linked 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)
[jira] [Closed] (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
]
Dennis Lundberg closed MRESOURCES-258.
--
Fix Version/s: 3.2.0
Assignee: Olivier Lamy
Resolution: Fixed
> 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
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.0
>
>
> 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] [Closed] (MRESOURCES-261) Make Maven 3.1.0 the minimum version
[ https://issues.apache.org/jira/browse/MRESOURCES-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-261. -- Fix Version/s: 3.2.0 Assignee: Elliotte Rusty Harold Resolution: Fixed > 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 >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (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:all-tabpanel ] Dennis Lundberg reassigned MRESOURCES-171: -- Assignee: Dennis Lundberg > 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 >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 3.2.0 > > 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] (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:all-tabpanel ] Dennis Lundberg closed MRESOURCES-171. -- Resolution: Fixed > 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 >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 3.2.0 > > 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-934) Allow using a different encoding when filtering properties files
[ https://issues.apache.org/jira/browse/MSHARED-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSHARED-934. --- Resolution: Fixed > Allow using a different encoding when filtering properties files > > > Key: MSHARED-934 > URL: https://issues.apache.org/jira/browse/MSHARED-934 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-filtering >Affects Versions: maven-filtering-3.1.1 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Major > Fix For: maven-filtering-3.2.0 > > > See MRESOURCES-171 for the full description of the problem. > We need to allow the plugin that uses maven-filtering to specify an encoding > to be used when filtering properties files, that is different from the > encoding used when filtering regular files. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-297) Commandline class shell injection vulnerabilities
[
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161054#comment-17161054
]
Dennis Lundberg commented on MSHARED-297:
-
Can this issue be closed now?
> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Reporter: Charles Duffy
>Priority: Critical
> Labels: SECURITY
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping,
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings
> (including the name of the command itself being quoted), with {{'"'"'}} used
> for embedded single quotes, for maximum safety across shells implementing a
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is
> submitted here in the hope that it will be useful, though it is not expected
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-431) # (Hash-Sign) should trigger quoting in BourneShell.java
[ https://issues.apache.org/jira/browse/MSHARED-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161053#comment-17161053 ] Dennis Lundberg commented on MSHARED-431: - Can this issue be closed now? > # (Hash-Sign) should trigger quoting in BourneShell.java > > > Key: MSHARED-431 > URL: https://issues.apache.org/jira/browse/MSHARED-431 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.8 > Environment: Unix (Linux) >Reporter: Fritz Elfert >Priority: Major > > When trying to use the latest maven-jarsign-plugin using a keystore-password > which started with a hash (#), signing failed. After enabling debug output > with -X, I got a strange debug message: > [DEBUG] Option lacks argument > Since signtool is invoked using /bin/sh -c ..., of course, any # must be > quoted, because otherwise it acts as a comment-start and thus effectively > cuts-off the rest of the cmdline. > After single-quoting the password in the pom.xml, the jar signing was ok. > => > Adding '#' to BASH_QUOTING_TRIGGER_CHARS in > org.apache.maven.shared.utils.cli.shell.BourneShell.java should fix the > problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-860) Deprecate obsolete functionality
[ https://issues.apache.org/jira/browse/MSHARED-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161045#comment-17161045 ] Dennis Lundberg commented on MSHARED-860: - Are we ready to close this issue? All pull request seems to have been merged. > Deprecate obsolete functionality > > > Key: MSHARED-860 > URL: https://issues.apache.org/jira/browse/MSHARED-860 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Large chunks of org.apache.maven.shared.utils are out of date and duplicate > better maintained code in the Java class libraries, Apache Commons Lang, > Apache Commons I/O, or even all three. > > Add deprecation comments and annotations to such methods, classes, and fields > with pointers to the modern replacements for this functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (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:all-tabpanel
]
Dennis Lundberg reassigned MRESOURCES-232:
--
Fix Version/s: (was: 3.2.0)
Assignee: (was: Dennis Lundberg)
> 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)
[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=17159935#comment-17159935
]
Dennis Lundberg commented on MRESOURCES-232:
I have updated the documentation for the "encoding" parameter to clarify that
it is used for both reading and writing resources. That will come with version
3.2.0 of the plugin.
The need for different input and output encoding parameters have not yet been
solved.
> 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)
[jira] [Updated] (MSHARED-884) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MSHARED-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSHARED-884:
Fix Version/s: maven-filtering-3.2.0
> 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
> Fix For: maven-filtering-3.2.0
>
>
> 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] [Closed] (MSHARED-884) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MSHARED-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MSHARED-884.
---
Resolution: Fixed
> 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
> Fix For: maven-filtering-3.2.0
>
>
> 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-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:all-tabpanel ] Dennis Lundberg updated MRESOURCES-171: --- Fix Version/s: 3.2.0 > 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 > Fix For: 3.2.0 > > 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] (MRESOURCES-257) property from list element in pom model
[
https://issues.apache.org/jira/browse/MRESOURCES-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MRESOURCES-257.
--
Assignee: Dennis Lundberg
Resolution: Fixed
I converted the supplied sample project (thank you) into an integration test,
to verify that this issue has been solved.
> property from list element in pom model
> ---
>
> Key: MRESOURCES-257
> URL: https://issues.apache.org/jira/browse/MRESOURCES-257
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: linux
>Reporter: Ernst Reissner
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: project.tar
>
>
> I tried to filter $\{project.developers[0].email}
> Although mvn help:evaluate finds the correct answer, filtering does not work
> else.
> Even if i havein the properties section of the pom one of the three
> ernst.reiss...@simuline.eu
> ${project.organization.name}
> $\{project.developers[0].email}
> the latter is not replaced and just comes litterally.
>
> Update: I added a minimal project
> comprising a pom and some resource to be filtered.
> What we see is, that ${project.organization.name} is filtered,
> whereas $\{project.developers[0].email} is not: remains literal.
>
> Also I think, better than developers[0] would be a way to use a label,
> e.g. a key, like an identifier. (but this is a feature request. )
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOURCES-256) make build Reproducible
[ https://issues.apache.org/jira/browse/MRESOURCES-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-256. -- Resolution: Fixed > make build Reproducible > --- > > Key: MRESOURCES-256 > URL: https://issues.apache.org/jira/browse/MRESOURCES-256 > Project: Maven Resources Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-936) Set minimum required Maven version to 3.1.0 and switch to Eclipse Aether
[ https://issues.apache.org/jira/browse/MSHARED-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSHARED-936: Summary: Set minimum required Maven version to 3.1.0 and switch to Eclipse Aether (was: Set minimum supported Maven version to 3.1.0 and switch to Eclipse Aether) > Set minimum required Maven version to 3.1.0 and switch to Eclipse Aether > > > Key: MSHARED-936 > URL: https://issues.apache.org/jira/browse/MSHARED-936 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-936) Set minimum supported Maven version to 3.1.0 and switch to Eclipse Aether
[ https://issues.apache.org/jira/browse/MSHARED-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSHARED-936: Summary: Set minimum supported Maven version to 3.1.0 and switch to Eclipse Aether (was: Set minimum supported Maven version to 3.1.0) > Set minimum supported Maven version to 3.1.0 and switch to Eclipse Aether > - > > Key: MSHARED-936 > URL: https://issues.apache.org/jira/browse/MSHARED-936 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- 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=17159737#comment-17159737 ] Dennis Lundberg commented on MRESOURCES-171: After having slept on this I realize that we should do the same thing as we did with the encoding parameter. We start out with an INFO about the situation and encourage our users to set the new propertiesEncding parameter. Some time later, say a year from now or so, we can turn that INFO into a WARN. That will give people like Anders and myself plenty of time to adjust our POMs to ensure that we don't get any warnings in our logs when we upgrade to the latest version of the plugin a year from now. What are your thoughts [~afloom] ? > 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=17159249#comment-17159249 ] Dennis Lundberg commented on MRESOURCES-171: Thanks for the feedback [~afloom] ! I have updated the requirements list in the previous comment, to make it clearer. The goal is to make the warning as unobtrusive as we possibly can. But, yes, there will be cases when you will need to configure the new parameter to avoid the warning. The example you give is one of those. This is of course unfortunate, but in the previous discussions we have concluded that we should not use convention over configuration here, simply because it will break some builds. The alternative we have is to inform those whose current builds might be broken, they just do not know it yet. We are at a similar place we where way back in 2008, when we changed the INFO to a WARN if no encoding was specified. Some people will get annoyed by the WARN cluttering their build logs. I know, I'm one of those people :) But unless we have a good solid convention over configuration to rely on all we can do is nag our users to make an informed decision that fits their project. > 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] [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=17159155#comment-17159155 ] Dennis Lundberg edited comment on MRESOURCES-171 at 7/16/20, 2:09 PM: -- I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The method DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, without having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # the propertiesEncoding parameter has not been set # properties is a filtered extension # filtering is enabled for at least one resource # there is at least one properties file in one of the resources that has filtering enabled Thoughs and comments are most welcome! was (Author: dennisl): I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The method DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, without having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! > 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] [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=17159155#comment-17159155 ] Dennis Lundberg edited comment on MRESOURCES-171 at 7/16/20, 12:02 PM: --- I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The method DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, without having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! was (Author: dennisl): I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, wihtout having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! > 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] [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=17159155#comment-17159155 ] Dennis Lundberg edited comment on MRESOURCES-171 at 7/16/20, 12:01 PM: --- I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, wihtout having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! was (Author: dennisl): I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The in DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, wihtout having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! > 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=17159155#comment-17159155 ] Dennis Lundberg commented on MRESOURCES-171: I'm trying to work out how to warn the users properly, if they have not set the new parameter for properties file encoding. The in DefaultMavenResourcesFiltering#filterResources() in maven-filtering currently handles warning users if they have not set the regular encoding parameter. So I would like to add the new warning there as well. That way all plugins will benefit from this, wihtout having to write any code for it. Locally I tried to add the warning in a similar way as for regular encoding. That however gets very noisy, since all the builds in the world would get this warning, if they just update to the new plugin. So I'm trying to make a fail fast, and not too time consuming, educated guess as to whether a project warrants a warning or not. Here's what I've thought of so far. Show a warning to the user if *all* of the following are true: # .properties is a filtered extension, taking into account any configured nonFilteredFileExtensions # resource.isFiltering() is true for any of the resources # there is at least one properties file among all the files in all the resources Thoughs and comments are most welcome! > 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=17159035#comment-17159035 ] Dennis Lundberg commented on MRESOURCES-171: True, you can use Unicode escapes to work around the problem. The downside of that is that you loose the readability for humans. ResourceBundles used for localization is an example where that workaround probably wouldn't work very well. Sorry, I forgot to write down my own assumptions about Herves suggestion :) I saw that his configuration was meant for the plugin. However I discarded that as a viable solution, since I don't think having almost the same configuration for the same thing in 2 different locations in the POM is a wise move. It would of course be technically possible to implement, but the amount of confusion for our users and the amount of support questions would be massive in my opinion. > 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=17159009#comment-17159009 ] Dennis Lundberg commented on MRESOURCES-171: Yes, there may be encoding problems for other file types besides properties files. In most cases that can be solved by the author by simply changing the encoding of those files to match the sourceEncoding for the project. For properties files that is simply not possible due to what the Java version you are using dictates. I totally agree that Herves suggestion is the best and most flexible solution. Unfortunately it means adding new stuff to the POM, build/resources/resource/encoding. That means changes in maven-core instead of this plugin. It also means that it will not work for older versions of Maven and projects would need to migrate to POM version 5, which might not be possible because it is being used be downstream projects. I'm not saying we should not do that, but it will take time, a lot of time, before it is usable. In the mean time we need a solution for filtered 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] [Created] (MSHARED-934) Allow using a different encoding when filtering properties files
Dennis Lundberg created MSHARED-934: --- Summary: Allow using a different encoding when filtering properties files Key: MSHARED-934 URL: https://issues.apache.org/jira/browse/MSHARED-934 Project: Maven Shared Components Issue Type: New Feature Components: maven-filtering Affects Versions: maven-filtering-3.1.1 Reporter: Dennis Lundberg Assignee: Dennis Lundberg Fix For: maven-filtering-3.1.2 See MRESOURCES-171 for the full description of the problem. We need to allow the plugin that uses maven-filtering to specify an encoding to be used when filtering properties files, that is different from the encoding used when filtering regular files. -- 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)
[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] (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)
[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)
[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] [Created] (MJDEPS-23) The parameter multiRelease should have a user property so that you can set it from the command line
Dennis Lundberg created MJDEPS-23: - Summary: The parameter multiRelease should have a user property so that you can set it from the command line Key: MJDEPS-23 URL: https://issues.apache.org/jira/browse/MJDEPS-23 Project: Maven JDeps Plugin Issue Type: Improvement Affects Versions: 3.1.1 Reporter: Dennis Lundberg This gives you the ability to change this parameter from the command line, to try different values, without having to change the pom.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
