date:20180307

Tested system-independent binary on OS X, everything seems to be in order.

Proceeding with publish.

On Wed, Mar 7, 2018 at 3:49 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> New build complete, correct version number is now included in the PDF
> docs: https://build.geoserver.org/geoserver/release/2.13-
> RC1/geoserver-2.13-RC1-user-manual.pdf
>
>
>
> On Wed, Mar 7, 2018 at 2:37 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> Looking at the PDF user manual, I still see the version as 2.12-SNAPSHOT.
>> I think I may have determined where this is getting set:
>> https://github.com/geoserver/geoserver/blob/2.13.x/doc/en/build.xml#L29
>>
>> Given that this issue has been occurring since sometime in 2.12, perhaps
>> this got broken when we changed the docbuild from using make to maven
>> around the time of the initial 2.12 release.
>>
>> I'm rerunning the build with a potential workaround, we'll see if it
>> helps.
>>
>> Torben.
>>
>> On Wed, Mar 7, 2018 at 2:22 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> GeoServer 2.13-RC1 artifacts available for testing:
>>> https://build.geoserver.org/geoserver/release/2.13-RC1/
>>>
>>> Torben
>>>
>>> On Wed, Mar 7, 2018 at 1:48 PM, Torben Barsballe <
>>> tbarsba...@boundlessgeo.com> wrote:
>>>
 Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases,
 the GeoServer 2.13-RC1 release process is starting.

 I will update here when the artifacts are available for testing.

 Torben

>>>
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.13-RC1 release starting

RC1 draft blog post here, if anyone wants to take a look:
http://blog.geoserver.org/wp-admin/post.php?post=2942&action=edit
Mostly the same as the beta blog post, but added mongodb to the community
modules section, and updated the list of bugfixes.

Torben

On Wed, Mar 7, 2018 at 3:59 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Tested system-independent binary on OS X, everything seems to be in order.
>
> Proceeding with publish.
>
> On Wed, Mar 7, 2018 at 3:49 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> New build complete, correct version number is now included in the PDF
>> docs: https://build.geoserver.org/geoserver/release/2.13-RC1
>> /geoserver-2.13-RC1-user-manual.pdf
>>
>>
>>
>> On Wed, Mar 7, 2018 at 2:37 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> Looking at the PDF user manual, I still see the version as
>>> 2.12-SNAPSHOT. I think I may have determined where this is getting set:
>>> https://github.com/geoserver/geoserver/blob/2.13.x/doc/en/build.xml#L29
>>>
>>> Given that this issue has been occurring since sometime in 2.12, perhaps
>>> this got broken when we changed the docbuild from using make to maven
>>> around the time of the initial 2.12 release.
>>>
>>> I'm rerunning the build with a potential workaround, we'll see if it
>>> helps.
>>>
>>> Torben.
>>>
>>> On Wed, Mar 7, 2018 at 2:22 PM, Torben Barsballe <
>>> tbarsba...@boundlessgeo.com> wrote:
>>>
 GeoServer 2.13-RC1 artifacts available for testing:
 https://build.geoserver.org/geoserver/release/2.13-RC1/

 Torben

 On Wed, Mar 7, 2018 at 1:48 PM, Torben Barsballe <
 tbarsba...@boundlessgeo.com> wrote:

> Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases,
> the GeoServer 2.13-RC1 release process is starting.
>
> I will update here when the artifacts are available for testing.
>
> Torben
>


>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.13-RC1 release starting

New build complete, correct version number is now included in the PDF docs:
https://build.geoserver.org/geoserver/release/2.13-RC1/geoserver-2.13-RC1-user-manual.pdf



On Wed, Mar 7, 2018 at 2:37 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Looking at the PDF user manual, I still see the version as 2.12-SNAPSHOT.
> I think I may have determined where this is getting set:
> https://github.com/geoserver/geoserver/blob/2.13.x/doc/en/build.xml#L29
>
> Given that this issue has been occurring since sometime in 2.12, perhaps
> this got broken when we changed the docbuild from using make to maven
> around the time of the initial 2.12 release.
>
> I'm rerunning the build with a potential workaround, we'll see if it helps.
>
> Torben.
>
> On Wed, Mar 7, 2018 at 2:22 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> GeoServer 2.13-RC1 artifacts available for testing:
>> https://build.geoserver.org/geoserver/release/2.13-RC1/
>>
>> Torben
>>
>> On Wed, Mar 7, 2018 at 1:48 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases,
>>> the GeoServer 2.13-RC1 release process is starting.
>>>
>>> I will update here when the artifacts are available for testing.
>>>
>>> Torben
>>>
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.13-RC1 release starting

Looking at the PDF user manual, I still see the version as 2.12-SNAPSHOT. I
think I may have determined where this is getting set:
https://github.com/geoserver/geoserver/blob/2.13.x/doc/en/build.xml#L29

Given that this issue has been occurring since sometime in 2.12, perhaps
this got broken when we changed the docbuild from using make to maven
around the time of the initial 2.12 release.

I'm rerunning the build with a potential workaround, we'll see if it helps.

Torben.

On Wed, Mar 7, 2018 at 2:22 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> GeoServer 2.13-RC1 artifacts available for testing:
> https://build.geoserver.org/geoserver/release/2.13-RC1/
>
> Torben
>
> On Wed, Mar 7, 2018 at 1:48 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases, the
>> GeoServer 2.13-RC1 release process is starting.
>>
>> I will update here when the artifacts are available for testing.
>>
>> Torben
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 2.13-RC1 release starting

GeoServer 2.13-RC1 artifacts available for testing:
https://build.geoserver.org/geoserver/release/2.13-RC1/

Torben

On Wed, Mar 7, 2018 at 1:48 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases, the
> GeoServer 2.13-RC1 release process is starting.
>
> I will update here when the artifacts are available for testing.
>
> Torben
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] 2.13-RC1 release starting

Following from the GeoTools 19-RC1 and GeoWebCache 1.13-RC1 releases, the
GeoServer 2.13-RC1 release process is starting.

I will update here when the artifacts are available for testing.

Torben
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

On Wed, Mar 7, 2018 at 5:50 PM, Nuno Oliveira <
nuno.olive...@geo-solutions.it> wrote:

> Indeed Teradata and SQLServer dialects pagination handling are quite
> complex.
> As far I can tell they should work fine.
>

Awesome. Then I have no objection, it's a good feature in the right hands.
Just remember to document clearly the gun and the foot :-)

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 di Montramito 3/A
55054  Massarosa (LU)
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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

2018-03-07 Thread Nuno Oliveira

Indeed Teradata and SQLServer dialects pagination handling are quite complex.
As far I can tell they should work fine.

On 03/07/2018 03:57 PM, Andrea Aime wrote:
On Wed, Mar 7, 2018 at 4:53 PM, Nuno Oliveira > wrote:

2) The SQL View mechanism is generic, cross database... will whatever query
location work
along with paging and query hints across
all databases? What I'm asking here is to consider all JDBCDataStore
implementation, as
this is not "Oracle sql views", but "sql views" :-p
Again, this might be documented, e.g., "Sorry XYZ users, :where_clause: is
not for you"

Analytics operations (DENSE_RANK, FIRST_VALUE, LAST_VALUE, RANK, ROW_NUMBER)
are available in ANSI SQL (maybe I'm wrong). My example is a PostgreSQL
query, I didn't
test it with Oracle but I have similar queries that work that way in Oracle
too ...

Unfortunately not, paging is done in the most atrocious ways across the various database dialets,
none of them

using a recognizable standard as far as I know

Cheers
Andrea
==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more
information.==Ing. Andrea Aime @geowolfTechnical LeadGeoSolutions S.A.S.Via di Montramito 3/A55054
Massarosa (LU)phone: +39 0584 962313fax: +39 0584 1660272mob: +39 339
8844549http://www.geo-solutions.ithttp://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.

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

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

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 r

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

On Wed, Mar 7, 2018 at 4:53 PM, Nuno Oliveira <
nuno.olive...@geo-solutions.it> wrote:

> 2) The SQL View mechanism is generic, cross database... will whatever
> query location work along with paging and query hints across
> all databases? What I'm asking here is to consider all JDBCDataStore
> implementation, as this is not "Oracle sql views", but "sql views" :-p
> Again, this might be documented, e.g., "Sorry XYZ users,
> :where_clause: is not for you"
>
>
> Analytics operations (DENSE_RANK, FIRST_VALUE, LAST_VALUE, RANK,
> ROW_NUMBER)
> are available in ANSI SQL (maybe I'm wrong). My example is a PostgreSQL
> query, I didn't
> test it with Oracle but I have similar queries that work that way in
> Oracle too ...
>

Unfortunately not, paging is done in the most atrocious ways across the
various database dialets, none of them
using a recognizable standard as far as I know

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 di Montramito 3/A
55054  Massarosa (LU)
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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

2018-03-07 Thread Nuno Oliveira


Hi Andrea,
thanks for the feedback, please see my answers bellow :)

On 03/07/2018 03:25 PM, Andrea Aime wrote:

Hi Nuno,
not against but I have a couple of worries.

1) The where clause generated by GeoServer talks about attributes visible when the full query is 
run, depending on the query
complexity one might decide to place the where somewhere that only has a subset of such attributes 
computed (e..g, case with inner queries).
This will eventually break the query if the wrong attribute is filtered upon. I guess this migth 
be dealt with at the documentation level:
"hey dude, we give you this opportunity, the mechanism works like this , 
you can shoot yourself in the foot with it, don't blame us"


As I said:
/
//This comes handy (better performance) when we have extra operations that //
//can  be done on top of the rows filtered with the GeoServer filter first./

The :where_clause: clause should always be applied at the point where we have
already all the final attributes (attributes GeoServer is aware of).

I understand your concern, a user may create the view and put the WHERE
place holder in a nested deep query where only a portion of the attributes are
available and then everything will be fine until a new request that uses a non
available attribute is requested ...

Unfortunately there is nothing we can do to prevent that to happen except warn
the user about the correct usage of the placeholder in the documentation.



2) The SQL View mechanism is generic, cross database... will whatever query location work along 
with paging and query hints across
    all databases? What I'm asking here is to consider all JDBCDataStore implementation, as this 
is not "Oracle sql views", but "sql views" :-p

    Again, this might be documented, e.g., "Sorry XYZ users, :where_clause: is not 
for you"


Analytics operations (DENSE_RANK, FIRST_VALUE, LAST_VALUE, RANK, ROW_NUMBER)
are available in ANSI SQL (maybe I'm wrong). My example is a PostgreSQL query, 
I didn't
test it with Oracle but I have similar queries that work that way in Oracle too 
...



Cheers
Andera


Summarizing, this is an advanced feature that may come handy in some use cases 
(common
enough to be handled by ANSI SQL) but if a user uses it wrong it can bite him 
hard :)




On Wed, Mar 7, 2018 at 3:59 PM, Nuno Oliveira > wrote:


Hi all,

Sorry for the cross porting but this touches the two projects ...

I would like to extend the current support of SQL views (Virtual Tables) to
allow us to add a placeholder for the where clause where GeoServer will
add the needed filter.

This comes handy (better performance) when we have extra operations that
can  be done on top of the rows filtered with the GeoServer filter first.

Consider the following use case: we have several meteorological stations
that have several measurements (wind speed, temperature, humidity,
etc ..) and for each one we are only interested in the last measurement for
each available measurement type.

We can create a query that returns exactly what we want:

SELECT STATION_NAME,
   MEASUREMENT,
   MEASUREMENT_TYPE,
   LOCATION
FROM
  (SELECT st.common_name AS STATION_NAME,
  ob.value AS MEASUREMENT,
  pr.param_name AS MEASUREMENT_TYPE,
  st.position AS LOCATION,
*ROW_NUMBER() OVER(PARTITION BY st.id , pr.param_name**
**    ORDER BY ob.time DESC) AS RANK*
   FROM meteo.meteo_stations st
   LEFT JOIN meteo.meteo_observations ob ON st.id  = 
ob.station_id
   LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id 
) AS stations
WHERE RANK = 1;

The issue is that this query will NOT be as efficient as it can be when 
used with GeoServer,
actually the performance will be quite bad. This happens because GeoServer 
will add
is WHERE clause around the query above, which means that the ranking will 
happen
for all the data set first and only after we will filter what we don't need.

The following query that uses the :where_clause: placeholder will do the 
opposite, we will first
filter what we don't want and then do the ranking:

SELECT STATION_NAME,
   MEASUREMENT,
   MEASUREMENT_TYPE,
   LOCATION
FROM
  (SELECT STATION_NAME,
  MEASUREMENT,
  MEASUREMENT_TYPE,
  LOCATION,
*ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE*
*    ORDER BY TIME DESC) AS RANK*
   FROM
 (SELECT st.id  AS STATION_ID,
 st.common_name AS STATION_NAME,
 ob.value AS MEASUREMENT,
 pr.param_name AS MEASUREMENT_TYPE,
 ob

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

Hi Nuno,
not against but I have a couple of worries.

1) The where clause generated by GeoServer talks about attributes visible
when the full query is run, depending on the query
complexity one might decide to place the where somewhere that only has a
subset of such attributes computed (e..g, case with inner queries).
This will eventually break the query if the wrong attribute is filtered
upon. I guess this migth be dealt with at the documentation level:
"hey dude, we give you this opportunity, the mechanism works like this
, you can shoot yourself in the foot with it,
don't blame us"

2) The SQL View mechanism is generic, cross database... will whatever query
location work along with paging and query hints across
all databases? What I'm asking here is to consider all JDBCDataStore
implementation, as this is not "Oracle sql views", but "sql views" :-p
Again, this might be documented, e.g., "Sorry XYZ users, :where_clause:
is not for you"

Cheers
Andera


On Wed, Mar 7, 2018 at 3:59 PM, Nuno Oliveira <
nuno.olive...@geo-solutions.it> wrote:

> Hi all,
>
> Sorry for the cross porting but this touches the two projects ...
>
> I would like to extend the current support of SQL views (Virtual Tables)
> to
> allow us to add a placeholder for the where clause where GeoServer will
> add the needed filter.
>
> This comes handy (better performance) when we have extra operations that
> can  be done on top of the rows filtered with the GeoServer filter first.
>
> Consider the following use case: we have several meteorological stations
> that have several measurements (wind speed, temperature, humidity,
> etc ..) and for each one we are only interested in the last measurement for
> each available measurement type.
>
> We can create a query that returns exactly what we want:
>
> SELECT STATION_NAME,
>MEASUREMENT,
>MEASUREMENT_TYPE,
>LOCATION
> FROM
>   (SELECT st.common_name AS STATION_NAME,
>   ob.value AS MEASUREMENT,
>   pr.param_name AS MEASUREMENT_TYPE,
>   st.position AS LOCATION,
>   *ROW_NUMBER() OVER(PARTITION BY st.id ,
> pr.param_name*
> *ORDER BY ob.time DESC) AS RANK*
>FROM meteo.meteo_stations st
>LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
>LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id) AS
> stations
> WHERE RANK = 1;
>
> The issue is that this query will NOT be as efficient as it can be when
> used with GeoServer,
> actually the performance will be quite bad. This happens because GeoServer
> will add
> is WHERE clause around the query above, which means that the ranking will
> happen
> for all the data set first and only after we will filter what we don't
> need.
>
> The following query that uses the :where_clause: placeholder will do the
> opposite, we will first
> filter what we don't want and then do the ranking:
>
> SELECT STATION_NAME,
>MEASUREMENT,
>MEASUREMENT_TYPE,
>LOCATION
> FROM
>   (SELECT STATION_NAME,
>   MEASUREMENT,
>   MEASUREMENT_TYPE,
>   LOCATION,
>   *ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE*
> *ORDER BY TIME DESC) AS RANK*
>FROM
>  (SELECT st.id AS STATION_ID,
>  st.common_name AS STATION_NAME,
>  ob.value AS MEASUREMENT,
>  pr.param_name AS MEASUREMENT_TYPE,
>  ob.time AS TIME,
>  st.position AS LOCATION
>   FROM meteo.meteo_stations st
>   LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
>   LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id
>   WHERE 1 = 1 *:where_clause:*) AS stations_filtered) AS stations
> WHERE RANK = 1;
>
> This will make the usage of some SQL analytic functions affordable
> (performance wise) with GeoServer.
>
> The changes in the code are quite small (a few lines), and this is an
> additive change fully backward compatible.
>
> Any objection ? comments ?
>
> Regards,
>
> Nuno Oliveira
>
> --
> Regards,
> Nuno Oliveira
> ==
> GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 
> for more information.
> ==
>
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313 <+39%200584%20962313>
> fax:  +39 0584 1660272 <+39%200584%20166%200272>
> http://www.geo-solutions.ithttp://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 corteseme

Re: [Geoserver-devel] [Geotools-devel] Improvement for SQL Views (Virtual Tables)

2018-03-07 Thread Ian Turton

Sounds good to me

Ian

On 7 March 2018 at 14:59, Nuno Oliveira 
wrote:

> Hi all,
>
> Sorry for the cross porting but this touches the two projects ...
>
> I would like to extend the current support of SQL views (Virtual Tables)
> to
> allow us to add a placeholder for the where clause where GeoServer will
> add the needed filter.
>
> This comes handy (better performance) when we have extra operations that
> can  be done on top of the rows filtered with the GeoServer filter first.
>
> Consider the following use case: we have several meteorological stations
> that have several measurements (wind speed, temperature, humidity,
> etc ..) and for each one we are only interested in the last measurement for
> each available measurement type.
>
> We can create a query that returns exactly what we want:
>
> SELECT STATION_NAME,
>MEASUREMENT,
>MEASUREMENT_TYPE,
>LOCATION
> FROM
>   (SELECT st.common_name AS STATION_NAME,
>   ob.value AS MEASUREMENT,
>   pr.param_name AS MEASUREMENT_TYPE,
>   st.position AS LOCATION,
>   *ROW_NUMBER() OVER(PARTITION BY st.id ,
> pr.param_name*
> *ORDER BY ob.time DESC) AS RANK*
>FROM meteo.meteo_stations st
>LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
>LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id) AS
> stations
> WHERE RANK = 1;
>
> The issue is that this query will NOT be as efficient as it can be when
> used with GeoServer,
> actually the performance will be quite bad. This happens because GeoServer
> will add
> is WHERE clause around the query above, which means that the ranking will
> happen
> for all the data set first and only after we will filter what we don't
> need.
>
> The following query that uses the :where_clause: placeholder will do the
> opposite, we will first
> filter what we don't want and then do the ranking:
>
> SELECT STATION_NAME,
>MEASUREMENT,
>MEASUREMENT_TYPE,
>LOCATION
> FROM
>   (SELECT STATION_NAME,
>   MEASUREMENT,
>   MEASUREMENT_TYPE,
>   LOCATION,
>   *ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE*
> *ORDER BY TIME DESC) AS RANK*
>FROM
>  (SELECT st.id AS STATION_ID,
>  st.common_name AS STATION_NAME,
>  ob.value AS MEASUREMENT,
>  pr.param_name AS MEASUREMENT_TYPE,
>  ob.time AS TIME,
>  st.position AS LOCATION
>   FROM meteo.meteo_stations st
>   LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
>   LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id
>   WHERE 1 = 1 *:where_clause:*) AS stations_filtered) AS stations
> WHERE RANK = 1;
>
> This will make the usage of some SQL analytic functions affordable
> (performance wise) with GeoServer.
>
> The changes in the code are quite small (a few lines), and this is an
> additive change fully backward compatible.
>
> Any objection ? comments ?
>
> Regards,
>
> Nuno Oliveira
>
> --
> Regards,
> Nuno Oliveira
> ==
> GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 
> for more information.
> ==
>
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313 <+39%200584%20962313>
> fax:  +39 0584 1660272 <+39%200584%20166%200272>
> http://www.geo-solutions.ithttp://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

[Geoserver-devel] Improvement for SQL Views (Virtual Tables)

2018-03-07 Thread Nuno Oliveira


Hi all,

Sorry for the cross porting but this touches the two projects ...

I would like to extend the current support of SQL views (Virtual Tables) to
allow us to add a placeholder for the where clause where GeoServer will
add the needed filter.

This comes handy (better performance) when we have extra operations that
can  be done on top of the rows filtered with the GeoServer filter first.

Consider the following use case: we have several meteorological stations
that have several measurements (wind speed, temperature, humidity,
etc ..) and for each one we are only interested in the last measurement for
each available measurement type.

We can create a query that returns exactly what we want:

   SELECT STATION_NAME,
   MEASUREMENT,
   MEASUREMENT_TYPE,
   LOCATION
   FROM
  (SELECT st.common_name AS STATION_NAME,
  ob.value AS MEASUREMENT,
  pr.param_name AS MEASUREMENT_TYPE,
  st.position AS LOCATION,
   *ROW_NUMBER() OVER(PARTITION BY st.id, pr.param_name**
   **    ORDER BY ob.time DESC) AS RANK*
   FROM meteo.meteo_stations st
   LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
   LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id) AS 
stations
   WHERE RANK = 1;

The issue is that this query will NOT be as efficient as it can be when used 
with GeoServer,
actually the performance will be quite bad. This happens because GeoServer will 
add
is WHERE clause around the query above, which means that the ranking will happen
for all the data set first and only after we will filter what we don't need.

The following query that uses the :where_clause: placeholder will do the 
opposite, we will first
filter what we don't want and then do the ranking:

   SELECT STATION_NAME,
   MEASUREMENT,
   MEASUREMENT_TYPE,
   LOCATION
   FROM
  (SELECT STATION_NAME,
  MEASUREMENT,
  MEASUREMENT_TYPE,
  LOCATION,
   *ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE*
   *    ORDER BY TIME DESC) AS RANK*
   FROM
 (SELECT st.id AS STATION_ID,
 st.common_name AS STATION_NAME,
 ob.value AS MEASUREMENT,
 pr.param_name AS MEASUREMENT_TYPE,
 ob.time AS TIME,
 st.position AS LOCATION
  FROM meteo.meteo_stations st
  LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id
  LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id
  WHERE 1 = 1 *:where_clause:*) AS stations_filtered) AS stations
   WHERE RANK = 1;

This will make the usage of some SQL analytic functions affordable (performance 
wise) with GeoServer.

The changes in the code are quite small (a few lines), and this is an additive change fully backward 
compatible.


Any objection ? comments ?

Regards,

Nuno Oliveira

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

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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 m

Re: [Geoserver-devel] [Geotools-devel] SourceForge exit strategy

Hi Jody,
I don't think it's a specific event, my colleagues not involved in the full
stack (and thus not having maybe an up to date GeoTools checkout)
report repository slowness periodically (e.g., weekly or monthly).
If the artifactory on SAC would get separation from other downloads, that
is, its own dedicated bandwidth, it may be an interesting option to look
into.

Cheers
Andrea


On Wed, Mar 7, 2018 at 3:20 PM, Jody Garnett  wrote:

> The recent qgis release hit the OSGeo download servers hard, and our maven
> repo was affected. After all the fun with repo.boundlessgeo.org we
> probably know a) enough to host artifactory on SAC b) not to try cloud
> hosting of the same.
> On Tue, Mar 6, 2018 at 11:43 PM Andrea Aime 
> wrote:
>
>> Hi Torben,
>> I'm tentatively -1 on the idea but willing to discuss.
>>
>> The proposal you're citing is 2.5 years old and the mailing list trouble
>> we have had in the past week is
>> been the only really serious issue we have had since, as far as I
>> remember.
>>
>> Migrating the lists to OSGeo will generate a very significant disturbance
>> again, but one of our own making,
>> we'll probably lose all subscribers* and create two places that people
>> have to search into before posting a request.
>>
>> I'd be willing to consider the idea again if we have another SF issue in
>> the short term, but besides that,
>> I believe we can tolerate one trouble in 2.5 years, I doubt OSGeo would
>> be able to significantly
>> outperform that.
>>
>> Speaking of which, we keep on having problems with the OSGeo hosted maven
>> repository,
>> my colleagues report slowness and occasional inability to connect, I
>> normally dodge the problem
>> by building from sources my snapshot and using -nsu in all builds. Now, I
>> understand we have not
>> seen similar issues on the mailing list, but it gives the impression SAC
>> is a bit short handed
>> (looking at our community, everybody seems to be busy up to their
>> eyeballs too, so don't think we
>> can offer help there).
>>
>> Cheers
>> Andrea
>>
>> * even assuming SF will give us the list of subscribers, which they might
>> not due to privacy,
>> I don't think we can force subscribe anyone to a new list server hosted
>> by a different
>> organization... so we'd likely have to start from scratch
>>
>>
>> On Tue, Mar 6, 2018 at 10:32 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *SourceForge had outages / reduced service during the week of the
>>> GeoTools 19-beta / GeoServer 2.13-beta release.This caused: - Delays on
>>> mailing list discussions and announcements (including the release
>>> announcement), - Loss of all download statistics for the release, so we
>>> don't know how many people are downloading / testing it.Once again, this
>>> brings up the topic of whether we should consider something a bit more
>>> reliable than sourceforge for hosting mailing lists and release artifacts.
>>> There is a preexisting migration proposal here:
>>> https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
>>>  One
>>> suggestion was to start by migrating the GeoTools project (As it is a
>>> lower-risk migration, given that most people get there artifacts via
>>> maven), and use that to determine feasibility of migrating the GeoServer
>>> project.Any thoughts?Torben*
>>>
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>>
>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
>>
>> ==
>> 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 di Montramito 3/A
>> 
>> 55054  Massarosa
>> 
>> (LU)
>> phone: +39 0584 962313 <+39%200584%20962313>
>> fax: +39 0584 1660272 <+39%200584%20166%200272>
>> mob: +39  339 8844549 <+39%20339%20884%204549>
>>
>> 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 vi

Re: [Geoserver-devel] [Geotools-devel] SourceForge exit strategy

2018-03-07 Thread Jody Garnett

The recent qgis release hit the OSGeo download servers hard, and our maven
repo was affected. After all the fun with repo.boundlessgeo.org we probably
know a) enough to host artifactory on SAC b) not to try cloud hosting of
the same.
On Tue, Mar 6, 2018 at 11:43 PM Andrea Aime 
wrote:

> Hi Torben,
> I'm tentatively -1 on the idea but willing to discuss.
>
> The proposal you're citing is 2.5 years old and the mailing list trouble
> we have had in the past week is
> been the only really serious issue we have had since, as far as I remember.
>
> Migrating the lists to OSGeo will generate a very significant disturbance
> again, but one of our own making,
> we'll probably lose all subscribers* and create two places that people
> have to search into before posting a request.
>
> I'd be willing to consider the idea again if we have another SF issue in
> the short term, but besides that,
> I believe we can tolerate one trouble in 2.5 years, I doubt OSGeo would be
> able to significantly
> outperform that.
>
> Speaking of which, we keep on having problems with the OSGeo hosted maven
> repository,
> my colleagues report slowness and occasional inability to connect, I
> normally dodge the problem
> by building from sources my snapshot and using -nsu in all builds. Now, I
> understand we have not
> seen similar issues on the mailing list, but it gives the impression SAC
> is a bit short handed
> (looking at our community, everybody seems to be busy up to their eyeballs
> too, so don't think we
> can offer help there).
>
> Cheers
> Andrea
>
> * even assuming SF will give us the list of subscribers, which they might
> not due to privacy,
> I don't think we can force subscribe anyone to a new list server hosted by
> a different
> organization... so we'd likely have to start from scratch
>
>
> On Tue, Mar 6, 2018 at 10:32 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>> *SourceForge had outages / reduced service during the week of the
>> GeoTools 19-beta / GeoServer 2.13-beta release.This caused: - Delays on
>> mailing list discussions and announcements (including the release
>> announcement), - Loss of all download statistics for the release, so we
>> don't know how many people are downloading / testing it.Once again, this
>> brings up the topic of whether we should consider something a bit more
>> reliable than sourceforge for hosting mailing lists and release artifacts.
>> There is a preexisting migration proposal here:
>> https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
>>  One
>> suggestion was to start by migrating the GeoTools project (As it is a
>> lower-risk migration, given that most people get there artifacts via
>> maven), and use that to determine feasibility of migrating the GeoServer
>> project.Any thoughts?Torben*
>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>>
> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> 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 di Montramito 3/A
> 55054  Massarosa (LU)
> 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
>

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

2018-03-07 Thread Simone Giannecchini

My Take:

- rename Beta to RC
- rather than having an RC2 adding one more release to the existing train
maybe with a shorter timeline if/as needed

The rationale is giving users something testable that does not carry the
Beta or RC tag as soon as possible and account for a initial shorter
release cycle to cover pressing bugs and problems.

Regards,
Simone Giannecchini
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==
Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob:   +39  333 8128928

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.

On Tue, Mar 6, 2018 at 10:26 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> There was some discussion on this topic in the PMC meeting. Salient points:
>
>- Should we rename the beta the RC (Basically, the fork/RC would now
>be 1 month before the .0 release and there wouldn't be a beta release
>anymore).
>   - The most useful naming scheme for would be whatever people are
>   more likely to test
>- Should we still have an RC(2) two weeks before the .0?
>   - Only if there are enough bugfixes to warrant it?
>
> Anyone have further opinions on these?
>
> On Thu, Feb 22, 2018 at 11:23 AM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> PR's for the associated doc changes here:
>>
>>- https://github.com/geotools/geotools/pull/1811
>>- https://github.com/geoserver/geoserver/pull/2763
>>
>> We also have a release process diagram which includes the freeze. While
>> not critical, that could be updated - does anyone have the source files for
>> it?
>>
>> Torben
>>
>> On Mon, Feb 19, 2018 at 8:14 AM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>>
>>>
>>> On Fri, Feb 16, 2018 at 8:47 AM, Jody Garnett 
>>> wrote:
>>>
 We could also cut the beta just to confirm master is releasable, and
 not branch. Make the first release candidate the branch to achieve the same
 effect.

 It has the advantage of less moving parts, but we do not get a code
 freeze to focus on bugs. But as you point out that is not happening so
 much.

>>>
>>> Unless I am misunderstanding you, this is what we do currently - branch
>>> on the RC. What are you actually suggesting here?
>>>
>>> Torben
>>>
>>>
>>>
 On Fri, Feb 16, 2018 at 2:45 AM Ian Turton  wrote:

> I agree we hardly ever see any feedback before the .0 release. Which
> is a shame but nothing we do seems to make a difference to customers.
>
> So +1 for me
>
> Ian
>
> On 16 February 2018 at 09:32, Nuno Oliveira <
> nuno.olive...@geo-solutions.it> wrote:
>
>> I don't have any voting power, just want to express my +1 towards
>> that change ... and indeed I don't see the advantage of the RC release.
>> If users don't provide feedback, bug fix doesn't happen ... what are
>> the advantages of having the RC release ?
>>
>>
>> On 02/16/2018 03:18 AM, Ben Caradoc-Davies wrote:
>>
>>> +1. It does seem that we are not getting much benefit from waiting
>>> until

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

See 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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 #5621

See 


Changes:

[Andrea Aime] Forgot to add pom file

--
[...truncated 544.10 KB...]
[INFO] 
[INFO] Skipping GWC UI Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping GeoServer INSPIRE Extensions
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Ysld GeoServer Plugin
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping GeoServer CSS Styling
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping WCS UI Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Application Schema Integration Test
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Importer Core Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping WCS NetCDF output Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Security UI JDBC Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Security UI LDAP Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping GeoServer Security Extension Modules
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Catalog Services for the Web core module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping OGR WPS
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Web process status sharing with Hazelcast
[INF

[Geoserver-devel] Jenkins build is back to normal : geoserver-2.13.x #20

See 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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 #5620