[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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(De
[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-tabpanel&focusedCommentId=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)
