Jetty Annotation Timeout Reason - maven

I am tying to run my web application with maven jetty plugin. But after some time at startup, it gives the error:
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
2014-08-10 17:39:45.840:INFO:oejs.Server:main: jetty-9.2.2.v20140723
2014-08-10 17:40:54.961:WARN:oejw.WebAppContext:main: Failed startup of context o.e.j.m.p.JettyWebAppContext#1e2c8{/asd,file:/C:/dev/project/hope/target/asd-1.0/,STARTING}{C:\dev\project\hope\target\asd-1.0.war}
java.lang.Exception: Timeout scanning annotations
at org.eclipse.jetty.annotations.AnnotationConfiguration.scanForAnnotations(AnnotationConfiguration.java:570)
at org.eclipse.jetty.annotations.AnnotationConfiguration.configure(AnnotationConfiguration.java:440)
at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:471)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1329)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:497)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:365)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
I am using spring mvc with annotations and I think there is a problem about it.
When I try to run it over eclipse jetty plugin, it starts succesfully, but with maven plugin, it gives the error.
Any ideas?

I've got the same error and to fix it, you should add to your start script (start.ini) the following:
-Dorg.eclipse.jetty.annotations.maxWait=120
120 is for two minutes of annotation scanning in case that you need a higher value, just set it to the propper one.

It is useless to scan all dependent jars, you can make the scanning pattern more restrictive to only match certain jars:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.8.v20150217</version>
<configuration>
<webAppConfig>
<contextPath>/</contextPath>
<webInfIncludeJarPattern>.*/foo-[^/]*\.jar$|.*/classes/.*</webInfIncludeJarPattern>
</webAppConfig>
</configuration>
</plugin>
See webInfIncludeJarPattern doc for more details:
http://www.eclipse.org/jetty/documentation/9.4.x/jetty-maven-plugin.html#configuring-your-webapp

One more (in my opinion) convinient way is to set this property using a jetty.xml like so:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure>
<Call name="setProperty" class="java.lang.System">
<Arg>org.eclipse.jetty.annotations.maxWait</Arg>
<Arg>120</Arg>
</Call>
</Configure>
This way you can omit the commandline args

The most simple way is adding the system property in pom.xml
https://www.eclipse.org/jetty/documentation/9.4.x/jetty-maven-plugin.html#setting-system-properties

This message means scanning annotation took time more than its being configured thus timeout so this can be fixed either by increasing the timeout period (Dorg.eclipse.jetty.annotations.maxWait=120) or by deleting the tmp / webapp-tmp from target which reduces its scan time.

The property (-Dorg.eclipse.jetty.annotations.maxWait=120) can be added to start.ini so it works for all the webapps in your app base.

Related

What Build Module in IntelliJ actually does for maven module

When I run
mvn clean install
for my maven module then it compiles fine. No issues.
But when I open my pom.xml file in IntelliJ and I choose to Build -> Build module then I get following issues:
Information:javac 1.8.0_144 was used to compile java sources
Information:Module "mymodule" was fully rebuilt due to project configuration/dependencies changes
Information:09.10.2017 21:16 - Compilation completed with 3 errors and 3 warnings in 23s 991ms
C:\somepath\mymodule\pom.xml
Error:Error:osgi: [mymodule] Exception: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Failed to load plugin org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true, error: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Cannot load the plugin org.apache.sling.bnd.models.ModelsScannerPlugin
This is a module with AEM code and it uses maven-sling-plugin. It works fine for other developers in the project. Because it's working when executed directly from maven I'm trying to understand what IntelliJ does in the background. But actually, my problem is those compilation issues.
From what I've found IntelliJ does not call maven when Build is done. Any ideas how can I find differences between running from IntelliJ and directly from Maven?
What happens here is that the ModelScanner plugin can't be found using the current ClassLoader. The reason for this can be that you are using IntelliJ IDEA Ultimate which comes with a OSGI plugin already pre-installed called 'Osmorc'. If this OSGI plugin is active it will determine the classloader to be used for building OSGI related projects.
So simply de-activating this Osmorc plugin in IntelliJ should allow your build to revert to the classloader from the ModelScannerPlugin mentioned in the configuration of your the maven-bundle-plugin in your projects POM.xml file which should solve the problem.
If this still results in a similar Maven build error, then make sure to add a Maven dependency 'org.apache.sling.bnd.model' to your maven-bundle-plugin in your POM.xml file.
<!-- Apache Felix Bundle Plugin -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.3.0</version>
<inherited>true</inherited>
<extensions>true</extensions>
<executions>
<!-- Configure extra execution of 'manifest' in process-classes phase to make sure SCR metadata is generated before unit test runs -->
<execution>
<id>scr-metadata</id>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportIncrementalBuild>true</supportIncrementalBuild>
</configuration>
</execution>
</executions>
<configuration>
<exportScr>true</exportScr>
<instructions>
<!-- Enable processing of OSGI DS component annotations -->
<_dsannotations>*</_dsannotations>
<!-- Enable processing of OSGI metatype annotations -->
<_metatypeannotations>*</_metatypeannotations>
<_plugin>org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true</_plugin>
</instructions>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.bnd.models</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
could you please check your core pom file. it should contain a plugin section like this:
<plugin> <!-- Enable registration of Sling Models classes via bnd plugin --> org.apache.sling.bnd.models.ModelsScannerPlugin, <!-- Allow the processing of SCR annotations via a bnd plugin --> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory} </plugin>
but if you created a project using aem archetype the tag looks like' <_plugin>

Cannot invoke Tomcat manager w/Jenkins

I'm managing the builds for a web service with Jenkins, and I've run into a problem with Tomcat. I'm getting the following error and stack trace:
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy(default-cli) on project rnr: Cannot invoke Tomcat manager
cause : Cannot invoke Tomcat manager
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on project rnr: Cannot invoke Tomcat manager
Here's my pom configuration for the Tomcat maven plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.1</version>
<configuration>
<url>http://localhost:8080/manager/text</url>
<server>TomcatServer</server>
<path>/</path>
</configuration>
</plugin>
EDIT: I'm using Tomcat 7.0.42.
I'm not sure exactly what the problem is or if I've provided enough information, so let me know if more is needed. This is the first time I've run into this problem, and to my knowledge nothing in the pom or jenkins setup has changed, so I don't know where this error is coming from.
Thank you!!

Cargo hangs while starting GlassFish 4.x and uses up 100% CPU

Trying to go with Maven Cargo plugin instead of the Maven GlassFish plugin that doesn't support hot redeploy. Cargo hangs on goals start/run for GlassFish local existing installation and eats up to 100% CPU until I kill it! I tried with a plain text password and then created a password file, same result. Online searching turns up posts with various kinds of Cargo-GlassFish configuration, almost all of them older than the versions I'm using, and didn't help either.
Maven plugin config and debug log are attached. Any help is appreciated.
Environment: Mac OS X Mavericks, Oracle JDK 1.7.0_45, GlassFish-4.0-b89, Maven 3.1.1, cargo-maven2-plugin 1.4.5
Maven plugin config
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.5</version>
<configuration>
<container>
<containerId>glassfish4x</containerId>
<type>installed</type>
<output>${glassfish.installDirectory}/glassfish/domains/${glassfish.domainName}/logs/server.log</output>
<!-- Fail if not started/stopped within 30 sec -->
<timeout>30000</timeout>
</container>
<configuration>
<type>existing</type>
<home>${glassfish.installDirectory}/glassfish</home>
<properties>
<cargo.glassfish.domain.name>${glassfish.domainName}</cargo.glassfish.domain.name>
<cargo.remote.username>${glassfish.adminUser}</cargo.remote.username>
<cargo.remote.passwordFile>${glassfish.installDirectory}/admin.password</cargo.remote.passwordFile>
<!-- Maven sets java.home property to JRE but we want JDK -->
</properties>
</configuration>
<deployables>
<deployable>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<type>${project.packaging}</type>
<properties>
<context>/${project.artifactId}</context>
</properties>
</deployable>
</deployables>
</configuration>
</plugin>
Debug log
[DEBUG] [2.ContainerStartMojo] Resolved artifact and dependencies:file:/Users/Abhijit/Repositories/maven/org/codehaus/cargo/cargo-core-container-glassfish/1.4.5/cargo-core-container-glassfish-1.4.5.jar]
[INFO] [2.ContainerStartMojo] Resolved container artifact org.codehaus.cargo:cargo-core-container-glassfish:jar:1.4.5 for container glassfish4x
[DEBUG] Scheduling deployable for deployment: [groupId [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId [calculator-enc], type [war], location [null], pingURL [null]]
[DEBUG] Initial deployable values: groupId = [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId = [calculator-enc], type = [war], location = [null]
[DEBUG] Searching for an artifact that matches [name.abhijitsarkar.learning.webservices.jaxws.security:calculator-enc:war:null]...
[DEBUG] Checking artifact [name.abhijitsarkar.learning.webservices.jaxws.security:calculator-enc:war:null]...
[DEBUG] Computed deployable values: groupId = [name.abhijitsarkar.learning.webservices.jaxws.security], artifactId = [calculator-enc], classifier = [null], type = [war], location = [/Users/Abhijit/Repositories/git/java-ee/jaxws-security/calculator-enc/target/calculator-enc-0.0.1-SNAPSHOT.war]
[DEBUG] Setting deployable property [context]:[/calculator-enc] for [/Users/Abhijit/Repositories/git/java-ee/jaxws-security/calculator-enc/target/calculator-enc-0.0.1-SNAPSHOT.war]
[DEBUG] Invoking setter method public synchronized void org.codehaus.cargo.container.deployable.WAR.setContext(java.lang.String) for deployable org.codehaus.cargo.container.deployable.WAR[calculator-enc-0.0.1-SNAPSHOT.war] with argument /calculator-enc
[DEBUG] Setting container timeout to [30000]
For others who may come across this issue, it took me 2 days of debugging through Cargo src code to figure out the problem. The two <home> locations are actually both needed. The one under <container> should point to the GlassFish outer installation directory (that contains another glassfish directory inside) and the one under <configuration> should point to the glassfish/domains directory.
Has anyone ever mentioned to them that the naming convention is terrible? Why not call the later '<home>' <domainsDir> or something that actually means what it reads?

maven jetty plugin log4j configuration

i have a java web app with maven.
i'm using jetty to run it during development (by using maven jetty plugin)
i've my log4j.properties file placed under src/main/resources and it is copied under WEB-INF/classes when deployed as expected.
in my log4j.properties file i defined a filter variable and when deployed it is also filtered with the real value.
in log4j.properties under src/main/resources;
log4j.appender.FILE.File = ${config-gui.log-file}
in log4j.properties under WEB-INF/classes (after deployed with filtering);
log4j.appender.FILE.File = /tmp/mylogfile.log
my problem is; i'm getting following error when i run mvn jetty:run
log4j:ERROR setFile(null,true) call failed.<br />
java.io.FileNotFoundException: (No such file or directory)
at java.io.FileOutputStream.openAppend(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:177)
at java.io.FileOutputStream.<init>(FileOutputStream.java:102)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:289)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:163)
at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:215)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:256)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:132)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:96)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:654)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:612)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:509)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:415)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:441)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:122)
at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:88)
at com.pribas.bucherplayerconfiggui.util.LoggerUtil.getLogger(LoggerUtil.java:10)
at com.pribas.bucherplayerconfiggui.Initialization.<clinit>(Initialization.java:22)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:649)
at org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:630)
at org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:367)
at org.mortbay.jetty.plus.webapp.AbstractConfiguration.initWebXmlElement(AbstractConfiguration.java:190)
at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
at org.mortbay.jetty.plus.webapp.AbstractConfiguration.initialize(AbstractConfiguration.java:133)
at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
at org.mortbay.jetty.plus.webapp.AbstractConfiguration.configure(AbstractConfiguration.java:113)
at org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
at org.mortbay.jetty.plus.webapp.AbstractConfiguration.configureWebApp(AbstractConfiguration.java:96)
at org.mortbay.jetty.plus.webapp.Configuration.configureWebApp(Configuration.java:124)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:110)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.filesChanged(AbstractJettyRunMojo.java:409)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:493)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:359)
at org.mortbay.util.Scanner.scan(Scanner.java:286)
at org.mortbay.util.Scanner$1.run(Scanner.java:246)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
i think this error is because of it sees log4j.properties file which is under src/main/resources (which has appender's file param is not acceptable) instead of under WEB-INF/classes one.
i want maven jetty plugin to ignore log4j.properties file which is under src/main/resources and sees the one under WEB-INF/classes.
how can i do this?
or if this error is not related the idea i have, how can i solve this?
thx in advance.
I think, you can hardly guarantee which of log4j.properties will be used on in your jar or in WEB-INF/classes. It depends on concrete classloader implementation (in Tomcat or Jetty) which can either see WEB-INF/classes/log4j.properties or WEB-INF/libs/yourlib.jar:/log4j.properties. So you need to filter here or there :)
Using maven profiles you can configure the <excludes> for your resources and use this profile for to build web application for Tomcat deployment.
Maybe better solution will be renaming /src/main/resources/log4j.properties to /src/main/resources/log4j-jetty.properties and then configure Log4j via jetty plugin to use that resource:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
...
<systemProperties>
<systemProperty>
<name>log4j.configuration</name>
<value>log4j-jetty.properties</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>

Unable to deploy to Tomcat7 from cargo

I'm trying to deploy to a remote Tomcat7 with Cargo from Maven over https.
I've set up manager-script role and I've succeeded so far as to have been able to undeploy an app remotely.
What I have looks like this:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.2</version>
<configuration>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.uri>https://xxx/manager/text</cargo.remote.uri>
<cargo.remote.username>${tomcat.username}</cargo.remote.username>
<cargo.remote.password>${tomcat.password}</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<groupId>mycomp</groupId>
<artifactId>myartifact</artifactId>
<type>war</type>
<properties>
<context>/</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Well, I know the credentials and everything is setup correctly, and I have used the new /text interface and I have been able to undeploy an existing app. But when trying to run deploy:
mvn cargo:deployer-deploy -e
I get an error with root cause:
Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2809)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2792)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:605)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:569)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:101)
... 25 more
I get it quite immediately so it can't be a timeout.
Can the file be to large? It's a 60 MB war. I made sure my nginx allows bigger:
client_max_body_size 200M;
I also added multipart config to the text manager in the manager webapps web.xml like this:
servlet>
Manager
org.apache.catalina.manager.ManagerServlet
debug
2
<multipart-config>
<max-file-size>209715200</max-file-size>
<max-request-size>209715200</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
http://nexnet.wordpress.com/2011/04/27/large-war-file-cannot-be-deployed-in-tomcat-7/
I love Maven in many ways, but the error reporting is really terrible. Any help highly appreciated.
I was bitten by this error recently, when I tried to cargo:deploy an artifact. Usually we stop, clean and start the webapps directory before deploying, but this time I noticed that one artifact was not removed.
After switching to cargo:redeploy the error was solved.
I ran into this same error message when deploying to a tomcat 8 server using the ant deploy task. The issue in my case was that I was running out of space on the server. Checking tomcat's manager log is what clued me in:
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/abc_beta'
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /usr/share/apache-tomcat-8.0.9/webapps/abc_beta.war
10-Jul-2014 10:15:57.962 SEVERE [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: managerServlet.check[/abc_beta]
java.io.IOException: No space left on device
... stacktrace ...
I don't remember if or how I solved this, but as rascio has the same problem, I'll post a an idea. Maybe it's the wagon-extension for ssl that's needed:
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>2.2</version>
</extension>
</extensions>
Wild guess though. I think you didn't need it before Maven 3.0.
Another reason for this exception that we stumbled upon suddenly on monday, when deployment jobs on our Jenkins instance using the cargo plugin plugin stopped working. Not all of them, but some. The main difference was a a custom settings.xml in the jobs for a Nexus repository to download deployables from.
The successful deployment jobs had it configured like described in https://support.sonatype.com/entries/20943003-configure-maven-to-download-from-nexus, the failed ones were missing the repository and pluginRepository
I'm still not sure why the behavior changed at one point. Any tipps?

Resources