That is interesting, I added some notes to the ticket... - the extensions package jars using SNAPSHOT - the war includes geoserver jars using SNAPSHOT, and geotools jars using timestamp
We could experiment with setting <uniqueVersion>false</uniqueVersion> ? -- Jody Garnett On Wed, 4 Dec 2019 at 16:04, Imran Rajjad <raj...@gmail.com> wrote: > Hello, > In context of the issue described in > https://osgeo-org.atlassian.net/browse/GEOS-9407 , when building a > Geoserver release, Geotool jar files with timestamp( e.g > gt-main-22-20191203.210809-185) appear in the lib folder of war file. > > I have done some investigation to find the cause, apparently the pom files > are configured correctly > e.g > > <distributionManagement> > <repository> > <id>boundless</id> > <name>Boundless Release Repository</name> > <url>https://repo.boundlessgeo.com/release/</url> > <uniqueVersion>true</uniqueVersion> > </repository> > <snapshotRepository> > <id>boundless</id> > <uniqueVersion>true</uniqueVersion> > <name>Boundless Snapshot Repository</name> > <url>https://repo.boundlessgeo.com/snapshot/</url> > </snapshotRepository> > </distributionManagement> > > Building a release with maven logging set to debug did not yield much > information. Can it be confirmed that the last build had uniqueVersion set > to true, which might be the reason that when building a release maven ends > up with these timestamped jar files. Perhaps the Jenkins log can offer a > better clue. > > regards. > Imran > -- > I.R > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
