[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352967#comment-352967 ] Dennis Lundberg commented on MCHANGES-341: -- Hi Mirko, If these new configuration parameters are unique to JIRA that should be reflected in the parameter names, i.e. jiraConnectionTimeout. The Changes plugin supports several issue management systems. Externalize JIRA server timeout values to the configuration section --- Key: MCHANGES-341 URL: https://jira.codehaus.org/browse/MCHANGES-341 Project: Maven Changes Plugin Issue Type: Improvement Reporter: Boris Pavlovic Assignee: Mirko Friedenhagen Fix For: 2.11 [Based on the StackOverflow Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] QUESTION: I have a maven-changes-plugin configured for a build process. Sometimes, JIRA intranet server is down and the build takes ages waiting for a long timeout on JIRA. Is there a way to configure the timeout? ANSWER: It does not appear so. The source for the RestJiraDownloader, the class that queries JIRA for issues, has hard-coded timeout values. Lines 562-566 indicate a connection timeout of 36 seconds and a receive timeout of 32 seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352969#comment-352969 ] Mirko Friedenhagen commented on MCHANGES-341: - Hello, [~dennislundberg], this is already stated in the documentation. Other parameters like webUser, webPassword etc. are only used for JIRA as well. Maybe this is because JIRA was the first system :-) Externalize JIRA server timeout values to the configuration section --- Key: MCHANGES-341 URL: https://jira.codehaus.org/browse/MCHANGES-341 Project: Maven Changes Plugin Issue Type: Improvement Reporter: Boris Pavlovic Assignee: Mirko Friedenhagen Fix For: 2.11 [Based on the StackOverflow Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] QUESTION: I have a maven-changes-plugin configured for a build process. Sometimes, JIRA intranet server is down and the build takes ages waiting for a long timeout on JIRA. Is there a way to configure the timeout? ANSWER: It does not appear so. The source for the RestJiraDownloader, the class that queries JIRA for issues, has hard-coded timeout values. Lines 562-566 indicate a connection timeout of 36 seconds and a receive timeout of 32 seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Created] (MPOM-59) enable checkstyle:check on every build
Hervé Boutemy created MPOM-59:
-
Summary: enable checkstyle:check on every build
Key: MPOM-59
URL: https://issues.apache.org/jira/browse/MPOM-59
Project: Maven POMs
Issue Type: Wish
Components: maven
Affects Versions: MAVEN-24
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
Fix For: MAVEN-25
the new maven-checkstyle-plugin 2.13 supports {{@SuppressWarnings}},
{{CHECKSTYLE_OFF/ON}} to suppress some violations
and for rules that will be seen causing really too much harm for fixing on
every place, we can use {{violationIgnore}} parameter, through its
{{checkstyle.violation.ignore}} parameter:
http://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#violationIgnore
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MASSEMBLY-648) lineEnding in fileSet corrupts jar files
[
https://jira.codehaus.org/browse/MASSEMBLY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352970#comment-352970
]
Karl-Heinz Marbaise commented on MASSEMBLY-648:
---
So i have tried to reproduce the problem with maven-assembly-plugin:2.3 and
maven-assembly-plugin:2.4 and maven-assembly-plugin:2.4.1.
{code}
[INFO] --- maven-assembly-plugin:2.3:single (assemly) @ assembly-lineEnding ---
[INFO] Reading assembly descriptor: src/main/assembly/bin.xml
[INFO] Building zip:
/massembly/massembly-648/target/assembly-lineEnding-1.0-SNAPSHOT-bin.zip
[INFO] Building tar:
/massembly/massembly-648/target/assembly-lineEnding-1.0-SNAPSHOT-bin.tar.gz
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 2.185s
[INFO] Finished at: Sun Sep 21 22:51:23 CEST 2014
[INFO] Final Memory: 15M/215M
[INFO]
$ ls -al target/
archive-tmp/
assembly-lineEnding-1.0-SNAPSHOT-bin.zip
assembly-lineEnding-1.0-SNAPSHOT-bin.tar.gz work-tmp/
$ ls -al target/archive-tmp/fileSetFormatter.
fileSetFormatter.1954286275.tmp/ fileSetFormatter.344610494.tmp/
$ ls -al target/archive-tmp/fileSetFormatter.
fileSetFormatter.1954286275.tmp/ fileSetFormatter.344610494.tmp/
$ ls -al target/archive-tmp/fileSetFormatter.1954286275.tmp/
total 3696
drwxr-xr-x 4 kama staff 136 Sep 21 22:51 .
drwxr-xr-x 4 kama staff 136 Sep 21 22:51 ..
-rw-r--r-- 1 kama staff 942171 Sep 21 22:51 maven-core-3.0.5.jar
-rw-r--r-- 1 kama staff 942171 Sep 21 22:51
maven-core-3.0.5.jar.281164798.formatted
$ ls -al target/work-tmp/
deps/ maven-core-3.0.5.jar
$ ls -al target/work-tmp/
total 1096
drwxr-xr-x 4 kama staff 136 Sep 21 22:51 .
drwxr-xr-x 6 kama staff 204 Sep 21 22:51 ..
drwxr-xr-x 3 kama staff 102 Sep 21 22:51 deps
-rw-r--r-- 1 kama staff 558991 Sep 21 22:51 maven-core-3.0.5.jar
{code}
Which means that already in maven-assembly-plugin:2.3 the file has been
corrupted. The original size is 558991 bytes size which is changed.
I have also tested the same scenario with maven-assembly-plugin:2.4 and
maven-assembly-plugin:2.4.1 and no change in behaviour. This means i'm at the
moment not able to reproduce the problem.
So the questions is if we see such configuration which must result in corrupted
jar files as wrong and try to generate a warnging etc. from it?
lineEnding in fileSet corrupts jar files
Key: MASSEMBLY-648
URL: https://jira.codehaus.org/browse/MASSEMBLY-648
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Maven 3.0.5 on Mac Os 10.8.3 with Apple JDK 1.6.0_43
Maven 3.0.5 on Windows XP with Oracle JDK 1.6.0_31
Reporter: Anders Hammar
Priority: Minor
Fix For: 2.5
Attachments: assembly-lineEnding.zip
I've found a difference in behavior between v2.3 and v2.4 of the plugin. If
lineEnding is set to, for example, unix for a fileSet which contains jar
files, the jar files are modified and corrupt with v2.4. This was not the
case with v2.3. See attached test project.
Not sure if this is an actual bug in the plugin, or rather a misconfiguation
in the project. But the behavioral change between the versions is a fact. :-)
If this is not a bug, maybe we could try to detect misconfiguration like this
and output a warning?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-421) Not authorized when deploying artifact following HTTP redirect
Bruno Medeiros created WAGON-421:
Summary: Not authorized when deploying artifact following HTTP
redirect
Key: WAGON-421
URL: https://jira.codehaus.org/browse/WAGON-421
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.7, 2.6, 2.5, 2.4
Environment: Maven 3.0.4+
Reporter: Bruno Medeiros
Priority: Critical
I always deployed artifacts to my repository without problems, until last week
when I was forced to migrate my repository to a different URL. I still have
control of the old domain, so I set a redirect in Apache on the old domain,
like this:
bq. Redirect permanent /maven2 http://newsubdomain.company.com/maven2
Deploys works perfect with the old URL for maven 2.2.1 and 3.0.3, but all maven
3.0.4+ are broken (even 3.1.1 and 3.2.3). Here follows my test:
# ~/apache-maven-3.2.3/bin/mvn -X deploy
error (full stacktrace):
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project jcompany_flex_util: Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project jcompany_flex_util: Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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: Failed to retrieve
remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
at
org.apache.maven.plugin.deploy.DeployMojo.deployProject(DeployMojo.java:284)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:169)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Failed to retrieve remote metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml: Could not
transfer metadata
br.com.company:jcompany_flex_util:0.4.0-SNAPSHOT/maven-metadata.xml from/to
company-repo (http://dev.company.com.br:80/maven2/libs-snapshots-local): Not
authorized , ReasonPhrase:Unauthorized.
[jira] (WAGON-369) wagon http doesn't follow HTTP 302 redirects for PUT
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352971#comment-352971
]
Bruno Medeiros commented on WAGON-369:
--
Mukarram, I have a very similar problem, but I get the wrong Unauthorized
problem when following redirects with any maven above 3.0.4, even 3.1.1 a 3.2.3.
I've just created a new issue for that:
https://jira.codehaus.org/browse/WAGON-421
wagon http doesn't follow HTTP 302 redirects for PUT
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352972#comment-352972 ] Dennis Lundberg commented on MCHANGES-341: -- I'm sure that this is well documented. That is not the problem. The parameters you mention was most likely added when JIRA was the only supported external issue management system. Hence there was no need at the time to prefix them with jira. We might consider deprecating those parameters and introducing new ones with a prefix, but that's another issue :-) My concern is what happens when the Trac or Github fetchers wants a similar parameter. In my opinion it is wise at this time to prefix a new parameter with the issue management system it is used for, if it only works for one. If the parameter works for all issue management systems then there is no need for a prefix. Externalize JIRA server timeout values to the configuration section --- Key: MCHANGES-341 URL: https://jira.codehaus.org/browse/MCHANGES-341 Project: Maven Changes Plugin Issue Type: Improvement Reporter: Boris Pavlovic Assignee: Mirko Friedenhagen Fix For: 2.11 [Based on the StackOverflow Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] QUESTION: I have a maven-changes-plugin configured for a build process. Sometimes, JIRA intranet server is down and the build takes ages waiting for a long timeout on JIRA. Is there a way to configure the timeout? ANSWER: It does not appear so. The source for the RestJiraDownloader, the class that queries JIRA for issues, has hard-coded timeout values. Lines 562-566 indicate a connection timeout of 36 seconds and a receive timeout of 32 seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-317) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MWAR-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reassigned MWAR-317: Assignee: Karl-Heinz Marbaise Upgrade to Maven 2.2.1 compatiblity --- Key: MWAR-317 URL: https://jira.codehaus.org/browse/MWAR-317 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 2.5 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: 2.5 Upgrade minimum Maven version to 2.2.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
