[jira] [Commented] (MNG-5956) Invalid DuplicateProjectException if physically same pom.xml
[ https://issues.apache.org/jira/browse/MNG-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076295#comment-15076295 ] ASF GitHub Bot commented on MNG-5956: - Github user nhojpatrick commented on the pull request: https://github.com/apache/maven/pull/75#issuecomment-168305170 I've worked on 5+ projects where they ranged from 75-150 maven projects. Allow this configuration would have simplified and reduce build times. The usual work around I've seen is developers creating scripts to manually navigate to dependencies within the same multi module project structure. When you have 10-40 developers working on a project I would prefer maven to handle this so everyone uses mvn clean install, instead of scripts being email or shared around or random scripts littering the repo. I've created a very basic project which demonstrates what I would like to allow happen and current fails. https://github.com/nhojpatrick/apache.maven.maven-core.MNG-5956 > Invalid DuplicateProjectException if physically same pom.xml > > > Key: MNG-5956 > URL: https://issues.apache.org/jira/browse/MNG-5956 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.2.x > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) > Maven home: /opt/local/share/java/maven3 > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.11.2", arch: "x86_64", family: "mac" >Reporter: John Patrick > Labels: github-import, newbie, patch > > Several projects I've worked on have lots of modules, some to aid developers > sub modules have been hijacked to also build other projects. Take the > following example. > ./pom.xml > ./common/pom.xml > ./sub1/pom.xml > ./sub2/pom.xml > If sub1 and sub2 both include ../common then > DuplicateProjectException is thrown. I've created a patch which before > throwing the exception does one last check to ignore instances where the > clash is actually the same physical pom file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5956) Invalid DuplicateProjectException if physically same pom.xml
[ https://issues.apache.org/jira/browse/MNG-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076297#comment-15076297 ] ASF GitHub Bot commented on MNG-5956: - Github user khmarbaise commented on the pull request: https://github.com/apache/maven/pull/75#issuecomment-168306169 First i see your setup as wrong..cause you use modules multiple times within the reactor (Apart from using `..` which is simply not needed`). What i don't understand is why would this setup reduce build time? Can you elaborate a little bit more how that influences the build time? And what do you mean by searching the dependencies within a multi module build ? > Invalid DuplicateProjectException if physically same pom.xml > > > Key: MNG-5956 > URL: https://issues.apache.org/jira/browse/MNG-5956 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.2.x > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) > Maven home: /opt/local/share/java/maven3 > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.11.2", arch: "x86_64", family: "mac" >Reporter: John Patrick > Labels: github-import, newbie, patch > > Several projects I've worked on have lots of modules, some to aid developers > sub modules have been hijacked to also build other projects. Take the > following example. > ./pom.xml > ./common/pom.xml > ./sub1/pom.xml > ./sub2/pom.xml > If sub1 and sub2 both include ../common then > DuplicateProjectException is thrown. I've created a patch which before > throwing the exception does one last check to ignore instances where the > clash is actually the same physical pom file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5956) Invalid DuplicateProjectException if physically same pom.xml
[ https://issues.apache.org/jira/browse/MNG-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076308#comment-15076308 ] ASF GitHub Bot commented on MNG-5956: - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/75#issuecomment-168311704 I second @khmarbaise answer, I do neither understand the problem you have. Looking at the demo project you have provided, I looks completely screwed up. Modules are supposed to be once int he reactor. It rather looks like a mess. > Invalid DuplicateProjectException if physically same pom.xml > > > Key: MNG-5956 > URL: https://issues.apache.org/jira/browse/MNG-5956 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.2.x > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) > Maven home: /opt/local/share/java/maven3 > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.11.2", arch: "x86_64", family: "mac" >Reporter: John Patrick > Labels: github-import, newbie, patch > > Several projects I've worked on have lots of modules, some to aid developers > sub modules have been hijacked to also build other projects. Take the > following example. > ./pom.xml > ./common/pom.xml > ./sub1/pom.xml > ./sub2/pom.xml > If sub1 and sub2 both include ../common then > DuplicateProjectException is thrown. I've created a patch which before > throwing the exception does one last check to ignore instances where the > clash is actually the same physical pom file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5829) mvn on Solaris 10 fails with syntax error
[
https://issues.apache.org/jira/browse/MNG-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5829.
---
Resolution: Not A Problem
I believe this has been already fixed. Several improvements for Solaris quirks
have been made and no {{$()}} calls are present in the script. If this is still
an issue, reopen and provide a patch.
> mvn on Solaris 10 fails with syntax error
> -
>
> Key: MNG-5829
> URL: https://issues.apache.org/jira/browse/MNG-5829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3
> Environment: Solaris 10
>Reporter: Zac Thompson
>Priority: Minor
>
> The {{$(cmd)}} idiom is used extensively in bin/mvn from lines 199-220, but
> this is not supported by older incarnations of /bin/sh (used on the shebang
> line). The {{`cmd`}} idiom is slightly more portable, and looks like it can
> probably be directly substituted.
> {noformat}
> find_maven_basedir() {
> local basedir=$(pwd)
> local wdir=$(pwd)
> while [ "$wdir" != '/' ] ; do
> wdir=$(cd "$wdir/.."; pwd)
> if [ -d "$wdir"/.mvn ] ; then
> basedir=$wdir
> break
> fi
> done
> echo "${basedir}"
> }
> # concatenates all lines of a file
> concat_lines() {
> if [ -f "$1" ]; then
> echo "$(tr -s '\n' ' ' < "$1")"
> fi
> }
> export MAVEN_PROJECTBASEDIR=${MAVEN_BASEDIR:-$(find_maven_basedir)}
> MAVEN_OPTS="$(concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config")
> $MAVEN_OPTS"
> {noformat}
> See MNG-5658 for an earlier case of a similar problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076319#comment-15076319 ] Jason van Zyl commented on MNG-5728: So I'll give you some food for thought. This doesn't make Maven more secure, really, but it would help with artifacts not being downloaded entirely or correctly. It was set to warn for historical reasons because many artifacts didn't have checksum files deployed. This has been largely corrected by the submission policy to Maven Central where there has to be checksum files. Where the cut off point in the past is I'm not sure. I'm also not sure how well organizations enforce this internally, especially where non-Maven systems are used to deploy. While I agree it makes sense to be the default I'd like to prevent the potential where in a minor version change we make a major behavioral change that causes people a lot of grief. So I'm all for changing this but why don't we throw this in the bucket for 4.x where we make a other large changes: Java8, massive deprecation removal, removal of Plexus, and anything where people should know and understand the impact of changing. In this particular case I think there are more builds than you might expect that would be affected by this change. That's my take at any rate. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5829) mvn on Solaris 10 fails with syntax error
[
https://issues.apache.org/jira/browse/MNG-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076372#comment-15076372
]
Michael Osipov commented on MNG-5829:
-
See
[commit|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=d980040ffd4e4ad9343171140270c1725c19a6fe]
for the change.
> mvn on Solaris 10 fails with syntax error
> -
>
> Key: MNG-5829
> URL: https://issues.apache.org/jira/browse/MNG-5829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3
> Environment: Solaris 10
>Reporter: Zac Thompson
>Priority: Minor
>
> The {{$(cmd)}} idiom is used extensively in bin/mvn from lines 199-220, but
> this is not supported by older incarnations of /bin/sh (used on the shebang
> line). The {{`cmd`}} idiom is slightly more portable, and looks like it can
> probably be directly substituted.
> {noformat}
> find_maven_basedir() {
> local basedir=$(pwd)
> local wdir=$(pwd)
> while [ "$wdir" != '/' ] ; do
> wdir=$(cd "$wdir/.."; pwd)
> if [ -d "$wdir"/.mvn ] ; then
> basedir=$wdir
> break
> fi
> done
> echo "${basedir}"
> }
> # concatenates all lines of a file
> concat_lines() {
> if [ -f "$1" ]; then
> echo "$(tr -s '\n' ' ' < "$1")"
> fi
> }
> export MAVEN_PROJECTBASEDIR=${MAVEN_BASEDIR:-$(find_maven_basedir)}
> MAVEN_OPTS="$(concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config")
> $MAVEN_OPTS"
> {noformat}
> See MNG-5658 for an earlier case of a similar problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5728: Fix Version/s: Issues to be reviewed for 4.x > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > Fix For: Issues to be reviewed for 4.x > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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&focusedCommentId=15076375#comment-15076375 ] Aaron Digulla commented on MRESOURCES-171: -- [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's a real, serious, and causes data corruption. > 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 (v6.3.4#6332)
[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&focusedCommentId=15076375#comment-15076375 ] Aaron Digulla edited comment on MRESOURCES-171 at 1/1/16 9:15 PM: -- [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's real, serious, and causes data corruption. was (Author: digulla): [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's a real, serious, and causes data corruption. > 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 (v6.3.4#6332)
[jira] [Created] (WAGON-447) Upgrade to Commons Lang 3.4
Michael Osipov created WAGON-447: Summary: Upgrade to Commons Lang 3.4 Key: WAGON-447 URL: https://issues.apache.org/jira/browse/WAGON-447 Project: Maven Wagon Issue Type: Task Affects Versions: 2.11 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.11 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WAGON-447) Replace Commons Lang with Plexus Utils
[ https://issues.apache.org/jira/browse/WAGON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-447: - Summary: Replace Commons Lang with Plexus Utils (was: Upgrade to Commons Lang 3.4) > Replace Commons Lang with Plexus Utils > -- > > Key: WAGON-447 > URL: https://issues.apache.org/jira/browse/WAGON-447 > Project: Maven Wagon > Issue Type: Task >Affects Versions: 2.11 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 2.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-447) Replace Commons Lang with Plexus Utils
[
https://issues.apache.org/jira/browse/WAGON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076384#comment-15076384
]
Michael Osipov commented on WAGON-447:
--
Plexus Utils are used throughout but from Commons Lang only {{StringUtils}} are
used. Plexus Utils offers the same operations. We can replace and remove that
dependency.
> Replace Commons Lang with Plexus Utils
> --
>
> Key: WAGON-447
> URL: https://issues.apache.org/jira/browse/WAGON-447
> Project: Maven Wagon
> Issue Type: Task
>Affects Versions: 2.11
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.11
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-447) Replace Commons Lang with Plexus Utils
[ https://issues.apache.org/jira/browse/WAGON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076390#comment-15076390 ] Michael Osipov commented on WAGON-447: -- Pushed to branch [WAGON-447|https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=tree;h=refs/heads/WAGON-447;hb=refs/heads/WAGON-447] until tests can be run successfully. > Replace Commons Lang with Plexus Utils > -- > > Key: WAGON-447 > URL: https://issues.apache.org/jira/browse/WAGON-447 > Project: Maven Wagon > Issue Type: Task >Affects Versions: 2.11 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 2.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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&focusedCommentId=15076393#comment-15076393
]
Karl Heinz Marbaise commented on MRESOURCES-171:
Based on the documentation UTF-8 encoding it *NOT* illegal nor any other
encoding, cause if this would be true no one from other countries like Finland,
Norway, Sweden, Japan, China, Russia, just to mention a few etc. could ever
correctly define text messages in property files (cause those text won't work
with ISO-8859-1)...Based on the references you gave and quoted you should quote
the whole sentences:
{quote}
The load(InputStream) / store(OutputStream, String) methods work the same way
as the load(Reader)/store(Writer, String) pair, except the input/output stream
is encoded in ISO 8859-1 character encoding. Characters that cannot be directly
represented in this encoding can be written using Unicode escapes as defined in
section 3.3 of The Java™ Language Specification; only a single 'u' character is
allowed in an escape sequence. The native2ascii tool can be used to convert
property files to and from other character encodings.
{quote}
Furthermore if you take a deeper look into methods like
[load(InputStream):|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#load(java.io.InputStream)]
{quote}
Reads a property list (key and element pairs) from the input byte stream. The
input stream is in a simple line-oriented format as specified in load(Reader)
and is assumed to use the ISO 8859-1 character encoding; that is each byte is
one Latin1 character. Characters not in Latin1, and certain special characters,
are represented in keys and elements using Unicode escapes as defined in
section 3.3 of The Java™ Language Specification.
{quote}
Which is also talking about: {quote}and is assumed to use the ISO 8859-1
character encoding{quote} which does not mean they have to be encoded in
ISO-8859-1...only they can...
This means here. A property file is read by ISO8859-1 character encoding *if*
nothing else is defined which means nothing like {{-Dfile.encoding=...}} has
been defined for the JVM. Furthermore i have given an example how to copy
resources which are encoded in different encoding than the rest of your source
files which has been defined by
{{WhatEverYouUse}}.
> 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
(v6.3.4#6332)
