Re: [Geoserver-devel] [Geotools-devel] MVN repo.boundlessgeo having problems?

[Andrea Aime]

On Tue, Oct 27, 2015 at 10:03 AM, Ian Turton  wrote:

> OK I've reverted that PR but it builds on my machine so I assumed the
> travis fail was due to the repo issue, I'll check some more later.
>

Thanks!

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] MVN repo.boundlessgeo having problems?

[Ian Turton]

OK I've reverted that PR but it builds on my machine so I assumed the
travis fail was due to the repo issue, I'll check some more later.

Ian

On 26 October 2015 at 20:49, Andrea Aime 
wrote:

> On Mon, Oct 26, 2015 at 9:26 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> GeoTools ares build finished. The artifactory repo is working, but we are
>> getting build failures in 13.x and 14.x.
>> Looks like a test failure in Render for 13.x and a Documentation build
>> failure in 14.x.
>>
>
> The compile failure on 14.x might be Ian's recent backport of a fix on
> master:
> https://github.com/geotools/geotools/pull/1016
>
> The Travis build apparently already complained on the pull request, with
> the same error:
> https://travis-ci.org/geotools/geotools/builds/87485009
>
> The doc failure (warning being treated as failures) could be due to this
> Frank's commit (most recent commit on the file):
>
> https://github.com/geotools/geotools/commit/180b3f7ea00d6838a778f1390d60ada17a24362f
>
> I've cc'ed both of them
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>



-- 
Ian Turton
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-7279) Extend CSW DirectDownload link with support for vectorial stores

[Daniele Romagnoli (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Daniele Romagnoli created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7279 
 
 
 
  Extend CSW DirectDownload link with support for vectorial stores  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 CSW 
 
 
 

Created:
 

 27/Oct/15 11:57 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Daniele Romagnoli 
 
 
 
 
 
 
 
 
 
 
Add the support for vectorial data download 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA 

[Geoserver-devel] [JIRA] (GEOS-7277) W3DS capabilities do not take into account proxy url

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 François Van Der Biest created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7277 
 
 
 
  W3DS capabilities do not take into account proxy url  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 2.5.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 27/Oct/15 10:27 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 François Van Der Biest 
 
 
 
 
 
 
 
 
 
 
Although proxy base url is set, and WMS capabilities take it into account, the W3DS capabilities do not use it. Instead, one gets something like https://nsx.ovh.net:8443/geoserver/ows? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 

[Geoserver-devel] [JIRA] (GEOS-7278) W3DS demos use external ressources

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 François Van Der Biest created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7278 
 
 
 
  W3DS demos use external ressources  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 2.5.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 27/Oct/15 10:30 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 François Van Der Biest 
 
 
 
 
 
 
 
 
 
 
The W3DS previews (eg http://myserver.com/geoserver3D/geoserver3D/w3ds?version=0.4=w3ds=GetTile=text/html=0=0=0=EPSG:27492=geoserver3D:dem_tile_levels) load 2 external ressources from 3dwebgis.di.uminho.pt : 
http://3dwebgis.di.uminho.pt/geoserver3D/x3dom/x3dom.css http://3dwebgis.di.uminho.pt/geoserver3D/x3dom/x3dom.js 
Instead, these files should be served locally. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
  

Re: [Geoserver-devel] Resources port

[Niels Charlier]

Jody,

Small addition. With respect to point (1), I know about 
GeoServerResourceLoader.lookupGeoServerDataDirectory(servletContext), 
but then we are bypassing the ResourceStore API and missing some of its 
generic purpose. The point is if we're making a GeoServerResourceLoader 
from a ResourceStore, should it not take the baseDirectory from it somehow.


Niels

On 27-10-15 14:21, Niels Charlier wrote:

Hello Jody,

Thanks for your email! That clarifies at least which direction we 
should be going with some of these issues. A few remaining important 
points:


1. Can you fill me in on a way to get the path to the DataDirectory 
without calling dir() ? I'll have to make a patch for that then, but I 
really did not see a way to do that in the current API, if you are 
working with a ResourceStore. See the constructor 
GeoServerResourceLoader(ResourceStore resourceStore). We'll have to 
change the resourcestore API to make this possible, no?


2. The problem with the GEOSERVER_DATA_DIRECTORY/data directory, or 
any other raster/vector data is slightly more complicated than you think.
 * The REST api uploads both configuration files as well as data 
files, and it uses the same methods for both. I converted the whole 
module to use resources instead of files. This results (for now) in 
data files being uploaded to the database and then cached when the 
store is created.
 * The distinction is not always simple to make, app-schema has 
configuration files (usually located in the workspaces dir) that are 
threated by geoserver in the same way as data files and they are read 
by geotools.


Is there a reason why using the database to store and distribute the 
data files is not recommended, is it a matter performance/space?


Otherwise, indeed I would recommend allowing the user specify in the 
jdbcstore configuration file which dirs to ignore. The jdbcstore would 
ignore with import as well as return a filebasedresource when these 
folders are being queried. Does that sound good?


3. I like the idea of deleting the data directory after import. But 
then point (1) _absolutely_ needs to be resolved, because otherwise 
the data directory will immediately be cached completely, repeatedly.


4. In my opinion, dir() should _always_ be avoided. I would recommend 
using resources as much as possible and as long as possible and only 
cache when absolutely necessary (usually a 3rd party lib), which means 
ery dir() is rarely necessary but file() is sufficient. The issue with 
the usage of dir() is that it could encourage people to use the file 
system directly, forgetting that changes to the file system have no 
lasting effect when using the jdbcstore!


Kind Regards
Niels


On 26-10-15 22:28, Jody Garnett wrote:
Thanks Niels, some comments inline, assume this is for GSIP-132 
 (unless that 
is completed already).


On 7 October 2015 at 05:28, Niels Charlier > wrote:


Hi Jody, Gabriel, Kevin

I have been  porting all modules to use the resources system
consistently and only use files when necessary (usually external
library). I still stumbled upon two minor questions/issues I
wanted to discuss.

1. Usage of the "data" directory. At the moment the import from
data directory -> jdbc store ignores the "data" directory. In a
clustered environment, this directory thus remains instance
specific, and it would be up to the user to refer to shared files.


Are you talking about GEOSERVER_DATA_DIRECTORY/data? If so that is 
only a convention, I have made data directories that used "raster" 
and "vector" folders for example.


For storing spatial data (GeoTIFF, Shapefile, Image Mosaic here) I 
had the idea of doing something like JNDI but for referencing an 
external folder used for this purpose. This could both provide an 
"ignore" list (so "data" was not hard coded) and allow for a cluster 
with RAID storage mapped to a specific mount.


At this moment, there is no reason why we couldn't include the
data dir in the jdbcstore and cache it before loading the
geotools datastore. This is actually what my modified version of
the rest service already does because it uses resources everywhere. 



For configuration files this is what we want.

Another idea, was to program the jdbcstore to return file based
resources only when the "data" directory is used, so that it
definitely will never store those files in the database
unnecessarily.


Okay pretty sure you are talking about GEOSERVER_DATA_DIRECTORY/data now.

Q: Is it worth removing the files that have been imported into 
JDBCConfig from GEOSERVER_DATA_DIRECTORY? This would prevent 
confusion, and allow GEOSERVER_DATA_DIRECTORY to work strictly as a 
cache (for the few things that require a file to be unpacked on to disk).


2. In the jdbcstore, should the children of a directory be cached
when dir() is called?

Re: [Geoserver-devel] Resources port

[Niels Charlier]

Hello Jody,

Thanks for your email! That clarifies at least which direction we should 
be going with some of these issues. A few remaining important points:


1. Can you fill me in on a way to get the path to the DataDirectory 
without calling dir() ? I'll have to make a patch for that then, but I 
really did not see a way to do that in the current API, if you are 
working with a ResourceStore. See the constructor 
GeoServerResourceLoader(ResourceStore resourceStore). We'll have to 
change the resourcestore API to make this possible, no?


2. The problem with the GEOSERVER_DATA_DIRECTORY/data directory, or any 
other raster/vector data is slightly more complicated than you think.
 * The REST api uploads both configuration files as well as data files, 
and it uses the same methods for both. I converted the whole module to 
use resources instead of files. This results (for now) in data files 
being uploaded to the database and then cached when the store is created.
 * The distinction is not always simple to make, app-schema has 
configuration files (usually located in the workspaces dir) that are 
threated by geoserver in the same way as data files and they are read by 
geotools.


Is there a reason why using the database to store and distribute the 
data files is not recommended, is it a matter performance/space?


Otherwise, indeed I would recommend allowing the user specify in the 
jdbcstore configuration file which dirs to ignore. The jdbcstore would 
ignore with import as well as return a filebasedresource when these 
folders are being queried. Does that sound good?


3. I like the idea of deleting the data directory after import. But then 
point (1) _absolutely_ needs to be resolved, because otherwise the data 
directory will immediately be cached completely, repeatedly.


4. In my opinion, dir() should _always_ be avoided. I would recommend 
using resources as much as possible and as long as possible and only 
cache when absolutely necessary (usually a 3rd party lib), which means 
ery dir() is rarely necessary but file() is sufficient. The issue with 
the usage of dir() is that it could encourage people to use the file 
system directly, forgetting that changes to the file system have no 
lasting effect when using the jdbcstore!


Kind Regards
Niels


On 26-10-15 22:28, Jody Garnett wrote:
Thanks Niels, some comments inline, assume this is for GSIP-132 
 (unless that is 
completed already).


On 7 October 2015 at 05:28, Niels Charlier > wrote:


Hi Jody, Gabriel, Kevin

I have been  porting all modules to use the resources system
consistently and only use files when necessary (usually external
library). I still stumbled upon two minor questions/issues I
wanted to discuss.

1. Usage of the "data" directory. At the moment the import from
data directory -> jdbc store ignores the "data" directory. In a
clustered environment, this directory thus remains instance
specific, and it would be up to the user to refer to shared files.


Are you talking about GEOSERVER_DATA_DIRECTORY/data? If so that is 
only a convention, I have made data directories that used "raster" and 
"vector" folders for example.


For storing spatial data (GeoTIFF, Shapefile, Image Mosaic here) I had 
the idea of doing something like JNDI but for referencing an external 
folder used for this purpose. This could both provide an "ignore" list 
(so "data" was not hard coded) and allow for a cluster with RAID 
storage mapped to a specific mount.


At this moment, there is no reason why we couldn't include the
data dir in the jdbcstore and cache it before loading the geotools
datastore. This is actually what my modified version of the rest
service already does because it uses resources everywhere. 



For configuration files this is what we want.

Another idea, was to program the jdbcstore to return file based
resources only when the "data" directory is used, so that it
definitely will never store those files in the database unnecessarily.


Okay pretty sure you are talking about GEOSERVER_DATA_DIRECTORY/data now.

Q: Is it worth removing the files that have been imported into 
JDBCConfig from GEOSERVER_DATA_DIRECTORY? This would prevent 
confusion, and allow GEOSERVER_DATA_DIRECTORY to work strictly as a 
cache (for the few things that require a file to be unpacked on to disk).


2. In the jdbcstore, should the children of a directory be cached
when dir() is called?


Cached is on import (so yes). Should the resources be unpacked 
(staged) to the file system when dir() is called? Yes


The DataDirectory class uses the dir() method to know the root of
the data directory, causing the whole data directory to be cached
at once multiple times unnecessarily, since the root dir is
usually requested just to know the path for some reason (all code
where it actually 

[Geoserver-devel] [JIRA] (GEOS-7280) Avoid catalog linear scans in GWC integration listeners

[Andrea Aime [Administrator] (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrea Aime [Administrator] created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7280 
 
 
 
  Avoid catalog linear scans in GWC integration listeners  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 GWC, JDBCConfig 
 
 
 

Created:
 

 27/Oct/15 12:49 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Andrea Aime [Administrator] 
 
 
 
 
 
 
 
 
 
 
The current GWC integration code, along with jdbcconfig, forces a full catalog load from database every time a style is changed, and loads way more than necessary for layer changes (all groups, which results in all their layers being load).  Use catalog.list with proper filters to limit data loading instead. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 

Re: [Geoserver-devel] Jetty upgrade?

[Andrea Aime]

On Tue, Oct 27, 2015 at 5:15 PM, Jody Garnett 
wrote:

> So review completed, merge when ready. Unless anyone else wants a crack at
> it ...


I'd say... merge :-p

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] LayergroupInfo changes

[Niels Charlier]

Hi,

I want to propose some minor API changes for the catalog, will make a 
proper proposal but just wanted to check already if I can expect this to 
be an issue or not.

1. Move property [AttributionInfo attribution] from LayerInfo to 
PublishedInfo, so that Layergroups can have this as well.

2. Add [List metadataLinks] to LayerGroupInfo so that 
a LayerGroupInfo can have its own metadatalink (for layer, this is 
actually in ResourceInfo).

Regards
Niels

--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Jetty upgrade?

[Jason Newmoyer]

We are running GeoServer 2.7.2 on Jetty 9.2 and Java 8 in a production
capacity, so far without issue (RHEL 6.6).

Just thought I'd throw that in there.


Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
ja...@newmoyergeospatial.com



On Mon, Oct 26, 2015 at 3:14 PM, Justin Deoliveira 
wrote:

> I did, as it was there before. So I just updated the copy. That said we
> could probably change that and depend on it as a maven artifact. That is
> what the mac installer does. It just requires we make some updates to the
> assembly scripts. If you feel strongly about that I suggest we open up a
> separate jira for that.
>
>
>
> On Mon, Oct 26, 2015 at 1:07 PM, Jody Garnett 
> wrote:
>
>> Thanks Justin, quick review left me with one question. Not sure if you
>> intended to commit src/release/jetty/start.jar as a binary file.
>>
>> --
>> Jody Garnett
>>
>> On 26 October 2015 at 11:23, Justin Deoliveira 
>> wrote:
>>
>>> Hey folks,
>>>
>>> Pull request ready.
>>>
>>>   https://github.com/geoserver/geoserver/pull/1301
>>>
>>> I’ve updated and tested the mac/win/bin installers. Also took the war
>>> for a spin just for the sake of it and no issues there.
>>>
>>> -Justin
>>>
>>>
>>> On Sun, Oct 25, 2015 at 4:54 PM, Justin Deoliveira 
>>> wrote:
>>>
 Thanks Jody. Nope, I’m not blocked on anything, as soon as I verify
 that there are no issues with the other release artifacts I’ll submit the
 pull request for review.

 I decided not to make this change contingent on the java 8 upgrade.
 Although once the upgrade happens if we want to jump to jetty 9.3 that
 should be trivial because as far as I can see there aren’t any api changes
 going from 9.2 to 9.3.

 On Sun, Oct 25, 2015 at 4:51 PM, Jody Garnett 
 wrote:

> Thanks Justin, epic work pulling all the threads together.
>
> I need to catch up on what is needed where - can I confirm your work
> is not blocked on anything?
> On Sun, Oct 25, 2015 at 3:40 PM Justin Deoliveira 
> wrote:
>
>> Great, thanks for the info guys. Good to know Jukka has had success.
>> At the moment I’ve been working on updating the build time dependency,
>> since as you know we have a bunch of test scoped dependencies on jetty, 
>> and
>> we depend on it to build the release artifacts.
>>
>> The first hitch I hit was the servlet-api dependency. Jetty 9.x
>> requires the 3.1 version of the dependency. So my first inclination was 
>> to
>> upgrade everything to use that version, but unfortunately that doesn’t 
>> look
>> all that easy. The issue is the mockrunner library we use for tests, it
>> requires the 2.5. I looked for a newer version that implemented the 3.1
>> version and allI found was an open github ticket from last year. I think
>> the best long term solution here is to ditch mockrunner and use the mock
>> http classes from spring. Unfortunately that is a bit of a bigger job.
>> Possibly something to be tackled during a code sprint with many hands on
>> deck.
>>
>> So for now I’ve decided to keep the dependency at 2.4 and instead
>> just update the test scope dependency from web/app that is used in the 
>> test
>> runner. That works, however it required use to use “provided” scope for 
>> the
>> upstream modules that depend on servlet-api. Which actually is what is
>> recommended for maven projects with that dependency.
>>
>> Here is the upgrade patch:
>>
>>
>> https://github.com/geoserver/geoserver/compare/master...jdeolive:jetty-upgrade
>>
>> I’ve run all the unit tests for core modules, extensions, and
>> community release modules. No issues there. I’ve also tested that the bin
>> artifact runs without an issue. Haven’t yet verified any of the other
>> artifacts. I was going to verify no issues with the other artifacts and
>> then probably call this one good to go unless anyone has any concerns.
>>
>> Thanks!
>>
>> -Justin
>>
>>
>> On Sun, Oct 25, 2015 at 3:26 AM, Rahkonen Jukka (MML) <
>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I made a test and I could run Geoserver 2.8 on Jetty 9.3.3 on
>>> Windows.
>>>
>>>
>>> http://osgeo-org.1560.x6.nabble.com/Re-Geoserver-devel-changing-data-directory-using-geoserver-war-with-jetty-td5230039.html
>>>
>>>
>>>
>>> I also asked in another mail about how could I help with updating
>>> the Jetty version that we ship with Geoserver.  I can have a try with
>>> making the startup.bat to work with the new Jetty but I can’t help with
>>> making the .exe installer etc. I am willing to test when someone makes 
>>> such
>>> installer.
>>>
>>>
>>>
>>> 

Re: [Geoserver-devel] Jetty upgrade?

[Jody Garnett]

So review completed, merge when ready. Unless anyone else wants a crack at
it ...
On Tue, Oct 27, 2015 at 9:12 AM Jason Newmoyer 
wrote:

> We are running GeoServer 2.7.2 on Jetty 9.2 and Java 8 in a production
> capacity, so far without issue (RHEL 6.6).
>
> Just thought I'd throw that in there.
>
>
> Jason Newmoyer
> Newmoyer Geospatial Solutions
> 843.606.0424
> ja...@newmoyergeospatial.com
>
>
>
> On Mon, Oct 26, 2015 at 3:14 PM, Justin Deoliveira 
> wrote:
>
>> I did, as it was there before. So I just updated the copy. That said we
>> could probably change that and depend on it as a maven artifact. That is
>> what the mac installer does. It just requires we make some updates to the
>> assembly scripts. If you feel strongly about that I suggest we open up a
>> separate jira for that.
>>
>>
>>
>> On Mon, Oct 26, 2015 at 1:07 PM, Jody Garnett 
>> wrote:
>>
>>> Thanks Justin, quick review left me with one question. Not sure if you
>>> intended to commit src/release/jetty/start.jar as a binary file.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 26 October 2015 at 11:23, Justin Deoliveira 
>>> wrote:
>>>
 Hey folks,

 Pull request ready.

   https://github.com/geoserver/geoserver/pull/1301

 I’ve updated and tested the mac/win/bin installers. Also took the war
 for a spin just for the sake of it and no issues there.

 -Justin


 On Sun, Oct 25, 2015 at 4:54 PM, Justin Deoliveira 
 wrote:

> Thanks Jody. Nope, I’m not blocked on anything, as soon as I verify
> that there are no issues with the other release artifacts I’ll submit the
> pull request for review.
>
> I decided not to make this change contingent on the java 8 upgrade.
> Although once the upgrade happens if we want to jump to jetty 9.3 that
> should be trivial because as far as I can see there aren’t any api changes
> going from 9.2 to 9.3.
>
> On Sun, Oct 25, 2015 at 4:51 PM, Jody Garnett 
> wrote:
>
>> Thanks Justin, epic work pulling all the threads together.
>>
>> I need to catch up on what is needed where - can I confirm your work
>> is not blocked on anything?
>> On Sun, Oct 25, 2015 at 3:40 PM Justin Deoliveira 
>> wrote:
>>
>>> Great, thanks for the info guys. Good to know Jukka has had success.
>>> At the moment I’ve been working on updating the build time dependency,
>>> since as you know we have a bunch of test scoped dependencies on jetty, 
>>> and
>>> we depend on it to build the release artifacts.
>>>
>>> The first hitch I hit was the servlet-api dependency. Jetty 9.x
>>> requires the 3.1 version of the dependency. So my first inclination was 
>>> to
>>> upgrade everything to use that version, but unfortunately that doesn’t 
>>> look
>>> all that easy. The issue is the mockrunner library we use for tests, it
>>> requires the 2.5. I looked for a newer version that implemented the 3.1
>>> version and allI found was an open github ticket from last year. I think
>>> the best long term solution here is to ditch mockrunner and use the mock
>>> http classes from spring. Unfortunately that is a bit of a bigger job.
>>> Possibly something to be tackled during a code sprint with many hands on
>>> deck.
>>>
>>> So for now I’ve decided to keep the dependency at 2.4 and instead
>>> just update the test scope dependency from web/app that is used in the 
>>> test
>>> runner. That works, however it required use to use “provided” scope for 
>>> the
>>> upstream modules that depend on servlet-api. Which actually is what is
>>> recommended for maven projects with that dependency.
>>>
>>> Here is the upgrade patch:
>>>
>>>
>>> https://github.com/geoserver/geoserver/compare/master...jdeolive:jetty-upgrade
>>>
>>> I’ve run all the unit tests for core modules, extensions, and
>>> community release modules. No issues there. I’ve also tested that the 
>>> bin
>>> artifact runs without an issue. Haven’t yet verified any of the other
>>> artifacts. I was going to verify no issues with the other artifacts and
>>> then probably call this one good to go unless anyone has any concerns.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>>
>>> On Sun, Oct 25, 2015 at 3:26 AM, Rahkonen Jukka (MML) <
>>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>>
 Hi,



 I made a test and I could run Geoserver 2.8 on Jetty 9.3.3 on
 Windows.


 http://osgeo-org.1560.x6.nabble.com/Re-Geoserver-devel-changing-data-directory-using-geoserver-war-with-jetty-td5230039.html



 I also asked in another mail about how could I help 

Re: [Geoserver-devel] Jetty upgrade?

[Justin Deoliveira]

Thanks for the review guys. Pull request merged. I’ll keep an eye out for
any unexpected issues that pop up.

On Tue, Oct 27, 2015 at 10:21 AM, Andrea Aime 
wrote:

> On Tue, Oct 27, 2015 at 5:15 PM, Jody Garnett 
> wrote:
>
>> So review completed, merge when ready. Unless anyone else wants a crack
>> at it ...
>
>
> I'd say... merge :-p
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] LayergroupInfo changes

[Andrea Aime]

On Tue, Oct 27, 2015 at 6:53 PM, Jody Garnett 
wrote:

> Good point Andrea, I wonder if it is worth making seperate pages for the
> different kinds of layer group? Some of these options only make sense when
> the layer group is named (and thus drawable) for example.
>

I was more thinking of having three tabs regardless of the type:
* The first one with the editing of the group structure and bbox (type
choice goes here)
* The second one for metadata links, attribution and whatnot (title,
abstract, metadati-sh stuff)
* The third one for caching

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: cite-wms-1.1 #736

[monitor]

See 

--
[...truncated 9068 lines...]
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 

[Geoserver-devel] Build failed in Jenkins: cite-wcs-1.1 #736

[monitor]

See 

--
[...truncated 1313 lines...]

all:

build.script:

build.script:

data:

webapp.scripts:
[mkdir] Created dir: 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 20 files to 

 [copy] Copying 3 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 17 files to 

 [copy] Copying 5 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 60 files to 

 [copy] Copying 2 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 18 files to 

 [copy] Copying 6 files to 

[mkdir] Created dir: 

 [copy] Copying 12 files to 


webapp.script:
[mkdir] Created dir: 

 [copy] Copying 38 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 69 files to 

 [copy] Copying 3 files to 

[mkdir] Created 

Re: [Geoserver-devel] LayergroupInfo changes

[Jody Garnett]

Yeah okay I like that.

I had a proposal a while back to organize our pages with consistent
headings (like GetCapabilities for all the title, abstract, metadataish
stuff).

For now I would follow what is done for a layer - or at least use the same
tab tiles for consistency.

--
Jody Garnett

On 27 October 2015 at 10:57, Andrea Aime 
wrote:

> On Tue, Oct 27, 2015 at 6:53 PM, Jody Garnett 
> wrote:
>
>> Good point Andrea, I wonder if it is worth making seperate pages for the
>> different kinds of layer group? Some of these options only make sense when
>> the layer group is named (and thus drawable) for example.
>>
>
> I was more thinking of having three tabs regardless of the type:
> * The first one with the editing of the group structure and bbox (type
> choice goes here)
> * The second one for metadata links, attribution and whatnot (title,
> abstract, metadati-sh stuff)
> * The third one for caching
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: cite-wcs-1.0 #737

[monitor]

See 

--
[...truncated 1385 lines...]
war:
  [zip] Building zip: 


jar.realm:

compile:
[mkdir] Created dir: 

[javac] 
:13:
 warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to 

warning: [options] bootstrap class path not set in conjunction with -source 1.6
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
 [copy] Copying 1 file to 


jar:
  [jar] Building jar: 


zip.manager.bin:
   [delete] Deleting directory 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 2 files to 

  [zip] Building zip: 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cite ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 

[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ cite 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ cite ---
[INFO] No tests to run.
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ cite ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ cite ---
[INFO] Installing 
 
to /var/lib/jenkins/.m2/repository/org/geoserver/cite/1.0/cite-1.0.jar
[INFO] Installing 
 to 
/var/lib/jenkins/.m2/repository/org/geoserver/cite/1.0/cite-1.0.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 34.969s
[INFO] Finished at: Tue Oct 27 18:27:59 UTC 2015
[INFO] Final Memory: 22M/179M
[INFO] 
+ ant clean
Buildfile: 

clean:

BUILD SUCCESSFUL
Total time: 0 seconds
+ pushd ..
~/workspace/geoserver-cite ~/workspace/geoserver-cite/tools 
~/workspace/geoserver-cite
++ pwd
+ FORMS=
+ popd
~/workspace/geoserver-cite/tools ~/workspace/geoserver-cite
+ ant -Dcite.headless=true 
-Dcite.headless.formroot=
 wcs-1.0
Buildfile: 

wcs-1.0:

run-test:
 [exec] Oct 27, 2015 6:28:02 PM com.occamlab.te.Generator generateXsl
 [exec] INFO: Validating 

 [exec] Oct 27, 2015 6:28:02 PM com.occamlab.te.Generator generateXsl
 [exec] INFO: Validating 

 [exec] Oct 

[Geoserver-devel] Build failed in Jenkins: cite-wms-1.3 #733

[monitor]

See 

--
[...truncated 1322 lines...]
[mkdir] Created dir: 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 20 files to 

 [copy] Copying 3 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 17 files to 

 [copy] Copying 5 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 60 files to 

 [copy] Copying 2 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 18 files to 

 [copy] Copying 6 files to 

[mkdir] Created dir: 

 [copy] Copying 12 files to 


webapp.script:
[mkdir] Created dir: 

 [copy] Copying 38 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 69 files to 

 [copy] Copying 3 files to 

[mkdir] Created dir: 

Re: [Geoserver-devel] Forwarding authentication headers to cascaded WFS store

[Jody Garnett]

Hey Jason, this question may be more suitable to the user list (the devel
list is focused on working on the geoserver codebase itself). It is a bit
tough to ask for public feedback on your custom data sources - perhaps you
would like to check the support page  for a
vendor in your neck of the woods?

For the specific functionality you are looking at you will want to dive
deep on the GeoTools codebase for WFSDataStore and WebMapServer client.
They are fairly extensible, and I have seen the used with a federated
security model as past of a OGC testbed (this involved passing security
details through as part of a cascade).

On Thu, Oct 22, 2015 at 9:28 AM Jason Newmoyer 
wrote:

> GeoServer Devs,
>
> We run a reverse proxy in front of GeoServer to handle authentication via
> Windows Integrated Auth. We also expose some of our custom data sources via
> hand-rolled WFS interfaces, which also require authentication using said
> proxy.
>
> If I want to expose some of these custom data sources to GeoServer's WMS
> via Cascaded WFS, would GeoServer automatically forward authentication
> headers from the client through the WMS and out to the WFS backend request?
>
> If not, would you recommend a way to implement that?
>
> Thanks!
>
> Jason Newmoyer
> Newmoyer Geospatial Solutions
> 843.606.0424
> ja...@newmoyergeospatial.com
>
>
>
> --
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] LayergroupInfo changes

[Andrea Aime]

On Tue, Oct 27, 2015 at 5:32 PM, Niels Charlier  wrote:

> Hi,
>
> I want to propose some minor API changes for the catalog, will make a
> proper proposal but just wanted to check already if I can expect this to
> be an issue or not.
>
> 1. Move property [AttributionInfo attribution] from LayerInfo to
> PublishedInfo, so that Layergroups can have this as well.
>
> 2. Add [List metadataLinks] to LayerGroupInfo so that
> a LayerGroupInfo can have its own metadatalink (for layer, this is
> actually in ResourceInfo).
>

No particular objections, but a couple of observations:
* What if the group is published as tree or named mode, are these going to
make
  sense regardless? I guess so... but by spec they will be inhrerited by
all sub-layers.
  I guess it will be up to the admin to decide if this makes sense or not
* The layer group UI is starting to become pretty crowded, breaking it up
in tabs
  like the layer one would probably be good

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: geoserver-master #1919

[monitor]

See 

Changes:

[jdeolive] GEOS-4239, upgrading jetty to version 9.2.

[jdeolive] GEOS-4239, updating assembly to accommodate jetty upgrade.

[jdeolive] Locking down slf4j to 1.7.10

[jdeolive] GEOS-4329, updated mac installer for jetty upgrade.

[jdeolive] GEOS-4329, updated win installer for jetty upgrade.

--
[...truncated 11611 lines...]
[INFO] [GitCommitIdMojo] 
-
[INFO] [GitCommitIdMojo] Finished running.
[INFO] 
[INFO] <<< maven-source-plugin:2.2.1:jar (attach-sources) @ gs-web-wcs2_0-eo <<<
[INFO] 
[INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @ gs-web-wcs2_0-eo ---
[INFO] Building jar: 

[INFO] 
[INFO] >>> maven-source-plugin:2.2.1:test-jar (attach-sources) @ 
gs-web-wcs2_0-eo >>>
[INFO] 
[INFO] --- git-commit-id-plugin:2.0.4:revision (default) @ gs-web-wcs2_0-eo ---
[INFO] [GitCommitIdMojo] Running on 
' repository...
[INFO] [GitCommitIdMojo] Initializing properties...
[INFO] [GitCommitIdMojo] Using maven project properties...
[INFO] [GitCommitIdMojo] Loading data from git repository...
[INFO] [GitCommitIdMojo] --git properties 
loaded--
[INFO] [GitCommitIdMojo] build.commit.message.short = Merge pull request #1301 
from jdeolive/jetty-upgrade
[INFO] [GitCommitIdMojo] build.build.user.email = Unknown
[INFO] [GitCommitIdMojo] build.hudsonId = -1
[INFO] [GitCommitIdMojo] build.commit.time = 27.10.2015 @ 17:04:39 UTC
[INFO] [GitCommitIdMojo] build.timestamp = 27-Oct-2015 17:07
[INFO] [GitCommitIdMojo] build.build.time = 27.10.2015 @ 17:22:38 UTC
[INFO] [GitCommitIdMojo] build.branch = 30f8c8a987c98e6952cf2d3cafe507ebbfe153b9
[INFO] [GitCommitIdMojo] build.commit.user.email = jdeol...@gmail.com
[INFO] [GitCommitIdMojo] build.build.user.name = Unknown
[INFO] [GitCommitIdMojo] build.commit.user.name = Justin Deoliveira
[INFO] [GitCommitIdMojo] build.commit.id.abbrev = 30f8c8a
[INFO] [GitCommitIdMojo] build.commit.id = 
30f8c8a987c98e6952cf2d3cafe507ebbfe153b9
[INFO] [GitCommitIdMojo] build.commit.message.full = Merge pull request #1301 
from jdeolive/jetty-upgrade

Upgrade jetty to version 9.2 [GEOS-4239]
[INFO] [GitCommitIdMojo] 
-
[INFO] [GitCommitIdMojo] Finished running.
[INFO] 
[INFO] <<< maven-source-plugin:2.2.1:test-jar (attach-sources) @ 
gs-web-wcs2_0-eo <<<
[INFO] 
[INFO] --- maven-source-plugin:2.2.1:test-jar (attach-sources) @ 
gs-web-wcs2_0-eo ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
gs-web-wcs2_0-eo ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/geoserver/extension/gs-web-wcs2_0-eo/2.9-SNAPSHOT/gs-web-wcs2_0-eo-2.9-SNAPSHOT.jar
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/geoserver/extension/gs-web-wcs2_0-eo/2.9-SNAPSHOT/gs-web-wcs2_0-eo-2.9-SNAPSHOT.pom
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/geoserver/extension/gs-web-wcs2_0-eo/2.9-SNAPSHOT/gs-web-wcs2_0-eo-2.9-SNAPSHOT-tests.jar
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/geoserver/extension/gs-web-wcs2_0-eo/2.9-SNAPSHOT/gs-web-wcs2_0-eo-2.9-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/geoserver/extension/gs-web-wcs2_0-eo/2.9-SNAPSHOT/gs-web-wcs2_0-eo-2.9-SNAPSHOT-test-sources.jar
GeneralEnvelope[(40.0, 10.0), (70.0, 55.0)]
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.826 sec
Running org.geoserver.wcs2_0.WCSNetCDFTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.025 sec
Running org.geoserver.web.netcdf.NetCDFOutSettingsPanelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.131 sec
Running org.geoserver.web.netcdf.layer.NetCDFOutTabPanelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.699 sec

Results :

Tests run: 14, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- 

Re: [Geoserver-devel] LayergroupInfo changes

[Jody Garnett]

There is an outstanding proposal that Kevin was putting together - that may
be related.

* https://github.com/geoserver/geoserver/wiki/GSIP-130

--
Jody Garnett

On 27 October 2015 at 09:32, Niels Charlier  wrote:

> Hi,
>
> I want to propose some minor API changes for the catalog, will make a
> proper proposal but just wanted to check already if I can expect this to
> be an issue or not.
>
> 1. Move property [AttributionInfo attribution] from LayerInfo to
> PublishedInfo, so that Layergroups can have this as well.
>
> 2. Add [List metadataLinks] to LayerGroupInfo so that
> a LayerGroupInfo can have its own metadatalink (for layer, this is
> actually in ResourceInfo).
>
> Regards
> Niels
>
>
> --
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: cite-wfs-1.0 #739

[monitor]

See 

--
[...truncated 3244 lines...]
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 

Re: [Geoserver-devel] LayergroupInfo changes

[Jody Garnett]

Good point Andrea, I wonder if it is worth making seperate pages for the
different kinds of layer group? Some of these options only make sense when
the layer group is named (and thus drawable) for example.

--
Jody Garnett

On 27 October 2015 at 10:44, Andrea Aime 
wrote:

> On Tue, Oct 27, 2015 at 5:32 PM, Niels Charlier  wrote:
>
>> Hi,
>>
>> I want to propose some minor API changes for the catalog, will make a
>> proper proposal but just wanted to check already if I can expect this to
>> be an issue or not.
>>
>> 1. Move property [AttributionInfo attribution] from LayerInfo to
>> PublishedInfo, so that Layergroups can have this as well.
>>
>> 2. Add [List metadataLinks] to LayerGroupInfo so that
>> a LayerGroupInfo can have its own metadatalink (for layer, this is
>> actually in ResourceInfo).
>>
>
> No particular objections, but a couple of observations:
> * What if the group is published as tree or named mode, are these going to
> make
>   sense regardless? I guess so... but by spec they will be inhrerited by
> all sub-layers.
>   I guess it will be up to the admin to decide if this makes sense or not
> * The layer group UI is starting to become pretty crowded, breaking it up
> in tabs
>   like the layer one would probably be good
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
>
> --
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: 2.8-cite-wfs-1.0 #27

[monitor]

See 

--
[...truncated 3244 lines...]
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 

[Geoserver-devel] Jenkins build is back to normal : geoserver-master #1920

[monitor]

See 


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Jenkins: 2.8-cite-wms-1.1 #27

[monitor]

See 

--
[...truncated 9003 lines...]
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 
net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:551)
 [exec] at 
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:409)
 [exec] at 

[Geoserver-devel] Build failed in Jenkins: 2.8-cite-wcs-1.0 #27

[monitor]

See 

--
[...truncated 1385 lines...]
war:
  [zip] Building zip: 


jar.realm:

compile:
[mkdir] Created dir: 

[javac] 
:13:
 warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to 

warning: [options] bootstrap class path not set in conjunction with -source 1.6
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
 [copy] Copying 1 file to 


jar:
  [jar] Building jar: 


zip.manager.bin:
   [delete] Deleting directory 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 2 files to 

  [zip] Building zip: 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cite ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 

[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ cite 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ cite ---
[INFO] No tests to run.
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ cite ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ cite ---
[INFO] Installing 

 to /var/lib/jenkins/.m2/repository/org/geoserver/cite/1.0/cite-1.0.jar
[INFO] Installing 
 to 
/var/lib/jenkins/.m2/repository/org/geoserver/cite/1.0/cite-1.0.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 34.368s
[INFO] Finished at: Tue Oct 27 20:53:23 UTC 2015
[INFO] Final Memory: 21M/259M
[INFO] 
+ ant clean
Buildfile: 


clean:

BUILD SUCCESSFUL
Total time: 0 seconds
+ pushd ..
~/workspace/geoserver-cite ~/workspace/geoserver-cite/tools 
~/workspace/geoserver-cite
++ pwd
+ FORMS=
+ popd
~/workspace/geoserver-cite/tools ~/workspace/geoserver-cite
+ ant -Dcite.headless=true 
-Dcite.headless.formroot=
 wcs-1.0
Buildfile: 


wcs-1.0:

run-test:
 [exec] Oct 27, 2015 8:53:26 PM com.occamlab.te.Generator generateXsl
 [exec] INFO: Validating 

 [exec] Oct 27, 2015 8:53:27 PM com.occamlab.te.Generator generateXsl
 [exec] INFO: Validating 

[Geoserver-devel] Build failed in Jenkins: 2.8-cite-wcs-1.1 #27

[monitor]

See 

--
[...truncated 1313 lines...]

all:

build.script:

build.script:

data:

webapp.scripts:
[mkdir] Created dir: 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 20 files to 

 [copy] Copying 3 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 17 files to 

 [copy] Copying 5 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 60 files to 

 [copy] Copying 2 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 18 files to 

 [copy] Copying 6 files to 

[mkdir] Created dir: 

 [copy] Copying 12 files to 


webapp.script:
[mkdir] Created dir: 

 [copy] Copying 38 files to 

[mkdir] Created dir: 

 [copy] Copying 1 file to 


webapp.script:
[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 69 files to 

 [copy] Copying 

[Geoserver-devel] [JIRA] (GEOS-7281) WPS - No Argument Process doesn't enter RUNNING state

[David Blasby (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 David Blasby created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7281 
 
 
 
  WPS - No Argument Process doesn't enter RUNNING state  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 WPS 
 
 
 

Created:
 

 27/Oct/15 11:37 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 David Blasby 
 
 
 
 
 
 
 
 
 
 
Currently, WPS Processes Enter RUNNING state when they fire a progress notifier (the notifier checks if its in QUEUED state and moves it to RUNNING). This notifier is fired after arguments are processed. 
However, when there are no arguments, the notifier isn't fired and the process does not enter RUNNING state.  
This should be changed so it enters running state during execution. 
This was found by a test failure in the geoserver scripting module (python - PyProcessIntTest.java). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 

[Geoserver-devel] Community Script-Core: test cases problem

[Dave Blasby]

Hi,

I created another pull request to fix the test case failure in community's
Script-core module.  This was a trivial whitespace problem in the
comparison.

PR   : https://github.com/geoserver/geoserver/pull/1306
issue: https://osgeo-org.atlassian.net/browse/GEOS-7282

Thanks,
dave
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Pulls for WPS changes and fixes

[Jody Garnett]

Thanks Dave, generally only message the list if you need specific
review/feedback. There is no need to double up on email and pull request
communication.

You may also wish to add a comment to your pull request mentioning a
specific party needed for a review (for example mentioning Mike for a
documentation change).

--
Jody Garnett

On 27 October 2015 at 15:50, Dave Blasby  wrote:

> I'm starting to put my pull requests up for a series of changes and fixes
> for WPS.
>
> Here's the first;
>
> PR:https://github.com/geoserver/geoserver/pull/1305
> issue: https://osgeo-org.atlassian.net/browse/GEOS-7281
>
> This is a very simple fix to resolve an issue shown by the Python
> Scripting language module for WPS processes.  Processes aren't being moved
> to RUNNING state (i.e. when they don't have any arguments/parameters).
>
>
> Should I send a message to list for every pull request?
>
> Thanks,
> Dave
>
>
> --
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-7282) Script-Core: test cases are not passing

[David Blasby (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 David Blasby created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoServer /  GEOS-7282 
 
 
 
  Script-Core: test cases are not passing  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 Community modules 
 
 
 

Created:
 

 28/Oct/15 12:24 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 David Blasby 
 
 
 
 
 
 
 
 
 
 
This is a minor white space problem in the test case (SessionTest). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA 

[Geoserver-devel] Pulls for WPS changes and fixes

[Dave Blasby]

I'm starting to put my pull requests up for a series of changes and fixes
for WPS.

Here's the first;

PR:https://github.com/geoserver/geoserver/pull/1305
issue: https://osgeo-org.atlassian.net/browse/GEOS-7281

This is a very simple fix to resolve an issue shown by the Python Scripting
language module for WPS processes.  Processes aren't being moved to RUNNING
state (i.e. when they don't have any arguments/parameters).


Should I send a message to list for every pull request?

Thanks,
Dave
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel