Handle better in versioneye:update situation when versioneye server is unavailable

[sslavic]

I just had a build fail when performing versioneye:update

build   03-Dec-2014 16:09:49    org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.versioneye:versioneye-maven-plugin:3.1.0:update (default-cli) on project foo-bar: Oh no! Something went wrong. Get in touch with the VersionEye guys and give them feedback. You find them on Twitter at https//twitter.com/VersionEye. 
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
build   03-Dec-2014 16:09:49        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
build   03-Dec-2014 16:09:49        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
build   03-Dec-2014 16:09:49        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
build   03-Dec-2014 16:09:49        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
build   03-Dec-2014 16:09:49        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
build   03-Dec-2014 16:09:49        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build   03-Dec-2014 16:09:49        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
build   03-Dec-2014 16:09:49        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
build   03-Dec-2014 16:09:49        at java.lang.reflect.Method.invoke(Method.java:606)
build   03-Dec-2014 16:09:49        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
build   03-Dec-2014 16:09:49        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
build   03-Dec-2014 16:09:49        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
build   03-Dec-2014 16:09:49        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
build   03-Dec-2014 16:09:49    Caused by: org.apache.maven.plugin.MojoExecutionException: Oh no! Something went wrong. Get in touch with the VersionEye guys and give them feedback. You find them on Twitter at https//twitter.com/VersionEye. 
build   03-Dec-2014 16:09:49        at com.versioneye.UpdateMojo.execute(UpdateMojo.java:37)
build   03-Dec-2014 16:09:49        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
build   03-Dec-2014 16:09:49        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
build   03-Dec-2014 16:09:49        ... 19 more
build   03-Dec-2014 16:09:49    Caused by: org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
build   03-Dec-2014 16:09:49     at [Source: java.io.InputStreamReader@48f819ee; line: 1, column: 2]
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.impl.JsonParserMinimalBase._reportError(JsonParserMinimalBase.java:521)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.impl.JsonParserMinimalBase._reportUnexpectedChar(JsonParserMinimalBase.java:442)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.impl.ReaderBasedParser._handleUnexpectedValue(ReaderBasedParser.java:1198)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.java:485)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.map.ObjectMapper._initForReading(ObjectMapper.java:2770)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2718)
build   03-Dec-2014 16:09:49        at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1886)
build   03-Dec-2014 16:09:49        at com.versioneye.UpdateMojo.uploadDependencies(UpdateMojo.java:49)
build   03-Dec-2014 16:09:49        at com.versioneye.UpdateMojo.execute(UpdateMojo.java:33)
build   03-Dec-2014 16:09:49        ... 21 more

At first I thought maybe there's something wrong with my POMs - but Maven build would fail early in that case. Then I found out that versioneye server is not accessible through browser, it's returning 504.

Now (3.1.0), update mojo seems to try to process response body as JSON, even when response is not 2xx, which results in this misleading and not informative stack trace.

Please fix plugin, update mojo, so that it handles better server error condition, with more informative exception and error message.

[reiz]

Hi @sslavic. Thanks for the report. I can not really reproduce it. The VersionEye servers are all running and the API is up as well. The project you tried it with, is it open source? That would help to reproduce the bug. But you are right with the error handling, that has room for improvement :-) That will happen soon. In case your project is not open source can you please run this command in your project:

mvn versioneye:json

That will create a pom.json file in the target directory. Please send me that file via email to reiz @ versioneye.com. I will delete it after I found the bug.

[sslavic]

Server is already back up/accessible and without any modifications in pom.xml versioneye:update works.

Bug is in versioneye-maven-plugin's HttpUtils.post method - it should check for status of HttpResponse and in case of non 2xx response code throw meaningful exception. Now, when proxy in between versioneye server and client (maven/plugin), responded with error html page and 504 http status code, HttpUtils.post just passed back response body, which UpdateMojo tried to interpret as JSON string, and parsing html as json failed with JsonParseException being thrown.

[reiz]

@sslavic Just thought it's a good time to work on this ticket :-) Feel free to test it. You can build it with:

mvn clean install 

And then just use the 3.1.1-SNAPSHOT version in your projects. I will add a couple more features before releasing it to mvn central.

[sslavic]

Switched to sbt, looking forward to rtimush/sbt-updates#35

Should be easy to reproduce the issue in a test with mock server, which to update request returns non-200 response code with html page as response body.

[reiz]

That's how it works. The plugin checks the response code, if it's not 200 it displays the error message from the server in the command line. I will close this ticket and check the sbt ticket.