I just pulled down the gs-web-app war artifact for the 2.5.2 release and noticed some commingling of 2.5.2 and 2.6-beta geoserver along with 11.2 and 12-beta geotools jars (and transient dependencies) in WEB-INF/lib. It appears that this artifact was packaged and deployed without running the maven “clean” first. I tried to dig into this and looked at the release job logs on http://ares.boundlessgeo.com/jenkins/
It looks as if jobs were run in this order:
2.5.2 was built with “geoserver-release” job in a directory (mvn clean install)
2.6-beta was built with “geoserver-release” job in same directory (mvn clean install)
2.5.2 was published with “geoserver-release-publish” job in same directory (mvn deploy)
This last job is problematic as “mvn deploy” also runs through the “package” phase and without a “clean” the build target directories can have files from prior builds (2.6-beta in this case)
I’ve only looked at the 2.5.2 gs-web-app war artifact and it’s tainted with 2.6-beta jars. There may be other published 2.5.2 release jar artifacts with issues.
Nice catch Tom! This is indeed an issue. If the jobs are intertwined like this it will definitely lead to problems.
The way the jobs are setup i am not sure simply doing a “clean deploy” would fix it because it would wipe out the assembly from the old jobs. A safer solution I think would be to create a sandbox by branch that the scripts run from. Will require some tweaks to the scripts but I believe is relatively straight forward.
I just pulled down the gs-web-app war artifact for the 2.5.2 release and noticed some commingling of 2.5.2 and 2.6-beta geoserver along with 11.2 and 12-beta geotools jars (and transient dependencies) in WEB-INF/lib. It appears that this artifact was packaged and deployed without running the maven “clean” first. I tried to dig into this and looked at the release job logs on http://ares.boundlessgeo.com/jenkins/
It looks as if jobs were run in this order:
2.5.2 was built with “geoserver-release” job in a directory (mvn clean install)
2.6-beta was built with “geoserver-release” job in same directory (mvn clean install)
2.5.2 was published with “geoserver-release-publish” job in same directory (mvn deploy)
This last job is problematic as “mvn deploy” also runs through the “package” phase and without a “clean” the build target directories can have files from prior builds (2.6-beta in this case)
I’ve only looked at the 2.5.2 gs-web-app war artifact and it’s tainted with 2.6-beta jars. There may be other published 2.5.2 release jar artifacts with issues.
Nice catch Tom! This is indeed an issue. If the jobs are intertwined like this it will definitely lead to problems.
The way the jobs are setup i am not sure simply doing a “clean deploy” would fix it because it would wipe out the assembly from the old jobs. A safer solution I think would be to create a sandbox by branch that the scripts run from. Will require some tweaks to the scripts but I believe is relatively straight forward.
I just pulled down the gs-web-app war artifact for the 2.5.2 release and noticed some commingling of 2.5.2 and 2.6-beta geoserver along with 11.2 and 12-beta geotools jars (and transient dependencies) in WEB-INF/lib. It appears that this artifact was packaged and deployed without running the maven “clean” first. I tried to dig into this and looked at the release job logs on http://ares.boundlessgeo.com/jenkins/
It looks as if jobs were run in this order:
2.5.2 was built with “geoserver-release” job in a directory (mvn clean install)
2.6-beta was built with “geoserver-release” job in same directory (mvn clean install)
2.5.2 was published with “geoserver-release-publish” job in same directory (mvn deploy)
This last job is problematic as “mvn deploy” also runs through the “package” phase and without a “clean” the build target directories can have files from prior builds (2.6-beta in this case)
I’ve only looked at the 2.5.2 gs-web-app war artifact and it’s tainted with 2.6-beta jars. There may be other published 2.5.2 release jar artifacts with issues.
I would appreciate clean artifacts. We use maven overlays for war injection and had wanted to upgrade to 2.5.2 to take advantage of some recent bug fixes.
Nice catch Tom! This is indeed an issue. If the jobs are intertwined like this it will definitely lead to problems.
The way the jobs are setup i am not sure simply doing a “clean deploy” would fix it because it would wipe out the assembly from the old jobs. A safer solution I think would be to create a sandbox by branch that the scripts run from. Will require some tweaks to the scripts but I believe is relatively straight forward.
I just pulled down the gs-web-app war artifact for the 2.5.2 release and noticed some commingling of 2.5.2 and 2.6-beta geoserver along with 11.2 and 12-beta geotools jars (and transient dependencies) in WEB-INF/lib. It appears that this artifact was packaged and deployed without running the maven “clean” first. I tried to dig into this and looked at the release job logs on http://ares.boundlessgeo.com/jenkins/
It looks as if jobs were run in this order:
2.5.2 was built with “geoserver-release” job in a directory (mvn clean install)
2.6-beta was built with “geoserver-release” job in same directory (mvn clean install)
2.5.2 was published with “geoserver-release-publish” job in same directory (mvn deploy)
This last job is problematic as “mvn deploy” also runs through the “package” phase and without a “clean” the build target directories can have files from prior builds (2.6-beta in this case)
I’ve only looked at the 2.5.2 gs-web-app war artifact and it’s tainted with 2.6-beta jars. There may be other published 2.5.2 release jar artifacts with issues.
