[jira] [Commented] (MENFORCER-299) Failure with ${revision}
[
https://issues.apache.org/jira/browse/MENFORCER-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461690#comment-16461690
]
Pavan Bawdane commented on MENFORCER-299:
-
+1
> Failure with ${revision}
>
>
> Key: MENFORCER-299
> URL: https://issues.apache.org/jira/browse/MENFORCER-299
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently the build fail in case of usage of the {{$revision}}
> {code}
> [WARNING] Rule 2: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find io.x.parent:parent:pom:${revision} in
> http://localhost:8081/nexus/content/groups/public was cached in the local
> repository, resolution will not be reattempted until the update interval of
> nexus has elapsed or updates are forced
> io..parent:parent:pom:${revision}
> {code}
> {code}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-maven) on project conference-root: Some Enforcer rules have failed.
> Look above for specific messages explaining why the rule failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> 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: Some Enforcer
> rules have failed. Look above for specific messages explaining why the rule
> failed.
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:243)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at
[jira] [Updated] (MNG-6386) ${project.baseUri} is not a valid URI (according to RFC 3986)
[
https://issues.apache.org/jira/browse/MNG-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6386:
Description:
{{File#toURI}} produces an invalid URI on Windows:
{noformat}
file:/C:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///C:/path/to/basedir{noformat}
Same issue for Unix-like OSes:
{noformat}
file:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///path/to/basedir{noformat}
Using {{Path#toUri}} we can easily solve that problem because it creates
compliant URIs. The failure occurs when interacting with local Git and
Subversion repos:
{noformat}
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
svn: E020024: Error resolving case of
'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
while the proper (new) havior will produce a valid URI:
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
branches/
tags/
trunk/
{noformat}
{noformat}
PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
tlll2
Cloning into 'tlll2'...
warning: You appear to have cloned an empty repository.
PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll tlll2
Cloning into 'tlll2'...
ssh: Could not resolve hostname file: Name or service not known
fatal: Could not read from remote repository.
{noformat}
or Subversion repo at: {{D:\Entwicklung\svn-repos\это по-русский}}:
{noformat}
PS D:\Entwicklung\Projekte> svn ls
file:/D:/Entwicklung/svn-repos/это%20по-русский/
svn: E020024: Error resolving case of
'file:\D:\Entwicklung\svn-repos\???%20??-???\'
{noformat}
proper URI gives:
{noformat}
PS D:\Entwicklung\Projekte> svn ls
file:///D:/Entwicklung/svn-repos/%D1%8D%D1%82%D0%BE%20%D0%BF%D0%BE-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9/
branches/
tags/
trunk/
{noformat}
was:
{{File#toURI}} produces an invalid URI on Windows:
{noformat}
file:/C:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///C:/path/to/basedir{noformat}
Same issue for Unix-like OSes:
{noformat}
file:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///path/to/basedir{noformat}
Using {{Path#toUri}} we can easily solve that problem because it creates
compliant URIs. The failure occurs when interacting with local Git and
Subversion repos:
{noformat}
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
svn: E020024: Error resolving case of
'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
while the proper (new) havior will produce a valid URI:
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
branches/
tags/
trunk/
{noformat}
{noformat}
PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
tlll2
Cloning into 'tlll2'...
warning: You appear to have cloned an empty repository.
PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll tlll2
Cloning into 'tlll2'...
ssh: Could not resolve hostname file: Name or service not known
fatal: Could not read from remote repository.
{noformat}
> ${project.baseUri} is not a valid URI (according to RFC 3986)
> -
>
> Key: MNG-6386
> URL: https://issues.apache.org/jira/browse/MNG-6386
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.4-candidate
>
>
> {{File#toURI}} produces an invalid URI on Windows:
> {noformat}
> file:/C:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///C:/path/to/basedir{noformat}
> Same issue for Unix-like OSes:
> {noformat}
> file:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///path/to/basedir{noformat}
> Using {{Path#toUri}} we can easily solve that problem because it creates
> compliant URIs. The failure occurs when interacting with local Git and
> Subversion repos:
> {noformat}
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> svn: E020024: Error resolving case of
> 'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
> while the proper (new) havior will produce a valid URI:
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> branches/
> tags/
> trunk/
> {noformat}
> {noformat}
> PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> warning: You appear to have cloned an empty repository.
> PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> ssh: Could not resolve hostname file: Name or service not known
> fatal:
[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore
[
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461638#comment-16461638
]
Hudson commented on MNGSITE-332:
Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » master #20
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/master/20/
> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
> Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this
> has to be changed into links to {{sha1}} and {{sha256}} instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6386) ${project.baseUri} is not a valid URI (according to RFC 3986)
[
https://issues.apache.org/jira/browse/MNG-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6386:
Description:
{{File#toURI}} produces an invalid URI on Windows:
{noformat}
file:/C:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///C:/path/to/basedir{noformat}
Same issue for Unix-like OSes:
{noformat}
file:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///path/to/basedir{noformat}
Using {{Path#toUri}} we can easily solve that problem because it creates
compliant URIs. The failure occurs when interacting with local Git and
Subversion repos:
{noformat}
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
svn: E020024: Error resolving case of
'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
while the proper (new) havior will produce a valid URI:
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
branches/
tags/
trunk/
{noformat}
{noformat}
PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
tlll2
Cloning into 'tlll2'...
warning: You appear to have cloned an empty repository.
PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll tlll2
Cloning into 'tlll2'...
ssh: Could not resolve hostname file: Name or service not known
fatal: Could not read from remote repository.
{noformat}
was:
{{File#toURI}} produces an invalid URL on Windows:
{noformat}
file:/C:/path/to/basedir{noformat}
A valid URI has to be:
{noformat}
file:///C:/path/to/basedir{noformat}
Using {{Path#toUri}} we can easily solve that problem.
> ${project.baseUri} is not a valid URI (according to RFC 3986)
> -
>
> Key: MNG-6386
> URL: https://issues.apache.org/jira/browse/MNG-6386
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.4-candidate
>
>
> {{File#toURI}} produces an invalid URI on Windows:
> {noformat}
> file:/C:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///C:/path/to/basedir{noformat}
> Same issue for Unix-like OSes:
> {noformat}
> file:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///path/to/basedir{noformat}
> Using {{Path#toUri}} we can easily solve that problem because it creates
> compliant URIs. The failure occurs when interacting with local Git and
> Subversion repos:
> {noformat}
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> svn: E020024: Error resolving case of
> 'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
> while the proper (new) havior will produce a valid URI:
> PS D:\Entwicklung\Projekte\maven-scm> svn ls
> file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
> branches/
> tags/
> trunk/
> {noformat}
> {noformat}
> PS D:\Entwicklung\Projekte> git clone file:///D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> warning: You appear to have cloned an empty repository.
> PS D:\Entwicklung\Projekte> git clone file:/D:/Entwicklung/git-repos/toll
> tlll2
> Cloning into 'tlll2'...
> ssh: Could not resolve hostname file: Name or service not known
> fatal: Could not read from remote repository.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6386) ${project.baseUri} is not a valid URI (according to RFC 3986)
[
https://issues.apache.org/jira/browse/MNG-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6386:
Summary: ${project.baseUri} is not a valid URI (according to RFC 3986)
(was: project.baseUri is not a valid URL on Windows)
> ${project.baseUri} is not a valid URI (according to RFC 3986)
> -
>
> Key: MNG-6386
> URL: https://issues.apache.org/jira/browse/MNG-6386
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.4-candidate
>
>
> {{File#toURI}} produces an invalid URL on Windows:
> {noformat}
> file:/C:/path/to/basedir{noformat}
> A valid URI has to be:
> {noformat}
> file:///C:/path/to/basedir{noformat}
> Using {{Path#toUri}} we can easily solve that problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MEJB-112) JDK 9 WARNING in Integration Test
[
https://issues.apache.org/jira/browse/MEJB-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MEJB-112:
-
Fix Version/s: (was: 3.0.1)
3.0.2
> JDK 9 WARNING in Integration Test
> -
>
> Key: MEJB-112
> URL: https://issues.apache.org/jira/browse/MEJB-112
> Project: Maven EJB Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.2
>
>
> Currently running on JDK 9 (EA+181) give the following warning during running
> via {{mvn -Prun-its clean verify}}:
> {code}
> [INFO] ..SUCCESS (3.8 s)
> [INFO] Building: mejb-93/pom.xml
> [INFO] run script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass$3$1
> (file:/Users/kama/.m2/repository/org/codehaus/groovy/groovy/2.0.1/groovy-2.0.1.jar)
> to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass$3$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [INFO] ..SUCCESS (4.1 s)
> [INFO] Building: reactor/pom.xml
> [INFO] run script verify.bsh
> [INFO] ..SUCCESS (3.4 s)
> {code}
> Upgrading to maven-invoker-plugin:3.0.1:
> {code}
> [INFO] run post-build script verify.bsh
> [INFO] MEJB-72/pom.xml .. SUCCESS
> (3.7 s)
> [INFO] Building: mejb-93/pom.xml
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/Users/kama/.m2/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [INFO] mejb-93/pom.xml .. SUCCESS
> (4.1 s)
> [INFO] Building: reactor/pom.xml
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-725) Upgrade wagon-provider-api to 3.0.0
Karl Heinz Marbaise created MSHARED-725: --- Summary: Upgrade wagon-provider-api to 3.0.0 Key: MSHARED-725 URL: https://issues.apache.org/jira/browse/MSHARED-725 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-io Affects Versions: maven-shared-io-3.0.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-shared-io-3.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MWAR-378) Package Excludes doesn't work
[
https://issues.apache.org/jira/browse/MWAR-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MWAR-378:
-
Fix Version/s: waiting-for-feedback
> Package Excludes doesn't work
> -
>
> Key: MWAR-378
> URL: https://issues.apache.org/jira/browse/MWAR-378
> Project: Maven WAR Plugin
> Issue Type: Bug
> Environment: Windows 10, eclipse Mars
>Reporter: Allyn Tobey
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The regex compiles, and runs in java, but it doesn't exclude the jar files. I
> am doing an or so i was able to use wild card characters and it is working
> but wanted to let you know my regex didn't work. Is there something wrong
> with my regex?
> {code}%regex[WEB-INF/lib/[email\\-library\\-|web\\-services\\-library\\-].*\\.jar]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MWAR-378) Package Excludes doesn't work
[
https://issues.apache.org/jira/browse/MWAR-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461561#comment-16461561
]
Karl Heinz Marbaise commented on MWAR-378:
--
Do you have an example project for that problem? Otherwise it's hard to
identify if the problem is related to the plugin or something else?
> Package Excludes doesn't work
> -
>
> Key: MWAR-378
> URL: https://issues.apache.org/jira/browse/MWAR-378
> Project: Maven WAR Plugin
> Issue Type: Bug
> Environment: Windows 10, eclipse Mars
>Reporter: Allyn Tobey
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The regex compiles, and runs in java, but it doesn't exclude the jar files. I
> am doing an or so i was able to use wild card characters and it is working
> but wanted to let you know my regex didn't work. Is there something wrong
> with my regex?
> {code}%regex[WEB-INF/lib/[email\\-library\\-|web\\-services\\-library\\-].*\\.jar]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MWAR-395) REGRESSION: Conflict with Workspace Resolution in Eclipse
[
https://issues.apache.org/jira/browse/MWAR-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MWAR-395.
Resolution: Not A Problem
On Command line Maven works fine. It looks more like a M2E problem.
> REGRESSION: Conflict with Workspace Resolution in Eclipse
> -
>
> Key: MWAR-395
> URL: https://issues.apache.org/jira/browse/MWAR-395
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.5, 2.6
> Environment: Eclipse Mars (4.5.2)
> Eclipse m2e 1.6.2
>Reporter: JDM
>Priority: Major
> Attachments: MWAR-395.zip
>
>
> MWAR-192 first introduced this issue. When executing a Maven WAR build
> through Eclipse, it allows resolution of other projects within the workspace
> via "Resolve Workspace artifacts" in the run configuration. This replaces the
> project dependencies that would normally be JARs with the {{target/classes}}
> directories for the projects.
> Here's a sample verbose output from the compiler plugin which shows this
> replacement, where "WarProject" is the WAR project and "JarProject" is a JAR
> project:
> {code}
> [DEBUG] Classpath: [~/WarProject/target/classes
> ~/JarProject/target/classes
>
> ~/.m2/repository/javax/servlet/javax.servlet-api/3.0.1/javax.servlet-api-3.0.1.jar]
> {code}
> This was corrected with a patch merged in revision
> [1492158|https://fisheye6.atlassian.com/changelog/maven?cs=1492158].
> Unfortunately, this fix was then regressed 18 days later by revision
> [1498124|https://fisheye6.atlassian.com/changelog/maven?cs=1498124] for issue
> MWAR-128.
> Previous to the second commit, the {{target/classes}} directory would be
> passed to {{AbstractWarPackagingTask.copyFile}} by
> {{ArtifactsPackagingTask.performPackaging}}. It would then be registered and
> passed to the second overload of {{AbstractWarPackagingTask.copyFile}}, where
> the directory would then be bundled into a JAR.
> After the second commit, any directory passed to that first {{copyFile}} will
> simply result in an empty directory with the target name being created. This
> is exactly the result I see after packaging the WAR:
> {code}
> WarProject-1.0.0.war
> |> WEB-INF/
>|> lib/
> |> JarProject-1.0.0.jar/
> |> javax.servlet-api-3.0.1.jar
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MWAR-399) Maven WAR Plugin imports MAR/AAR Dependencies - can not be disabled
[
https://issues.apache.org/jira/browse/MWAR-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MWAR-399:
-
Fix Version/s: waiting-for-feedback
> Maven WAR Plugin imports MAR/AAR Dependencies - can not be disabled
> ---
>
> Key: MWAR-399
> URL: https://issues.apache.org/jira/browse/MWAR-399
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jeff Thomas
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Included Axis2 AAR/MAR Dependencies are automatically added to the WAR. This
> functionality can currently not be disabled.
> Axis2 provides a separate plugin for performing the task of creating an Axis2
> Repository including AAR/MAR dependencies
> ("org.apache.axis2:axis2-repo-maven-plugin").
> Reasons to allow disabling:
> 1. The Axis2 Repository *default* is "WEB-INF" (ie. WEB-INF/modules,
> WEB-INF/services); however this is not a requirement. The Axis2 Repository
> can be located somewhere else ("WEB-INF/foobar/modules") - by default it is
> relative to the location of the "axis2.xml" file.
> 2. A single WAR can contain multiple Axis2 repositories with different
> modules and services. (ie. "WEB-INF/client/modules" and
> "WEB-INF/server/moduels"). Currently *all* MARs are sent to "WEB-INF/lib"
> and adding the Axis2 plugin to the mix to use a non-standard location results
> in at least two copies of every AAR/MAR.
> Filtering the artifact "*.aar" or "*.mar" with "" works on
> the final WAR packaging (not on the exploded); however, causes other problems
> - all filtered artifacts are no longer recognized as dependencies. As such,
> in a multi-module project with a custom MAR and a WAR dependent on the MAR -
> if filtered, the MAR project is no longer correctly associated with the WAR
> project disabling dynamic hotswap debugging.
> I believe what I am looking for is a MOJO parameter to disable the packaging
> of specific artifact types (without completely filtering them out of the
> dependencies). This parameter would probably be set in the
> WarPackagingContext and picked up in the ArtifactsPackagingTask. (?!?)
> My workaround at the moment is not so great. I have build a special
> variation of the axis2-repo-maven-plugin which picks up MAR dependencies with
> scope "runtime" and flagged as optional. The maven-war-plugin ignores these.
> The problem with the workaround is the above mentioned Eclipse m2e problem
> which doesn't associate the MAR source projects on runtime dependencies.
> This can be resolved with an Eclipse-only profile, but the solution is not
> "clean". Disabling the MAR packaging on the WAR would solve these problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-695) Move checksum creation from install part to deploy part
[ https://issues.apache.org/jira/browse/MSHARED-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461266#comment-16461266 ] Hudson commented on MSHARED-695: Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » MSHARED-695 #3 See https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/MSHARED-695/3/ > Move checksum creation from install part to deploy part > --- > > Key: MSHARED-695 > URL: https://issues.apache.org/jira/browse/MSHARED-695 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.10.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: maven-artifact-transfer-0.10.0 > > > We should remove the checksum generation from install parts and move them > consistently to the deploy part instead -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore
[
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461265#comment-16461265
]
Hudson commented on MNGSITE-332:
Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » MSHARED-695 #3
See
https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/MSHARED-695/3/
> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
> Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this
> has to be changed into links to {{sha1}} and {{sha256}} instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-235) Upgrade mave-surefire/failsafe-plugin 2.21.0
[ https://issues.apache.org/jira/browse/MDEPLOY-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461264#comment-16461264 ] Hudson commented on MDEPLOY-235: Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » MSHARED-695 #3 See https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/MSHARED-695/3/ > Upgrade mave-surefire/failsafe-plugin 2.21.0 > > > Key: MDEPLOY-235 > URL: https://issues.apache.org/jira/browse/MDEPLOY-235 > Project: Maven Deploy Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1408) Surefire shows random tests failing with fork issue when one of the tests hangs
[
https://issues.apache.org/jira/browse/SUREFIRE-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461259#comment-16461259
]
Tibor Digana commented on SUREFIRE-1408:
[~aonishuk]
We should continue on this issue. Where did we take the Git link to Ambari
especially related to this issue?
We have to reproduce the problem again and find the root cause.
> Surefire shows random tests failing with fork issue when one of the tests
> hangs
> ---
>
> Key: SUREFIRE-1408
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1408
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.20
>Reporter: Andrew Onischuk
>Assignee: Tibor Digana
>Priority: Blocker
>
> This was blocking 100% of test runs. Random tests were failing due to fork
> issue. Which made us really confused on what is happening. We tried a lot of
> options to fix this (fix memory,ulimits,sys.exit etc.)
> {noformat}
> [WARNING] Tests run: 4830, Failures: 0, Errors: 0, Skipped: 35
> [INFO]
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Views .. SUCCESS [4.001s]
> [INFO] utility ... SUCCESS [1.057s]
> [INFO] Ambari Metrics Common . SUCCESS [14.892s]
> [INFO] Ambari Server . FAILURE
> [28:40.637s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 29:01.548s
> [INFO] Finished at: Wed Sep 06 13:53:46 EEST 2017
> [INFO] Final Memory: 49M/583M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on
> project ambari-server: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /tmp/ambari_test_java/ambari-server/target/surefire-reports for the
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter7964123771295668464.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun4 surefire3196986160626902066tmp
> surefire_494835328994998108571tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] Crashed tests:
> [ERROR] org.apache.ambari.server.controller.AmbariServerTest
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter5127210523160415183.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun1 surefire5729106817171066937tmp
> surefire_5004808314434139002513tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter3901662057959462367.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun2 surefire1724459552574953042tmp
> surefire_5012934123283689072947tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] Crashed tests:
> [ERROR]
> org.apache.ambari.server.controller.metrics.ganglia.GangliaPropertyProviderTest
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter8706425108380679609.jar
>
[jira] [Commented] (SUREFIRE-1408) Surefire shows random tests failing with fork issue when one of the tests hangs
[
https://issues.apache.org/jira/browse/SUREFIRE-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461191#comment-16461191
]
Eugene Tenkaev commented on SUREFIRE-1408:
--
What the status of this? Same issue in 2.21.0
> Surefire shows random tests failing with fork issue when one of the tests
> hangs
> ---
>
> Key: SUREFIRE-1408
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1408
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.20
>Reporter: Andrew Onischuk
>Assignee: Tibor Digana
>Priority: Blocker
>
> This was blocking 100% of test runs. Random tests were failing due to fork
> issue. Which made us really confused on what is happening. We tried a lot of
> options to fix this (fix memory,ulimits,sys.exit etc.)
> {noformat}
> [WARNING] Tests run: 4830, Failures: 0, Errors: 0, Skipped: 35
> [INFO]
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Views .. SUCCESS [4.001s]
> [INFO] utility ... SUCCESS [1.057s]
> [INFO] Ambari Metrics Common . SUCCESS [14.892s]
> [INFO] Ambari Server . FAILURE
> [28:40.637s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 29:01.548s
> [INFO] Finished at: Wed Sep 06 13:53:46 EEST 2017
> [INFO] Final Memory: 49M/583M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on
> project ambari-server: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /tmp/ambari_test_java/ambari-server/target/surefire-reports for the
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter7964123771295668464.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun4 surefire3196986160626902066tmp
> surefire_494835328994998108571tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] Crashed tests:
> [ERROR] org.apache.ambari.server.controller.AmbariServerTest
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter5127210523160415183.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun1 surefire5729106817171066937tmp
> surefire_5004808314434139002513tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter3901662057959462367.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun2 surefire1724459552574953042tmp
> surefire_5012934123283689072947tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] Crashed tests:
> [ERROR]
> org.apache.ambari.server.controller.metrics.ganglia.GangliaPropertyProviderTest
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /tmp/ambari_test_java/ambari-server &&
> /usr/local/java/jdk1.8.0_25/jre/bin/java -Xmx2048m -XX:MaxPermSize=1024m
> -Xms1024m -jar
> /tmp/ambari_test_java/ambari-server/target/surefire/surefirebooter8706425108380679609.jar
> /tmp/ambari_test_java/ambari-server/target/surefire
> 2017-09-06T13-25-37_978-jvmRun4 surefire3030080908304903958tmp
>
[jira] [Comment Edited] (MNG-5102) Mixin POM fragments
[ https://issues.apache.org/jira/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460994#comment-16460994 ] Andrew VanLoo edited comment on MNG-5102 at 5/2/18 1:08 PM: Is it possible to use some kind of `include`s directive, like Apache Web Server does with configuration files? That works extremely well there. I just found: https://issues.apache.org/jira/browse/MNG-5173 Although, I am not altogether clear on why abritrary POMs will break things... was (Author: gumshoe2055): Is it possible to use some kind of `include`s directive, like Apache Web Server does with configuration files? That works extremely well there. > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://issues.apache.org/jira/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford >Priority: Major > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5102) Mixin POM fragments
[ https://issues.apache.org/jira/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460994#comment-16460994 ] Andrew VanLoo commented on MNG-5102: Is it possible to use some kind of `include`s directive, like Apache Web Server does with configuration files? That works extremely well there. > Mixin POM fragments > --- > > Key: MNG-5102 > URL: https://issues.apache.org/jira/browse/MNG-5102 > Project: Maven > Issue Type: Wish > Components: FDPFC, POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford >Priority: Major > Fix For: Issues to be reviewed for 4.x > > Attachments: daddy3.zip, maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6360) Maven doesn't export org.slf4j.event.Level
[ https://issues.apache.org/jira/browse/MNG-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6360. --- Resolution: Cannot Reproduce > Maven doesn't export org.slf4j.event.Level > -- > > Key: MNG-6360 > URL: https://issues.apache.org/jira/browse/MNG-6360 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Blocker > > Hi > maven doesn't export org.slf4j.event package in > maven-core/src/main/resources/META-INF/maven/extension.xml so this package > from slf4j is not usable in mojos/extensions which lead to a weird > classloading for slf4j users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460694#comment-16460694 ] ASF GitHub Bot commented on SCM-714: rfscholte commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-385900126 Yes, I agree This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://issues.apache.org/jira/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Assignee: Robert Scholte >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rfscholte commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows
rfscholte commented on issue #30: Fix for SCM-714: mvn release:prepare fails if the command line is too long on windows URL: https://github.com/apache/maven-scm/pull/30#issuecomment-385900126 Yes, I agree This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6360) Maven doesn't export org.slf4j.event.Level
[ https://issues.apache.org/jira/browse/MNG-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460684#comment-16460684 ] Romain Manni-Bucau commented on MNG-6360: - Hi [~michael-o], tried to reproduce it on the 3.5.3 and seems I can't anymore so I guess we can close it for now. > Maven doesn't export org.slf4j.event.Level > -- > > Key: MNG-6360 > URL: https://issues.apache.org/jira/browse/MNG-6360 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Blocker > > Hi > maven doesn't export org.slf4j.event package in > maven-core/src/main/resources/META-INF/maven/extension.xml so this package > from slf4j is not usable in mojos/extensions which lead to a weird > classloading for slf4j users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-487) Saved password with french accent breaks deployment
[
https://issues.apache.org/jira/browse/WAGON-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460677#comment-16460677
]
Michael Osipov commented on WAGON-487:
--
Here it is:
http://maven.apache.org/guides/mini/guide-http-settings.html#Fine-Tuning_HttpClient_Parameters
> Saved password with french accent breaks deployment
> ---
>
> Key: WAGON-487
> URL: https://issues.apache.org/jira/browse/WAGON-487
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 2.12
>Reporter: Dominique Jean-Prost
>Priority: Critical
> Fix For: waiting-for-feedback
>
>
> I cannot deploy any artifact to my sonatype nexus instance when using a
> pasword with french accetn, like 'é'.
> This instance needs authentication to deploy.
> My test :
> # Check authentication against nexus directly with a password containing
> accent : OK
> # Check deploy with clear password in {{settings.xml}} with no accent : OK
> # Check deploy with encrypted password in {{settings.xml}} with no accent : OK
> # Check deploy with clear password in {{settings.xml}} with accent : KO
> # Check deploy with encrypted password in {{settings.xml}} with accent : KO
> After many minutes of debugging, I managed to verify that my password is
> correctly "read" in the settings {{org.apache.maven.settings.Server}} : it
> has nothing to do with {{settings.xml}} XML encoding.
> When finally wagon enters the game, the http header with authentication basic
> contains a '? ' instead of my 'é'. I managed to narrow the problem to
> {{org.apache.maven.wagon.providers.http.httpclient.impl.auth.BasicScheme}}
> which I think is the cuplrit by not dealing correctly with charset encoding
> in the {{authenticate}} method.
> I came to the end of what I can do for the moment, appart of changing my
> password to remove the accent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-487) Saved password with french accent breaks deployment
[
https://issues.apache.org/jira/browse/WAGON-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460602#comment-16460602
]
Dominique Jean-Prost commented on WAGON-487:
Hello,
Well, I'm not sure I understand where I should set
{{http.auth.credential-charset}} in my configuration.
Would you mind giving me a detailed example of settings so that I can finally
test the patch successfully ?
Thank you.
> Saved password with french accent breaks deployment
> ---
>
> Key: WAGON-487
> URL: https://issues.apache.org/jira/browse/WAGON-487
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 2.12
>Reporter: Dominique Jean-Prost
>Priority: Critical
> Fix For: waiting-for-feedback
>
>
> I cannot deploy any artifact to my sonatype nexus instance when using a
> pasword with french accetn, like 'é'.
> This instance needs authentication to deploy.
> My test :
> # Check authentication against nexus directly with a password containing
> accent : OK
> # Check deploy with clear password in {{settings.xml}} with no accent : OK
> # Check deploy with encrypted password in {{settings.xml}} with no accent : OK
> # Check deploy with clear password in {{settings.xml}} with accent : KO
> # Check deploy with encrypted password in {{settings.xml}} with accent : KO
> After many minutes of debugging, I managed to verify that my password is
> correctly "read" in the settings {{org.apache.maven.settings.Server}} : it
> has nothing to do with {{settings.xml}} XML encoding.
> When finally wagon enters the game, the http header with authentication basic
> contains a '? ' instead of my 'é'. I managed to narrow the problem to
> {{org.apache.maven.wagon.providers.http.httpclient.impl.auth.BasicScheme}}
> which I think is the cuplrit by not dealing correctly with charset encoding
> in the {{authenticate}} method.
> I came to the end of what I can do for the moment, appart of changing my
> password to remove the accent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460567#comment-16460567
]
Abel Salgado Romero commented on SUREFIRE-1255:
---
I already run some isolation back when we found it doing a general upgrade:
https://github.com/asciidoctor/asciidoctor-maven-plugin/pull/337.
If you want to reproduce it, just download the project from the repo
https://github.com/asciidoctor/asciidoctor-maven-plugin/, upgrade the surefire
version
https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/pom.xml#L346
and run the tests.
I honestly don't discard the issue is caused by some combination of factors,
but so far this is the only lead I found :%.
Note: the first test starts an embedded server and that can be missleading, add
an {{@Ignore}} if you prefer to see the issue with a normal test.
> Surefire 2.19.1 hangs before starting test execution
>
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of
> tests with no log output from the test itself, e.g.
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> [ERROR] Command was /bin/sh -c cd
> /home/travis/build/mxm/flink/flink-scala-shell/target &&
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1
> -XX:-UseGCOverheadLimit -jar
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the
> problem (Ran over 100 builds). It seems to be a race condition because it
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I
> haven't been able to reproduce the problem locally.
> More logs:
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
