I this the same issue as reported with the 2.5.2 and 2.6-beta release?
http://jira.codehaus.org/browse/GEOS-6601
I like to use the war artifact as the basis for customization using maven
war overlays and this is problematic.
Tom
On Fri, Jan 23, 2015 at 7:57 PM, Jody Garnett <[email protected]>
wrote:
> Was not able to deploy today, will try again on monday.
>
> --
> Jody Garnett
>
> On 23 January 2015 at 13:57, Chris Bennight <[email protected]> wrote:
>
>> Might be a few other similar mixups - Whitney (the guy who discovered
>> this issue) also replied back to the thread on nabble (don't know if it
>> will make it to the list or not) noting that gs-wps-core-2.6.2.jar also has
>> some 2.7 classes in it. (his post:
>> http://osgeo-org.1560.x6.nabble.com/gs-web-app-2-6-2-war-jar-artifacts-contains-2-7-beta-artifacts-and-vice-versa-td5183266.html#a5183431
>> )
>>
>> 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.
>>
>>
>> On Fri, Jan 23, 2015 at 4:23 PM, Jody Garnett <[email protected]>
>> wrote:
>>
>>>
>>> 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:
>>>> - Automated integration testing against different versions of geoserver
>>>> (targeting N and N-1 support) on travis ( see build matrix @
>>>> https://github.com/ngageoint/geowave/blob/master/.travis.yml ) - and
>>>> specifically the integration testing part @ (
>>>> https://github.com/ngageoint/geowave/blob/master/geowave-test/pom.xml#L87
>>>> ) - basically using maven to pull down the correct war artifact per the
>>>> build matrix settings.
>>>>
>>>
>>> Yeah good stuff :)
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
* Tom Kunicki* | Software Engineer
*w:* 608 695 4251 *e:* [email protected]
------------------------------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
