-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
OS: Linux 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Java: java version "1.7.0_95", OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-0ubuntu0.14.04.1), OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
Jenkins: ver. 1.648
WildFly Deployer Plugin: org.jenkins-ci.plugins:wildfly-deployer:1.0.1
Log4j Implemented Over SLF4J: org.slf4j:log4j-over-slf4j:1.7.7
SLF4J API Module: org.slf4j:slf4j-api:1.7.7
WildFly: Command line interface: org.wildfly:wildfly-cli:8.2.1.FinalOS: Linux 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Java: java version "1.7.0_95", OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-0ubuntu0.14.04.1), OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode) Jenkins: ver. 1.648 WildFly Deployer Plugin: org.jenkins-ci.plugins:wildfly-deployer:1.0.1 Log4j Implemented Over SLF4J: org.slf4j:log4j-over-slf4j:1.7.7 SLF4J API Module: org.slf4j:slf4j-api:1.7.7 WildFly: Command line interface: org.wildfly:wildfly-cli:8.2.1.Final
My build configuration creates a war artifact in a subdirectory of the workspace root. As the description says (A single WAR or EAR file to deploy, packaged with the appropriate bindings (if applicable). Relative to the workspace root.), I enter a relative path (in my case: mcmod-server/build/libs/missioncontrol.war).
When I run a build, everything is fine. When I run it again, it failes, because Jenkins says "missioncontrol.war cannot be found" and that's correct, since it's in a subdirectory.
So I set the filepath again and successfully run the build. When I have a look at the configuration after the build, the filepath has been truncated to the filename. I can reproduce that after each build.