In poking around the 2.7-beta artifacts (war/jar) also appear to have 2.6.2 artifacts in them, and the build times are the same day ~ 30 minutes apart, so looks like something may have gone funky on the build/deploy.
(Ran into the issue with some integration tests failing - race condition depending on if the 2.7-beta or 2.6.2 jars load first on the classpath - https://github.com/ngageoint/geowave/pull/191 )
In poking around the 2.7-beta artifacts (war/jar) also appear to have 2.6.2 artifacts in them, and the build times are the same day ~ 30 minutes apart, so looks like something may have gone funky on the build/deploy.
(Ran into the issue with some integration tests failing - race condition depending on if the 2.7-beta or 2.6.2 jars load first on the classpath - https://github.com/ngageoint/geowave/pull/191 )
Thanks Chris, good (and quick) testing. I post the links to the devel email list here before running the final deploy to source forge. I did run the OS X build locally and did not have any issues.
So I guess we have two approaches, short list the bundles that are two big and I can manually remove the extra jars … or I can try another clean build run.
I am curious though, you are providing links to the repo - are you building a downstream app and grabbing these from maven? In which case only a clean build and deploy step will fix.
In poking around the 2.7-beta artifacts (war/jar) also appear to have 2.6.2 artifacts in them, and the build times are the same day ~ 30 minutes apart, so looks like something may have gone funky on the build/deploy.
(Ran into the issue with some integration tests failing - race condition depending on if the 2.7-beta or 2.6.2 jars load first on the classpath - https://github.com/ngageoint/geowave/pull/191 )
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
Either one of the options works for me (as long as whatever the underlying issue doesn’t repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
The reason we are pulling from the maven repo instead of sourceforgs is:
-Downstream app
We will eventually have some downstream RPM’s that build/bundle everything, but still getting some bits squared away - right now there are just some internal nightlies built automatically via jenkins, so those will resolve themselves. (probably will clean out the maven cache, though really the hash changes should pick that up)
Thanks Chris, good (and quick) testing. I post the links to the devel email list here before running the final deploy to source forge. I did run the OS X build locally and did not have any issues.
So I guess we have two approaches, short list the bundles that are two big and I can manually remove the extra jars … or I can try another clean build run.
I am curious though, you are providing links to the repo - are you building a downstream app and grabbing these from maven? In which case only a clean build and deploy step will fix.
In poking around the 2.7-beta artifacts (war/jar) also appear to have 2.6.2 artifacts in them, and the build times are the same day ~ 30 minutes apart, so looks like something may have gone funky on the build/deploy.
(Ran into the issue with some integration tests failing - race condition depending on if the 2.7-beta or 2.6.2 jars load first on the classpath - https://github.com/ngageoint/geowave/pull/191 )
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
Either one of the options works for me (as long as whatever the underlying
issue doesn't repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
Oh that is great, means I can just checkout the tag and run locally.
I expect we are only tripping up on these beta's since we trying to release
concurrently. I will check what directory they are working in - probably
need to ensure 2.7.x is working in its own play area ...
The reason we are pulling from the maven repo instead of sourceforgs is:
It probably covers more than the two that we have noted, but it’s more obvious in the gs-wps-core-2.6.2.jar as the security pieces (WpsAccessRule, DAO, etc.) didn’t exist previously. If you unzip the jar the class files the classes are there - so some 2.7 artifacs are getting mixed in. - ref: https://dl.dropboxusercontent.com/u/6649380/wps.png
For the overlapping class names I haven’t dug in to see which version is taking precedence. Might want to re-publish the 2.6.2 and 2.5.2 artifacts though - as those were just the two examples that whitney ran in to off the bat.
Either one of the options works for me (as long as whatever the underlying issue doesn’t repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
Oh that is great, means I can just checkout the tag and run locally.
I expect we are only tripping up on these beta’s since we trying to release concurrently. I will check what directory they are working in - probably need to ensure 2.7.x is working in its own play area …
The reason we are pulling from the maven repo instead of sourceforgs is:
It probably covers more than the two that we have noted, but it’s more obvious in the gs-wps-core-2.6.2.jar as the security pieces (WpsAccessRule, DAO, etc.) didn’t exist previously. If you unzip the jar the class files the classes are there - so some 2.7 artifacs are getting mixed in. - ref: https://dl.dropboxusercontent.com/u/6649380/wps.png
For the overlapping class names I haven’t dug in to see which version is taking precedence. Might want to re-publish the 2.6.2 and 2.5.2 artifacts though - as those were just the two examples that whitney ran in to off the bat.
Either one of the options works for me (as long as whatever the underlying issue doesn’t repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
Oh that is great, means I can just checkout the tag and run locally.
I expect we are only tripping up on these beta’s since we trying to release concurrently. I will check what directory they are working in - probably need to ensure 2.7.x is working in its own play area …
The reason we are pulling from the maven repo instead of sourceforgs is:
Was not able to deploy today, will try again on monday.
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
It probably covers more than the two that we have noted, but it’s more obvious in the gs-wps-core-2.6.2.jar as the security pieces (WpsAccessRule, DAO, etc.) didn’t exist previously. If you unzip the jar the class files the classes are there - so some 2.7 artifacs are getting mixed in. - ref: https://dl.dropboxusercontent.com/u/6649380/wps.png
For the overlapping class names I haven’t dug in to see which version is taking precedence. Might want to re-publish the 2.6.2 and 2.5.2 artifacts though - as those were just the two examples that whitney ran in to off the bat.
Either one of the options works for me (as long as whatever the underlying issue doesn’t repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
Oh that is great, means I can just checkout the tag and run locally.
I expect we are only tripping up on these beta’s since we trying to release concurrently. I will check what directory they are working in - probably need to ensure 2.7.x is working in its own play area …
The reason we are pulling from the maven repo instead of sourceforgs is:
It probably covers more than the two that we have noted, but it’s more obvious in the gs-wps-core-2.6.2.jar as the security pieces (WpsAccessRule, DAO, etc.) didn’t exist previously. If you unzip the jar the class files the classes are there - so some 2.7 artifacs are getting mixed in. - ref: https://dl.dropboxusercontent.com/u/6649380/wps.png
For the overlapping class names I haven’t dug in to see which version is taking precedence. Might want to re-publish the 2.6.2 and 2.5.2 artifacts though - as those were just the two examples that whitney ran in to off the bat.
Either one of the options works for me (as long as whatever the underlying issue doesn’t repeat itself)
(And yep, the sourceforge links are fine for the same artifacts)
Oh that is great, means I can just checkout the tag and run locally.
I expect we are only tripping up on these beta’s since we trying to release concurrently. I will check what directory they are working in - probably need to ensure 2.7.x is working in its own play area …
The reason we are pulling from the maven repo instead of sourceforgs is:
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
The rest looks to be good (just going by filesize real quick - the ones with duplicates appear to be around ~80MB, the rest ~60MB)
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
In poking around the 2.7-beta artifacts (war/jar) also appear to have 2.6.2 artifacts in them, and the build times are the same day ~ 30 minutes apart, so looks like something may have gone funky on the build/deploy.
(Ran into the issue with some integration tests failing - race condition depending on if the 2.7-beta or 2.6.2 jars load first on the classpath - https://github.com/ngageoint/geowave/pull/191 )
