[jira] [Updated] (MNG-6259) Maven Resources Plugin copy error when filtering is true on a Mac
[
https://issues.apache.org/jira/browse/MNG-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fahd Siddiqui updated MNG-6259:
---
Description:
This is an error consistently seen on Mac (OS X 10.11.6), but it seems to work
fine on linux (our jenkins agent).
Basically, when `filtering` is set to true in the resources plugin, the
resource file contents are copied incorrectly converting \${something} to
${something}. Note the missing back-slash, and also that "something" is not a
maven variable. The expected behavior is to keep it unchanged. Here is a unit
test that shows the issue:
1. First, create a resource text file "new.test" with just the string
{code}\${something }{code}
2. Make sure that resource plugin has filtering set to "true":
{code}
src/test/resources
true
{code}
3. Create the unit test below:
{code}
@Test
public void test() throws IOException {
URL url = Resources.getResource("conf/new.test");
String text = Resources.toString(url, Charsets.UTF_8);
String expectedText = "\\${something }" ;
System.out.println("actual: " + text);
System.out.println("expected: " + expectedText);
assertEquals(expectedText, text);
}
{code}
3. Note that when you run the above test from the IDE directly, it passes.
4. Run `mvn clean install` from command line and verify the following error:
{code}
actual: ${something }
expected: \${something }
org.junit.ComparisonFailure:
Expected :\${something }
Actual :${something } ---> Note the back-slash has gone missing.
{code}
was:
This is an error consistently seen on Mac (OS X 10.11.6), but it seems to work
fine on linux (our jenkins agent).
Basically, when `filtering` is set to true in the resources plugin, the
resource file contents are copied incorrectly converting \${something} to
${something}. Note the missing back-slash, and also that "something" is not a
maven variable. The expected behavior is to keep it unchanged. Here is a unit
test that shows the issue:
1. First, create a resource text file "new.test" with just the string
{code}\${something }{code}
2. Make sure that resource plugin has filtering set to "true":
{code}
src/test/resources
true
{code}
3. Create the unit test below:
{code}
@Test
public void test() throws IOException {
URL url = Resources.getResource("conf/new.test");
String text = Resources.toString(url, Charsets.UTF_8);
String expectedText = "\\${something }" ;
System.out.println("actual: " + text);
System.out.println("expected: " + expectedText);
assertEquals(expectedText, text);
}
{code}
3. Note that when you run the above test from the IDE directly, it passes.
4. Run `mvn clean install` from command line and verify the following error:
{code}
actual: ${something }
expected: \${something }
org.junit.ComparisonFailure:
Expected :\${something }
Actual :${something }
{code}
> Maven Resources Plugin copy error when filtering is true on a Mac
> -
>
> Key: MNG-6259
> URL: https://issues.apache.org/jira/browse/MNG-6259
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.2.5
>Reporter: Fahd Siddiqui
>
> This is an error consistently seen on Mac (OS X 10.11.6), but it seems to
> work fine on linux (our jenkins agent).
> Basically, when `filtering` is set to true in the resources plugin, the
> resource file contents are copied incorrectly converting \${something} to
> ${something}. Note the missing back-slash, and also that "something" is not a
> maven variable. The expected behavior is to keep it unchanged. Here is a unit
> test that shows the issue:
> 1. First, create a resource text file "new.test" with just the string
> {code}\${something }{code}
> 2. Make sure that resource plugin has filtering set to "true":
> {code}
>
>
> src/test/resources
> true
>
> {code}
> 3. Create the unit test below:
> {code}
> @Test
> public void test() throws IOException {
> URL url = Resources.getResource("conf/new.test");
> String text = Resources.toString(url, Charsets.UTF_8);
> String expectedText = "\\${something }" ;
> System.out.println("actual: " + text);
> System.out.println("expected: " + expectedText);
> assertEquals(expectedText, text);
> }
> {code}
> 3. Note that when you run the above test from the IDE directly, it passes.
> 4. Run `mvn clean install` from command line and verify the following error:
> {code}
> actual: ${something }
> expected: \${something }
> org.junit.ComparisonFailure:
> Expected :\${something }
> Actual :${something } ---> Note the back-slash has gone missing.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6259) Maven Resources Plugin copy error when filtering is true on a Mac
Fahd Siddiqui created MNG-6259:
--
Summary: Maven Resources Plugin copy error when filtering is true
on a Mac
Key: MNG-6259
URL: https://issues.apache.org/jira/browse/MNG-6259
Project: Maven
Issue Type: Bug
Components: Errors
Affects Versions: 3.2.5
Reporter: Fahd Siddiqui
This is an error consistently on Mac (OS X 10.11.6), but it seems to work fine
on linux (our jenkins agent).
Basically, when `filtering` is set to true in the resources plugin, the
resource file contents are copied incorrectly converting \${something} to
${something}. Note the missing back-slash, and also that "something" is not a
maven variable. The expected behavior is to keep it unchanged. Here is a unit
test that shows the issue:
1. First, create a resource text file "new.test" with just the string
{code}\${something }{code}
2. Make sure that resource plugin has filtering set to "true":
{code}
src/test/resources
true
{code}
3. Create the unit test below:
{code}
@Test
public void test() throws IOException {
URL url = Resources.getResource("conf/new.test");
String text = Resources.toString(url, Charsets.UTF_8);
String expectedText = "\\${something }" ;
System.out.println("actual: " + text);
System.out.println("expected: " + expectedText);
assertEquals(expectedText, text);
}
{code}
3. Note that when you run the above test from the IDE directly, it passes.
4. Run `mvn clean install` from command line and verify the following error:
{code}
actual: ${something }
expected: \${something }
org.junit.ComparisonFailure:
Expected :\${something }
Actual :${something }
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6259) Maven Resources Plugin copy error when filtering is true on a Mac
[
https://issues.apache.org/jira/browse/MNG-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fahd Siddiqui updated MNG-6259:
---
Description:
This is an error consistently seen on Mac (OS X 10.11.6), but it seems to work
fine on linux (our jenkins agent).
Basically, when `filtering` is set to true in the resources plugin, the
resource file contents are copied incorrectly converting \${something} to
${something}. Note the missing back-slash, and also that "something" is not a
maven variable. The expected behavior is to keep it unchanged. Here is a unit
test that shows the issue:
1. First, create a resource text file "new.test" with just the string
{code}\${something }{code}
2. Make sure that resource plugin has filtering set to "true":
{code}
src/test/resources
true
{code}
3. Create the unit test below:
{code}
@Test
public void test() throws IOException {
URL url = Resources.getResource("conf/new.test");
String text = Resources.toString(url, Charsets.UTF_8);
String expectedText = "\\${something }" ;
System.out.println("actual: " + text);
System.out.println("expected: " + expectedText);
assertEquals(expectedText, text);
}
{code}
3. Note that when you run the above test from the IDE directly, it passes.
4. Run `mvn clean install` from command line and verify the following error:
{code}
actual: ${something }
expected: \${something }
org.junit.ComparisonFailure:
Expected :\${something }
Actual :${something }
{code}
was:
This is an error consistently on Mac (OS X 10.11.6), but it seems to work fine
on linux (our jenkins agent).
Basically, when `filtering` is set to true in the resources plugin, the
resource file contents are copied incorrectly converting \${something} to
${something}. Note the missing back-slash, and also that "something" is not a
maven variable. The expected behavior is to keep it unchanged. Here is a unit
test that shows the issue:
1. First, create a resource text file "new.test" with just the string
{code}\${something }{code}
2. Make sure that resource plugin has filtering set to "true":
{code}
src/test/resources
true
{code}
3. Create the unit test below:
{code}
@Test
public void test() throws IOException {
URL url = Resources.getResource("conf/new.test");
String text = Resources.toString(url, Charsets.UTF_8);
String expectedText = "\\${something }" ;
System.out.println("actual: " + text);
System.out.println("expected: " + expectedText);
assertEquals(expectedText, text);
}
{code}
3. Note that when you run the above test from the IDE directly, it passes.
4. Run `mvn clean install` from command line and verify the following error:
{code}
actual: ${something }
expected: \${something }
org.junit.ComparisonFailure:
Expected :\${something }
Actual :${something }
{code}
> Maven Resources Plugin copy error when filtering is true on a Mac
> -
>
> Key: MNG-6259
> URL: https://issues.apache.org/jira/browse/MNG-6259
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.2.5
>Reporter: Fahd Siddiqui
>
> This is an error consistently seen on Mac (OS X 10.11.6), but it seems to
> work fine on linux (our jenkins agent).
> Basically, when `filtering` is set to true in the resources plugin, the
> resource file contents are copied incorrectly converting \${something} to
> ${something}. Note the missing back-slash, and also that "something" is not a
> maven variable. The expected behavior is to keep it unchanged. Here is a unit
> test that shows the issue:
> 1. First, create a resource text file "new.test" with just the string
> {code}\${something }{code}
> 2. Make sure that resource plugin has filtering set to "true":
> {code}
>
>
> src/test/resources
> true
>
> {code}
> 3. Create the unit test below:
> {code}
> @Test
> public void test() throws IOException {
> URL url = Resources.getResource("conf/new.test");
> String text = Resources.toString(url, Charsets.UTF_8);
> String expectedText = "\\${something }" ;
> System.out.println("actual: " + text);
> System.out.println("expected: " + expectedText);
> assertEquals(expectedText, text);
> }
> {code}
> 3. Note that when you run the above test from the IDE directly, it passes.
> 4. Run `mvn clean install` from command line and verify the following error:
> {code}
> actual: ${something }
> expected: \${something }
> org.junit.ComparisonFailure:
> Expected :\${something }
> Actual :${something }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-456) Upgrade to Maven3 plugin
[ https://issues.apache.org/jira/browse/MJAVADOC-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084869#comment-16084869 ] Hudson commented on MJAVADOC-456: - FAILURE: Integrated in Jenkins build maven-plugins #9031 (See [https://builds.apache.org/job/maven-plugins/9031/]) [MJAVADOC-456] Upgrade to Maven3 plugin No need to resolve transitive dependencies twice (rfscholte: [http://svn.apache.org/viewvc/?view=rev&rev=1801785]) * (edit) maven-javadoc-plugin/pom.xml * (edit) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java * (edit) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/ResourceResolver.java * (edit) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/SourceResolverConfig.java > Upgrade to Maven3 plugin > > > Key: MJAVADOC-456 > URL: https://issues.apache.org/jira/browse/MJAVADOC-456 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.10.4 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.0 > > > - Upgrade plugin according to > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies > - Remove shading of o.a.m.w.p.ProxyUtils; was done for Maven 2.0.x backwards > compatibility -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJAVADOC-456) Upgrade to Maven3 plugin
[ https://issues.apache.org/jira/browse/MJAVADOC-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084621#comment-16084621 ] Hudson commented on MJAVADOC-456: - FAILURE: Integrated in Jenkins build maven-plugins #9030 (See [https://builds.apache.org/job/maven-plugins/9030/]) [MJAVADOC-456] Upgrade to Maven3 plugin Change package to org.apache.maven.plugins (rfscholte: [http://svn.apache.org/viewvc/?view=rev&rev=1801772]) * (edit) maven-javadoc-plugin/pom.xml * (delete) maven-javadoc-plugin/src/main/java/org/apache/maven/plugin * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractFixJavadocMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AdditionalDependency.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AggregatorJavadocJar.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AggregatorJavadocReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AggregatorTestJavadocJar.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AggregatorTestJavadocReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/FixJavadocMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocArchiveConfiguration.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocJar.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocNoForkReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/JavadocVersion.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/TestFixJavadocMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/TestJavadocJar.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/TestJavadocNoForkReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/TestJavadocReport.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/TestResourcesBundleMojo.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/JavadocBundle.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/ProjectArtifactFilter.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/ResourceResolver.java * (add) maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/resolver/SourceResolverConfig.java * (edit) maven-javadoc-plugin/src/main/mdo/javadocOptions.mdo * (delete) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugin * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/css * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/css/stylesheet.css * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/frame-injection-fix.txt * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.3 * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.4 * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.5 * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.6 * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.7 * (add) maven-javadoc-plugin/src/main/resources/org/apache/maven/plugins/javadoc/java-api-package-list-1.8 * (delete) maven-javadoc-plugin/src/test/java/org/apache/maven/plugin * (add) maven-javadoc-plugin/src/test/java/org/apache/maven/plugins * (add) maven-javadoc-plugin/src/test/java/org/apache/maven/plugins/javadoc * (add) maven-javadoc-plugin/src/test/java/org/apache/maven/plugins/javadoc/AbstractFixJavadocMojoTest.java * (add) maven-javadoc-plugin/src/test/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojoTest.java * (add) mave
[jira] [Created] (MJAVADOC-490) Aggregate goal fails if artifacts not installed
Shannon Carey created MJAVADOC-490:
--
Summary: Aggregate goal fails if artifacts not installed
Key: MJAVADOC-490
URL: https://issues.apache.org/jira/browse/MJAVADOC-490
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 2.10.4
Reporter: Shannon Carey
Using the javadoc aggregate report causes release:perform to fail if the
modules were not already installed into the local repository.
During release:perform's execution of "deploy site-deploy", when
report:aggregate runs it appears to fork executions on all of the reactor
modules ("Forking mymodule 0.0.1"). When it gets to a module which has a
dependency on another module, it cannot find it locally (since that module has
not yet been installed), tries to download it from Nexus, and ultimately fails
with "... Could not resolve dependencies for project ... The following
artifacts could not be resolved ..."
The only way I can think of to fix this is to add "install" to the
"preparationGoals" of release:prepare so that the modules are already installed
before release:perform is run. However, this violates the self-containment of
release:perform's deploy build, and is generally confusing and difficult to
diagnose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6226) mvn dependency:get error - Premature end of Content-Length delimited message body (expected: 56473600; received: 6843
[
https://issues.apache.org/jira/browse/MNG-6226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084377#comment-16084377
]
Michael Osipov commented on MNG-6226:
-
Provide a full dump with {{curl --verbose $URL}} of the target in question.
This seems to be an issue with your internal setup.
> mvn dependency:get error - Premature end of Content-Length delimited message
> body (expected: 56473600; received: 6843
> -
>
> Key: MNG-6226
> URL: https://issues.apache.org/jira/browse/MNG-6226
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.5.0
>Reporter: Sahil Amar
>Priority: Blocker
> Labels: maven
>
> Hi Team,
> I am trying to use the maven dependency get plugin to get the artifact which
> is a tar file from our central repo.
> Here is the command:
> {code:xml}
> mvn dependency:get -DgroupId=com.sample -DartifactId=sample-project
> -Dversion=1.0.1-SNAPSHOT -Dtransitive=false -Dpackaging=tar
> {code}
> It gives me the below error:
> {code:xml}
> [ERROR] : Premature end of Content-Length delimited message body (expected:
> 56473600; received: 6843
> [ERROR] -> [Help 1]
> {code}
> And also when I try it with the debug(-X) mode, this is the error I get:
> {code:xml}
> Caused by:
> org.apache.maven.wagon.providers.http.httpclient.ConnectionClosedException:
> Premature end of Content-Length delimited message body (expected: 56473600;
> received: 6835
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:180)
> at
> org.apache.maven.wagon.providers.http.httpclient.conn.EofSensorInputStream.read(EofSensorInputStream.java:137)
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:572)
> at
> org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:372)
> ... 43 more
> {code}
> The above command when I try on windows it works. But issue is when I run it
> on UNIX.
> But when I try to get the jar using the below command(with -Dpackaging=jar)
> on both Linux and windows, it works:
> {code:xml}
> mvn dependency:get -DgroupId=com.sample -DartifactId=sample-project
> -Dversion=1.0.1-SNAPSHOT -Dtransitive=false -Dpackaging=jar
> {code}
> Also the same works for a war.
> Please help.
> Thanks and Regards,
> Sahil Amar
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6258) Upgrade to Maven Resolver 1.1.0
Michael Osipov created MNG-6258: --- Summary: Upgrade to Maven Resolver 1.1.0 Key: MNG-6258 URL: https://issues.apache.org/jira/browse/MNG-6258 Project: Maven Issue Type: Task Components: Dependencies, Deployment Affects Versions: 3.5.0 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.5.1-candidate -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6221) Maven cannot build with Java 1.8.0_131
[ https://issues.apache.org/jira/browse/MNG-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6221. --- Resolution: Invalid Two months w/o a sample project. > Maven cannot build with Java 1.8.0_131 > -- > > Key: MNG-6221 > URL: https://issues.apache.org/jira/browse/MNG-6221 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.3.9, 3.5.0 >Reporter: Erich Steiger >Priority: Blocker > > After upgrading from Oracle Java 1.8.0_102 to Oracle Java 1.8.0_131, it is > not possible to build anymore with maven. Tested with maven 3.3.9 and 3.5.0. > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building com.example 0.0.1-SNAPSHOT > [INFO] > > [WARNING] Error injecting: org.apache.maven.wagon.providers.http.HttpWagon > java.lang.NoClassDefFoundError: Could not initialize class > sun.security.ssl.SSLContextImpl$DefaultSSLContext > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at java.security.Provider$Service.getImplClass(Provider.java:1634) > at java.security.Provider$Service.newInstance(Provider.java:1592) > at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) > at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) > at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96) > ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6255:
Comment: was deleted
(was: Why not set this in {{.gitattributes}}?)
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084339#comment-16084339
]
Michael Osipov commented on MNG-6255:
-
Surprisingly what will happen when this file is read from the command script
and having {{LF}} only.
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084337#comment-16084337
]
Michael Osipov commented on MNG-6255:
-
Why not set this in {{.gitattributes}}?
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MDEP-576) maven-dependency-plugin ignores class of object passed as a parameter to method references
[
https://issues.apache.org/jira/browse/MDEP-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Dergachev updated MDEP-576:
Description:
Hi there, i created a project on
[github|https://github.com/vdergachev/dependency-plugin-vs-java-lambda] that
can help you to reproduce the issue. Just clone it and make {code}mvn clean
install{code}
In my case plugin ignored Server class from jetty-server.jar and a as result i
got message {code}Unused declared dependencies found{code}
was:
Hi there, i created a project on
[github|https://github.com/vdergachev/dependency-plugin-vs-java-lambda] that
can help you to reproduce the issue. Just clone it and make
{code:java}
mvn clean install
{code}
> maven-dependency-plugin ignores class of object passed as a parameter to
> method references
> --
>
> Key: MDEP-576
> URL: https://issues.apache.org/jira/browse/MDEP-576
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> Hi there, i created a project on
> [github|https://github.com/vdergachev/dependency-plugin-vs-java-lambda] that
> can help you to reproduce the issue. Just clone it and make {code}mvn clean
> install{code}
> In my case plugin ignored Server class from jetty-server.jar and a as result
> i got message {code}Unused declared dependencies found{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MDEP-576) maven-dependency-plugin ignores class of object passed as a parameter to method references
Vladimir Dergachev created MDEP-576:
---
Summary: maven-dependency-plugin ignores class of object passed as
a parameter to method references
Key: MDEP-576
URL: https://issues.apache.org/jira/browse/MDEP-576
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Vladimir Dergachev
Priority: Minor
Hi there, i created a project on
[github|https://github.com/vdergachev/dependency-plugin-vs-java-lambda] that
can help you to reproduce the issue. Just clone it and make
{code:java}
mvn clean install
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MRRESOURCES-102) Filtering of non-.vm files
[ https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Falko Modler updated MRRESOURCES-102: - Description: It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (fixing this would require some other plugin) was: It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (which would require some other plugin) > Filtering of non-.vm files > -- > > Key: MRRESOURCES-102 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-102 > Project: Maven Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.5 >Reporter: Falko Modler > > It would be a very welcomed addition if the plugin would also filter > non-verlocity (.vm) files. > See also: MRRESOURCES-83 > Renaming the files in question to *.vm is not an option for me because: > - MRRESOURCES-94 > - the module _providing_ the file(s) also needs them _without_ .vm suffix > (fixing this would require some other plugin) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6257) explicitly enable http proxies
Noel Grandin created MNG-6257: - Summary: explicitly enable http proxies Key: MNG-6257 URL: https://issues.apache.org/jira/browse/MNG-6257 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.5.0 Environment: All Reporter: Noel Grandin when using maven from behind a proxy, it cannot connect to download The maven/java stuff will not use the system proxies unless explicitly told to do so, which is a problem when maven tries to download the jars it needs :-) Basically, I need the following option added to the java command line: -Djava.net.useSystemProxies=true Sun did not see to make this the default because of backwards compatibility, which is a right PITA, but anyhow :-) Please also see original issue here: https://github.com/takari/maven-wrapper/issues/58 https://github.com/pmd/pmd/issues/498 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: (was: cmd_mvn_insall_X.jpg) > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20:verify classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Summary: maven-failsafe-plugin:2.20:verify classNotFound (spring autowired service) testNg (was: maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg) > maven-failsafe-plugin:2.20:verify classNotFound (spring autowired service) > testNg > - > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-45-33_517-jvmRun1.dump, > cmd_mvn_install_X.txt, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: cmd_mvn_install_X.txt 2017-07-12T09-45-33_517-jvmRun1.dump failsafe-summary.xml > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-45-33_517-jvmRun1.dump, > cmd_mvn_install_X.txt, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: (was: cmd_mvn_insall_X.jpg) > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-42-09_878-jvmRun1.dump, > cmd_mvn_insall_X.jpg, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: (was: 2017-07-12T09-42-09_878-jvmRun1.dump) > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: (was: failsafe-summary.xml) > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: (was: cmd_mvn_insall_X.PNG) > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-42-09_878-jvmRun1.dump, > cmd_mvn_insall_X.jpg, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6256) Maven script can break if "-f" path contains special characters
Christoph Etzel created MNG-6256:
Summary: Maven script can break if "-f" path contains special
characters
Key: MNG-6256
URL: https://issues.apache.org/jira/browse/MNG-6256
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.5.0
Environment: Windows 10 with PowerShell
Reporter: Christoph Etzel
Executing maven on Windows using the {{-f}} or {{--file}} parameter to specify
an alternate POM file can break the script if the path contains special
characters.
It was originally discovered on a Windows Jenkins instance with working
directory located under C:\Program Files (x86)\Jenkins..
Example:
{code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
nicht verarbeitet werden.}}
Just for fun: Starting calc from maven script using {{-f}}
{code:java}mvn -f " ' & start calc"{code}
Command line output: {{POM file '}} and a new calculator process
The bug was introduced with commit
https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
for issue MNG-5889.
Workaround: Use maven 3.3.9 or below
Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
commands in {{maven.cmd}} (line 120 and 129).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6256) Maven script can break if "-f" path contains special characters
[
https://issues.apache.org/jira/browse/MNG-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Etzel updated MNG-6256:
-
Description:
Executing maven on Windows using the {{\-f}} or {{--file}} parameter to specify
an alternate POM file can break the script if the path contains special
characters.
It was originally discovered on a Windows Jenkins instance with working
directory located under C:\Program Files (x86)\Jenkins..
Example:
{code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
nicht verarbeitet werden.}}
Just for fun: Starting calc from maven script using {{\-f}}
{code:java}mvn -f " ' & start calc"{code}
Command line output: {{POM file '}} and a new calculator process
The bug was introduced with commit
https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
for issue MNG-5889.
Workaround: Use maven 3.3.9 or below
Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
commands in {{maven.cmd}} (line 120 and 129).
was:
Executing maven on Windows using the {{-f}} or {{--file}} parameter to specify
an alternate POM file can break the script if the path contains special
characters.
It was originally discovered on a Windows Jenkins instance with working
directory located under C:\Program Files (x86)\Jenkins..
Example:
{code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
nicht verarbeitet werden.}}
Just for fun: Starting calc from maven script using {{-f}}
{code:java}mvn -f " ' & start calc"{code}
Command line output: {{POM file '}} and a new calculator process
The bug was introduced with commit
https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
for issue MNG-5889.
Workaround: Use maven 3.3.9 or below
Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
commands in {{maven.cmd}} (line 120 and 129).
> Maven script can break if "-f" path contains special characters
>
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to
> specify an alternate POM file can break the script if the path contains
> special characters.
> It was originally discovered on a Windows Jenkins instance with working
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file '}} and a new calculator process
> The bug was introduced with commit
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
> for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
> commands in {{maven.cmd}} (line 120 and 129).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: cmd_mvn_insall_X.jpg > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-42-09_878-jvmRun1.dump, > cmd_mvn_insall_X.jpg, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
Michael Hodnett created SUREFIRE-1390: - Summary: maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg Key: SUREFIRE-1390 URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, TestNG support Affects Versions: 2.20, 2.19.1, 2.19 Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, 1.5.4] Reporter: Michael Hodnett Fix For: 2.18.1 Attachments: 2017-07-12T09-42-09_878-jvmRun1.dump, cmd_mvn_insall_X.PNG, failsafe-summary.xml Apologies in advance if duplicate or needs to be in Failsafe specific project, am new to jira, tried searching, but couldn't find match. Not sure if bug in plugin, but couldn't find anything on google/SO based on failsafe stacktrace. Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during integration test run of spring-based testNg tests. However, remaining on current failsafe version, 2.18.1, works as expected. See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1390) maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hodnett updated SUREFIRE-1390: -- Attachment: cmd_mvn_insall_X.jpg > maven-failsafe-plugin:2.20 classNotFound (spring autowired service) testNg > -- > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: Michael Hodnett > Labels: build, test > Fix For: 2.18.1 > > Attachments: 2017-07-12T09-42-09_878-jvmRun1.dump, > cmd_mvn_insall_X.jpg, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNGSITE-312) "Using Your Own Manifest File" link is broken
Linmao Song created MNGSITE-312: --- Summary: "Using Your Own Manifest File" link is broken Key: MNGSITE-312 URL: https://issues.apache.org/jira/browse/MNGSITE-312 Project: Maven Project Web Site Issue Type: Bug Reporter: Linmao Song The link to "Using Your Own Manifest File" from page https://maven.apache.org/plugins/maven-jar-plugin/index.html appears broken. The link's URL is https://maven.apache.org/plugins/maven-jar-plugin/shared/maven-archiver/examples/manifestFile.html . Currently it redirects to "Not Found". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1340) add a kind of progress status to surefire output
[
https://issues.apache.org/jira/browse/SUREFIRE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1340:
---
Fix Version/s: Backlog
> add a kind of progress status to surefire output
>
>
> Key: SUREFIRE-1340
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1340
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> ATM surefire executes tests but for big suites no way to know where we are in
> the execution exactly. What about adding a kind of line prefix showing it:
> {code}
> [124/1254] normal output
> [124/1254] another normal output
> [126/1254] another normal output after 2 tests finished
> ...
> {code}
> This would at least allow to know where we are. Idea would be to have a
> counter in the "executor" and just show it when there is something on
> stdout/stderr.
> Of course it will require a new configuration flag to activate it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SUREFIRE-1340) add a kind of progress status to surefire output
[
https://issues.apache.org/jira/browse/SUREFIRE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1340:
--
Assignee: Tibor Digana
> add a kind of progress status to surefire output
>
>
> Key: SUREFIRE-1340
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1340
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> ATM surefire executes tests but for big suites no way to know where we are in
> the execution exactly. What about adding a kind of line prefix showing it:
> {code}
> [124/1254] normal output
> [124/1254] another normal output
> [126/1254] another normal output after 2 tests finished
> ...
> {code}
> This would at least allow to know where we are. Idea would be to have a
> counter in the "executor" and just show it when there is something on
> stdout/stderr.
> Of course it will require a new configuration flag to activate it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MRRESOURCES-102) Filtering of non-.vm files
Falko Modler created MRRESOURCES-102: Summary: Filtering of non-.vm files Key: MRRESOURCES-102 URL: https://issues.apache.org/jira/browse/MRRESOURCES-102 Project: Maven Remote Resources Plugin Issue Type: New Feature Affects Versions: 1.5 Reporter: Falko Modler It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (which would require some other plugin) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
