[jira] [Commented] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422305#comment-15422305
]
Michael Osipov commented on MNG-6080:
-
{{compile}}? You probably mean {{provided}}. This won't end up in the output.
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422287#comment-15422287
]
Michael Osipov commented on WAGON-461:
--
Thanks for the input. 409:
{quote}
The request could not be completed due to a conflict with the current state of
the target resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request.
{quote}
This error does not seem to relate to the URI but to another issue. Can you
also provide a full debug log?
As far ar I know, the client must create the collection {{.../IBM}} first
before perform the {{PUT}} operation. Can you create provide a minimal project
with does this DAV upload? I will retry with the Apache DAV module.
Additionally, do the collections upto IBM exist on the server already?
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1269) FileNotFoundException by SureFire after execution of tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Mahapatro updated SUREFIRE-1269: --- Attachment: screenshot-1.png > FileNotFoundException by SureFire after execution of tests > -- > > Key: SUREFIRE-1269 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1269 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, TestNG support >Affects Versions: 2.19.1 > Environment: OS: Win10 > Java: 8 rev.102 > Maven: 3.3.9 > TestNG: 6.9.10 > SureFire: 2.19.1 > SystemMemory: 16G >Reporter: Deepak Mahapatro >Priority: Minor > Attachments: Test.zip, screenshot-1.png > > > After executing tests, maven is throwing a FienotFoundException which > originates from surefire (I understood the source from trace.). > java.io.FileNotFoundException: \Users\cedric\java\misc\jquery\head (The > system cannot find the path specified) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.(FileInputStream.java:138) > at org.testng.reporters.Files.readFile(Files.java:21) > at org.testng.reporters.JqReporter.generateReport(JqReporter.java:40) > at org.testng.TestNG.generateReports(TestNG.java:1135) > at org.testng.TestNG.run(TestNG.java:1081) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:281) > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:121) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > This is not impacting either test result or build status but it is creating > some confusion while analyzing logs from both file system and from maven > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1269) FileNotFoundException by SureFire after execution of tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Mahapatro updated SUREFIRE-1269: --- Attachment: Test.zip > FileNotFoundException by SureFire after execution of tests > -- > > Key: SUREFIRE-1269 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1269 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, TestNG support >Affects Versions: 2.19.1 > Environment: OS: Win10 > Java: 8 rev.102 > Maven: 3.3.9 > TestNG: 6.9.10 > SureFire: 2.19.1 > SystemMemory: 16G >Reporter: Deepak Mahapatro >Priority: Minor > Attachments: Test.zip > > > After executing tests, maven is throwing a FienotFoundException which > originates from surefire (I understood the source from trace.). > java.io.FileNotFoundException: \Users\cedric\java\misc\jquery\head (The > system cannot find the path specified) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.(FileInputStream.java:138) > at org.testng.reporters.Files.readFile(Files.java:21) > at org.testng.reporters.JqReporter.generateReport(JqReporter.java:40) > at org.testng.TestNG.generateReports(TestNG.java:1135) > at org.testng.TestNG.run(TestNG.java:1081) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:281) > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:121) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > This is not impacting either test result or build status but it is creating > some confusion while analyzing logs from both file system and from maven > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SUREFIRE-1269) FileNotFoundException by SureFire after execution of tests
Deepak Mahapatro created SUREFIRE-1269: -- Summary: FileNotFoundException by SureFire after execution of tests Key: SUREFIRE-1269 URL: https://issues.apache.org/jira/browse/SUREFIRE-1269 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin, TestNG support Affects Versions: 2.19.1 Environment: OS: Win10 Java: 8 rev.102 Maven: 3.3.9 TestNG: 6.9.10 SureFire: 2.19.1 SystemMemory: 16G Reporter: Deepak Mahapatro Priority: Minor After executing tests, maven is throwing a FienotFoundException which originates from surefire (I understood the source from trace.). java.io.FileNotFoundException: \Users\cedric\java\misc\jquery\head (The system cannot find the path specified) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.(FileInputStream.java:138) at org.testng.reporters.Files.readFile(Files.java:21) at org.testng.reporters.JqReporter.generateReport(JqReporter.java:40) at org.testng.TestNG.generateReports(TestNG.java:1135) at org.testng.TestNG.run(TestNG.java:1081) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:281) at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:121) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) This is not impacting either test result or build status but it is creating some confusion while analyzing logs from both file system and from maven console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421772#comment-15421772
]
Mike Summers commented on WAGON-461:
Right, I tried that originally however pre-encoding the URI in the pom doesn't
help as the URI is finally encoded farther down the code chain which then
encodes the encoding.
pom.xml
{code:xml}
dav:https://snafu.sharefile-webdav.com/Shared%20Folders/Fit%20-%20Expert%20Services/IBM
{code}
Stack trace:
{code:java}
[ERROR] Failed to execute goal
org.codehaus.mojo:wagon-maven-plugin:1.0:upload-single (upload-assembly) on
project synthetics-monitor-plugin: Error handling resource: Failed to transfer
file:
https://snafu.sharefile-webdav.com/Shared%2520Folders/Fit%2520-%2520Expert%2520Services/IBM/synthetics-monitor-plugin-1.0.0.jar.
Return code is: 409 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.codehaus.mojo:wagon-maven-plugin:1.0:upload-single (upload-assembly) on
project synthetics-monitor-plugin: Error handling resource
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error handling
resource
at
org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute(AbstractSingleWagonMojo.java:68)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
{code}
{color:red}
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer
file:
https://snafu.sharefile-webdav.com/Shared%2520Folders/Fit%2520-%2520Expert%2520Services/IBM/synthetics-monitor-plugin-1.0.0.jar.
Return code is: 409
{color}
{code:java}
at
org.apache.maven.wagon.providers.webdav.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:417)
at
org.apache.maven.wagon.providers.webdav.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:324)
at
org.apache.maven.wagon.providers.webdav.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:301)
at
org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:326)
at
org.codehaus.mojo.wagon.UploadSingleMojo.execute(UploadSingleMojo.java:70)
at
org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute(AbstractSingleWagonMojo.java:64)
... 22 more
{code}
wagon-ftp working on the unencoded pom URI is also an indication that
pre-encoding the URI in the pom is probably not the right direction. I would
think that both wagon-ftp and wagon-webdav would have the same interface
contract with the plugin, but perhaps not.
Also, pre-encoding the URI doesn't make a lot of sense given that adding the
encoding call to WebDavWagon does work.
If you have an alternate URI encoding you're thinking of please forward it and
I'll give it a try.
Thanks.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.ap
[jira] [Comment Edited] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421645#comment-15421645
]
Mike Summers edited comment on WAGON-461 at 8/15/16 9:42 PM:
-
I apologize, I misunderstood your earlier question.
The webdav string comes from a pom:
{code:xml}
org.codehaus.mojo
wagon-maven-plugin
1.0
upload-assembly
install
upload-single
sharefile-ftp
${project.build.directory}/${project.build.finalName}.jar
dav:https://snafu.sharefile-webdav.com/Shared
Folders/Fit - Expert Services/IBM
{code}
It _is_ a valid webdav URI, it is simply not encoded properly by wagon-webdav.
Adding the one line of code to encode the URI fixes the problem. Hand encoding
the URI in the POM does not fix the problem.
Using wagon-ftp rather than wagon-webdav also works
{code:xml}
ftp://snafu.sharefileftp.com/FIT - Expert Services/IBM/
{code}
which seems to indicate the the encoding is not a plugin function.
_Is_ it the plugins job to encode the URI?
was (Author: msummers):
We seem to be having a communication problem.
The webdav string comes from a pom:
{code:xml}
org.codehaus.mojo
wagon-maven-plugin
1.0
upload-assembly
install
upload-single
sharefile-ftp
${project.build.directory}/${project.build.finalName}.jar
dav:https://snafu.sharefile-webdav.com/Shared
Folders/Fit - Expert Services/IBM
{code}
It _is_ a valid webdav URI, it is simply not encoded properly by wagon-webdav.
Adding the one line of code to encode the URI fixes the problem. Hand encoding
the URI in the POM does not fix the problem.
Using wagon-ftp rather than wagon-webdav also works
{code:xml}
ftp://snafu.sharefileftp.com/FIT - Expert Services/IBM/
{code}
which seems to indicate the the encoding is not a plugin function.
_Is_ it the plugins job to encode the URI?
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421716#comment-15421716
]
Michael Osipov commented on WAGON-461:
--
This is actually what I wanted to see. The URI ist not valid, see
[here|http://stackoverflow.com/a/497972/696632] for a citation of the
appropriate RFC.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421659#comment-15421659
]
Paul Benedict commented on MNG-6080:
Michael, you are right that ZIP files are treated as first-class citizens on
the classpath. Just for the sake of quoting something official to backup your
point, here's a good line from Java documentation: ["Class path entries that
are neither directories nor archives (.zip or JAR files) nor the asterisk (*)
wildcard character are
ignored."|https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html]
Regarding your first question, I am only proposing one scope. The two names are
just potential choices ... with some philosophical waxing by me on the
meanings/suggestions/implications behind the words. I hope that whatever name
is chosen, it best captures the purpose of the scope.
Regarding your second question, the new scope should act like "compile" except
it has no classpath entry. Plugins should not attempt to add it to any language
execution environment.
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421645#comment-15421645
]
Mike Summers edited comment on WAGON-461 at 8/15/16 8:47 PM:
-
We seem to be having a communication problem.
The webdav string comes from a pom:
{code:xml}
org.codehaus.mojo
wagon-maven-plugin
1.0
upload-assembly
install
upload-single
sharefile-ftp
${project.build.directory}/${project.build.finalName}.jar
dav:https://snafu.sharefile-webdav.com/Shared
Folders/Fit - Expert Services/IBM
{code}
It _is_ a valid webdav URI, it is simply not encoded properly by wagon-webdav.
Adding the one line of code to encode the URI fixes the problem. Hand encoding
the URI in the POM does not fix the problem.
Using wagon-ftp rather than wagon-webdav also works
{code:xml}
ftp://snafu.sharefileftp.com/FIT - Expert Services/IBM/
{code}
which seems to indicate the the encoding is not a plugin function.
_Is_ it the plugins job to encode the URI?
was (Author: msummers):
We seem to be having a communication problem.
The webdav string comes from a pom:
{code:xml}
org.codehaus.mojo
wagon-maven-plugin
1.0
upload-assembly
install
upload-single
sharefile-ftp
${project.build.directory}/${project.build.finalName}.jar
dav:https://snafu.sharefile-webdav.com/Shared
Folders/Fit - Expert Services/IBM
{code}
It _is_ a valid webdav URI, it is simply not encoded properly by wagon-webdav.
Adding the one line of code to encode the URI fixes the problem. Hand encoding
the URI in the POM does not fix the problem.
Using wagon-ftp rather than wagon-webdav also works
{code:xml}
ftp://snafu.sharefileftp.com/FIT - Expert Services/IBM/
{code}
which seems to indicate the the encoding is not a plugin function.
_Is_ it the plugins job to encode the URI?
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421645#comment-15421645
]
Mike Summers commented on WAGON-461:
We seem to be having a communication problem.
The webdav string comes from a pom:
{code:xml}
org.codehaus.mojo
wagon-maven-plugin
1.0
upload-assembly
install
upload-single
sharefile-ftp
${project.build.directory}/${project.build.finalName}.jar
dav:https://snafu.sharefile-webdav.com/Shared
Folders/Fit - Expert Services/IBM
{code}
It _is_ a valid webdav URI, it is simply not encoded properly by wagon-webdav.
Adding the one line of code to encode the URI fixes the problem. Hand encoding
the URI in the POM does not fix the problem.
Using wagon-ftp rather than wagon-webdav also works
{code:xml}
ftp://snafu.sharefileftp.com/FIT - Expert Services/IBM/
{code}
which seems to indicate the the encoding is not a plugin function.
_Is_ it the plugins job to encode the URI?
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421619#comment-15421619
]
Michael Osipov commented on WAGON-461:
--
I have no idead what Sharefile but I am trying to figure out *who* is actually
providing this faulty URI. What makes you think that this is a valid URI?
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421586#comment-15421586
]
Michael Osipov commented on MNG-6080:
-
It should also be mentioned that ZIP files are treated as first-class citizens
by {{java(1)}}. In your case, any decent web framework offers to serve static
files from classpath (Spring does) or the Servlet 3.0 spec provides
auto-deployment of static files from {{/META-INF/resources}} in a JAR file,
removing the need to unpack them to the WAR file at all.
Can you elaborate on the difference between both proposed scopes? What impact
would they have actually in the reactor, dependency consumption and (test)
classpath composition?
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421542#comment-15421542
]
Mike Summers commented on WAGON-461:
It's from Sharefile and it is a valid Sharefile webdav URI. Adding the
encodeURLToString results in a successful file transfer into the target
Sharefile folder. I can send you a Pull request with my working change if you
like.
Putting debug statements into WebDavWagon shows that the problem is the code is
not URL encoding the spaces which then causes HttpMethodBase to blow-up.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated MNG-6080:
---
Summary: New scope for non-functional dependencies (was: New scope for
non-functional resources)
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6080) New scope for non-functional resources
Paul Benedict created MNG-6080:
--
Summary: New scope for non-functional resources
Key: MNG-6080
URL: https://issues.apache.org/jira/browse/MNG-6080
Project: Maven
Issue Type: New Feature
Components: Dependencies
Affects Versions: 3.3.9
Reporter: Paul Benedict
Assignee: Paul Benedict
Priority: Critical
Maven currently lacks a scope for artifacts that should not be part of the
classpath. The classpath is the path that the Java Runtime Environment (JRE)
searches for classes and other resource files. Given that the classpath is Java
specific, this feature request can be generalized to accommodate artifacts that
are not code related (directly or indirectly). It is neither code that executes
(like a .class file = "directly") nor a resource file intimately linked to
executable code (like a .properties file = "indirectly").
For example, an organization may with to establish a Maven project that
contains common look-and-feel elements to brand all their web applications.
This project could be a ZIP archive to be included in downstream projects, in
which each build explodes the archive into their respective web application
context roots.
Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
They are nearly equal but have a different slight emphasis. The {{"asset"}}
name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes purpose
within the build. The Maven Team should decide among these two or propose a
third.
Thread where discussion originated:
http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421495#comment-15421495
]
Michael Osipov commented on WAGON-461:
--
Where does the URI come from, especially the path ({{/Shared Folders/Fit -
Expert Services/IBM}})? It pretty much looks like invalid input from the POM.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-294) 'report' mojo should use 'extractors' configuration parameter
[ https://issues.apache.org/jira/browse/MPLUGIN-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421379#comment-15421379 ] Robert Scholte commented on MPLUGIN-294: I think this on is superseded by MPLUGIN-310, i.e it uses the plugin.xml for the report as would Maven do to get the pluginDescriptors. In other words: they use the same file to get there information. > 'report' mojo should use 'extractors' configuration parameter > - > > Key: MPLUGIN-294 > URL: https://issues.apache.org/jira/browse/MPLUGIN-294 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.4 >Reporter: Grzegorz Slowikowski >Priority: Trivial > > "extractors" configuration parameter should be used by "report" mojo the same > way it's used by "descriptor" and "helpmojo" mojos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHARED-577) Remove usage of M2_HOME environment variable
[ https://issues.apache.org/jira/browse/MSHARED-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421311#comment-15421311 ] Michael Osipov commented on MSHARED-577: Makes sense. Did you check already for relevant spots? > Remove usage of M2_HOME environment variable > > > Key: MSHARED-577 > URL: https://issues.apache.org/jira/browse/MSHARED-577 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-invoker >Reporter: Michael Simacek > > Maven 3.4.0 drops usage of M2_HOME variable in the launcher mvn script > [MNG-5607]. Invoker should drop the usage as well to be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6024) maven-antrun-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[ https://issues.apache.org/jira/browse/MNG-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421136#comment-15421136 ] Michael Osipov commented on MNG-6024: - Am I still waiting for your example. > maven-antrun-plugin:instrument failing NoClassDefFoundError: > org/slf4j/LoggerFactory > > > Key: MNG-6024 > URL: https://issues.apache.org/jira/browse/MNG-6024 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Window 7, JDK 1.8.0_40 >Reporter: S V Mohana Rao >Priority: Blocker > Attachments: mvn-coreslf4j-issue.txt > > > Related issues : MNG-5783, MNG-5817. I was using maven-antrun-plugin added > dependency cobertura which requires slf4j-api dependent jar. Even i tried > using 3.4.0-SNAPSHOT version but problem persists. As i was observed it's > been excluded from the child dependent artifacts of cobertura cause it's part > maven core. But it's not referring from maven core which hasn't been added > class path. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPLUGIN-292) HelpMojo contains malformed HTML which causes javadoc to fail under JDK 8
[
https://issues.apache.org/jira/browse/MPLUGIN-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421114#comment-15421114
]
Hudson commented on MPLUGIN-292:
SUCCESS: Integrated in Jenkins build maven-plugin-tools #266 (See
[https://builds.apache.org/job/maven-plugin-tools/266/])
[MPLUGIN-292] HelpMojo contains malformed HTML which causes javadoc to fail
under JDK 8
Apply proper html escaping (rfscholte:
[http://svn.apache.org/viewvc/?view=rev&rev=1756391])
* (edit) maven-plugin-tools-generators/src/main/resources/help-class-source.vm
> HelpMojo contains malformed HTML which causes javadoc to fail under JDK 8
> -
>
> Key: MPLUGIN-292
> URL: https://issues.apache.org/jira/browse/MPLUGIN-292
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: S L
>Assignee: Robert Scholte
> Fix For: 3.5
>
>
> Hi,
> the generated Help-Mojo Class contains malformed HTML which causes the
> generation of javadoc to fail under JDK 8. This is not reproducible with
> older Java versions (I suspect that oracle has deployed some more strict
> validation here).
> error output is:
> {quote}
> /fooBar/target/generated-sources/plugin/com/example/helpmojo/HelpMojo.java:311:
> error: malformed HTML
> * @throws NegativeArraySizeException if repeat < 0
> ^
> /fooBar/target/generated-sources/plugin/com/example/helpmojo/HelpMojo.java:350:
> error: malformed HTML
> * @throws NegativeArraySizeException if indent < 0
> ^
> Command line was: /usr/lib/jvm/java-8-oracle/jre/../bin/javadoc @options
> @packages
> []
> {quote}
> using the following configuration:
> {quote}
>
> org.apache.maven.plugins
> maven-plugin-plugin
> 3.4
>
>
>
> org.apache.maven.plugin-tools
>
> maven-plugin-tools-ant
> 3.4
>
>
>
>
> default-descriptor
>
> descriptor
>
> process-classes
>
>
> generated-helpmojo
>
> helpmojo
>
>
>
> myPrefix
>
> com.example.helpmojo
>
>
>
>
> {quote}
> and the following java / maven versions:
> {quote}
> $ java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> $ mvn --version
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T22:58:10+02:00)
> Maven home: /usr/share/maven-3.2.3
> Java version: 1.8.0_60, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-33-generic", arch: "amd64", family: "unix"
> {quote}
> If a demo project for this is required let me know.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPLUGIN-160) PluginDescriptorGenerator doesn't generate component requirements for MojoDescriptor.getRequirements()
[
https://issues.apache.org/jira/browse/MPLUGIN-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPLUGIN-160.
--
Resolution: Won't Fix
Assignee: Robert Scholte
{{@Parameter}} with a component expression is deprecated. Use {{@Component}}
instead. Based on the timeline this is not a real issue anymore.
> PluginDescriptorGenerator doesn't generate component requirements for
> MojoDescriptor.getRequirements()
> --
>
> Key: MPLUGIN-160
> URL: https://issues.apache.org/jira/browse/MPLUGIN-160
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: API
>Affects Versions: 2.5
>Reporter: Stefan Grinsted
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: patch.txt
>
>
> The part that generates the section for a mojo in
> PluginDescriptorGenerator, only includes requirements for components, if they
> are specified via a parameter with expression=$\{component.*}, not if it is
> actually specified as a required component using the element.
> I have created a patch, which includes the ComponentRequirements as
> requirements when generating the element.
> Until released, the following workaround can be used in the module.mojos.xml,
> to get the required component in the plugin.xml:
> {code:xml}
> workaroundForPathTransformer
> true
>
> ${component.org.apache.maven.project.path.PathTranslator}
> org.apache.maven.project.path.PathTranslator
> This is a workaround to get the PathTransformer as a
> Requirement in the plugin.xml.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPLUGIN-292) HelpMojo contains malformed HTML which causes javadoc to fail under JDK 8
[
https://issues.apache.org/jira/browse/MPLUGIN-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPLUGIN-292.
--
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.5
Fixed in [r1756391|http://svn.apache.org/viewvc?rev=1756391&view=rev]
> HelpMojo contains malformed HTML which causes javadoc to fail under JDK 8
> -
>
> Key: MPLUGIN-292
> URL: https://issues.apache.org/jira/browse/MPLUGIN-292
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: S L
>Assignee: Robert Scholte
> Fix For: 3.5
>
>
> Hi,
> the generated Help-Mojo Class contains malformed HTML which causes the
> generation of javadoc to fail under JDK 8. This is not reproducible with
> older Java versions (I suspect that oracle has deployed some more strict
> validation here).
> error output is:
> {quote}
> /fooBar/target/generated-sources/plugin/com/example/helpmojo/HelpMojo.java:311:
> error: malformed HTML
> * @throws NegativeArraySizeException if repeat < 0
> ^
> /fooBar/target/generated-sources/plugin/com/example/helpmojo/HelpMojo.java:350:
> error: malformed HTML
> * @throws NegativeArraySizeException if indent < 0
> ^
> Command line was: /usr/lib/jvm/java-8-oracle/jre/../bin/javadoc @options
> @packages
> []
> {quote}
> using the following configuration:
> {quote}
>
> org.apache.maven.plugins
> maven-plugin-plugin
> 3.4
>
>
>
> org.apache.maven.plugin-tools
>
> maven-plugin-tools-ant
> 3.4
>
>
>
>
> default-descriptor
>
> descriptor
>
> process-classes
>
>
> generated-helpmojo
>
> helpmojo
>
>
>
> myPrefix
>
> com.example.helpmojo
>
>
>
>
> {quote}
> and the following java / maven versions:
> {quote}
> $ java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> $ mvn --version
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T22:58:10+02:00)
> Maven home: /usr/share/maven-3.2.3
> Java version: 1.8.0_60, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-oracle/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-33-generic", arch: "amd64", family: "unix"
> {quote}
> If a demo project for this is required let me know.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MVERIFIER-23) maven-failsafe-plugin IntegrationTestMojo @Override
Martin Gainty created MVERIFIER-23:
--
Summary: maven-failsafe-plugin IntegrationTestMojo @Override
Key: MVERIFIER-23
URL: https://issues.apache.org/jira/browse/MVERIFIER-23
Project: Maven Verifier Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Environment: JDK 1.8
Maven-3.2.5
Reporter: Martin Gainty
Priority: Minor
maven-failsafe-plugin-2.19.2-SNAPSHOT
org.apache.maven.plugin.failsafe.IntegrationTestMojo.java contains superfluous
@Override
//@Override /* getReportSchemaLocation not exist in base class */
protected String getReportSchemaLocation()
{
return
"https://maven.apache.org/surefire/maven-failsafe-plugin/xsd/failsafe-test-report.xsd";;
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPLUGIN-291) Provide toggle to enable mojo detection for dependencies
[ https://issues.apache.org/jira/browse/MPLUGIN-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPLUGIN-291. -- Resolution: Resolved Assignee: Robert Scholte > Provide toggle to enable mojo detection for dependencies > > > Key: MPLUGIN-291 > URL: https://issues.apache.org/jira/browse/MPLUGIN-291 > Project: Maven Plugin Tools > Issue Type: New Feature >Affects Versions: 3.4 >Reporter: Benjamin Asbach >Assignee: Robert Scholte >Priority: Minor > Labels: easyfix, easytest, features, maven, patch > Attachments: MPLUGIN-291.patch > > > I currently develop a decompiler plugin which should provide multiple > decompilers as separate plugin. So basically the idea is to have a generic > mojo which I include in the separate implementation as a dependency which > currently won't work since mojos are not recognized in dependencies. > I already wrote a patch which I'll attach to that ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6024) maven-antrun-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[ https://issues.apache.org/jira/browse/MNG-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S V Mohana Rao updated MNG-6024: Priority: Blocker (was: Major) > maven-antrun-plugin:instrument failing NoClassDefFoundError: > org/slf4j/LoggerFactory > > > Key: MNG-6024 > URL: https://issues.apache.org/jira/browse/MNG-6024 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Window 7, JDK 1.8.0_40 >Reporter: S V Mohana Rao >Priority: Blocker > Attachments: mvn-coreslf4j-issue.txt > > > Related issues : MNG-5783, MNG-5817. I was using maven-antrun-plugin added > dependency cobertura which requires slf4j-api dependent jar. Even i tried > using 3.4.0-SNAPSHOT version but problem persists. As i was observed it's > been excluded from the child dependent artifacts of cobertura cause it's part > maven core. But it's not referring from maven core which hasn't been added > class path. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
