Re: [Geotools-devel] SourceForge exit strategy

2018-03-07 Thread Kevin Smith 
On the subject of migrating away from Source Forge for hosting
installation artifacts, I just noticed that SourceForge has the option
to automatically pull in the artifacts from GitHub releases.  This might
simplify transitioning to GitHub while still using SourceForge as a backup.


On 2018-03-06 01:32 PM, Torben Barsballe 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
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Kevin Michael Smith




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

2018-03-07 Thread Torben Barsballe 
>
>
> None of the others took down the system for a whole week, that was
> actually bad, the others, well... (in my mail I started with "only one
> really serious outage", the rest talked about "one trouble" in fact, I
> should have been more clear
>

Fair enough, "serious outage" is relatively open to interpretation; I would
consider anything that delays / blocks a release a serious outage (which
would give us two or three in four years). But yes, this last outage has
definitely been the most severe.

to avoid leaving side to misinterpretations, need to learn to read a few
> more times mails before sending them on this list).
>
>
After-the-fact clarifications work fine too.


> I am personally more concerned about changing how we host artifacts than
>> changing mailing lists. I think we would probably be OK to remain with
>> SourceForge for hosting the mailing lists, given that it would be a very
>> disruptive move.
>>
>
> Works for me
>
>

Cheers,

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

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

2018-03-07 Thread Andrea Aime 
On Wed, Mar 7, 2018 at 7:03 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> With respect to SourceForge reliability: From a search of GS discussions
> (Gitter and otherwise), there's been a notable SourceForge outage at least
> once a year. In addition to these, I believe there have been a number of
> other short, minor outages that were an annoyance, but not of sufficient
> scope to be remarked upon.
>
> SourceForge Outages:
>
> February 13-20, 2018, blocked GT 19-beta / GS 2.13-beta for a day or two,
> also knocked out Mailing Lists.
>
> September 27-28, 2017, blocked GT 18-RC1 / GS 2.12-RC1 build for a day or
> two, also knocked out Mailing Lists. We tested uploading the release to
> GitHub, it was pretty easy: https://github.com/geoto
> ols/geotools/releases/tag/18-RC1
>
> May 9th 2016 - SourceForge outage blocking downloads of GeoServer
>
> February 22, 2016 - SourceForge outage blocking GWC 1.7.4 release,
> artifacts uploaded to GitHub: https://github.com/GeoWebCache/geowebcache/
> releases/tag/1.7.4
>
> July 21-21, 2015 - SourceForge outage blocking downloads and mailing lists
>
> December 16, 2014 - SourceForge down, blocking mailing lists
>
>

None of the others took down the system for a whole week, that was actually
bad, the others, well... (in my mail I started with "only one really
serious outage", the rest talked about "one trouble" in fact, I should have
been more clear
to avoid leaving side to misinterpretations, need to learn to read a few
more times mails before sending them on this list).


> I am personally more concerned about changing how we host artifacts than
> changing mailing lists. I think we would probably be OK to remain with
> SourceForge for hosting the mailing lists, given that it would be a very
> disruptive move.
>

Works for me

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___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

2018-03-07 Thread Torben Barsballe 
With respect to SourceForge reliability: From a search of GS discussions
(Gitter and otherwise), there's been a notable SourceForge outage at least
once a year. In addition to these, I believe there have been a number of
other short, minor outages that were an annoyance, but not of sufficient
scope to be remarked upon.

SourceForge Outages:

February 13-20, 2018, blocked GT 19-beta / GS 2.13-beta for a day or two,
also knocked out Mailing Lists.

September 27-28, 2017, blocked GT 18-RC1 / GS 2.12-RC1 build for a day or
two, also knocked out Mailing Lists. We tested uploading the release to
GitHub, it was pretty easy: https://github.com/geotools/geotools/releases/
tag/18-RC1

May 9th 2016 - SourceForge outage blocking downloads of GeoServer

February 22, 2016 - SourceForge outage blocking GWC 1.7.4 release,
artifacts uploaded to GitHub:
https://github.com/GeoWebCache/geowebcache/releases/tag/1.7.4

July 21-21, 2015 - SourceForge outage blocking downloads and mailing lists

December 16, 2014 - SourceForge down, blocking mailing lists


In addition to this, SourceForge does not have a particularly good
reputation:

   - They have been known to inject malicious code into binaries in the
   past (This was in 2015, see
   
http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
   )
   - I have found reports of people being redirected to malicious sites
   after downloading GeoServer via SourceForge (Although note that this was in
   2016, they seem to have improved somewhat since then)


So, one outage in 2.5 years is not accurate, and apart from that there are
other reasons why SourceForge is perhaps not the best place to be hosting
artifacts.

I am personally more concerned about changing how we host artifacts than
changing mailing lists. I think we would probably be OK to remain with
SourceForge for hosting the mailing lists, given that it would be a very
disruptive move.

Torben

On Wed, Mar 7, 2018 at 7:55 AM, Jim Hughes  wrote:

> I don't think there's a hard requirement that all dependencies have to be
> available on Maven central...
>
> That said, it is a typical nice-to-have thing...
>
> I'd say that having GT/GWC/GS jars on Maven central and having OSGeo, or
> interested companies host JAI on their Maven repos seems like a reasonable
> plan.
>
> http://central.sonatype.org/pages/requirements.html
>
> Basically, I'm suggesting Maven central for Jars, and then
> GitHub+SourceForge for wars/other binaries.
>
> Cheers,
>
> Jim
>
>
> On 03/07/2018 10:38 AM, Andrea Aime wrote:
>
> On Wed, Mar 7, 2018 at 4:34 PM, Jim Hughes  wrote:
>
>> Hi all,
>>
>> As a quick question, are there any impediments to publishing GeoTools and
>> GeoServer jars on Maven Central?
>>
>
> JAI, I think? :-)
>
> 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 <+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 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

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

2018-03-07 Thread Andrea Aime 
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___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [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

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

2018-03-07 Thread Andrea Aime 
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___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

2018-03-07 Thread Jim Hughes 
I don't think there's a hard requirement that all dependencies have to 
be available on Maven central...


That said, it is a typical nice-to-have thing...

I'd say that having GT/GWC/GS jars on Maven central and having OSGeo, or 
interested companies host JAI on their Maven repos seems like a 
reasonable plan.


http://central.sonatype.org/pages/requirements.html

Basically, I'm suggesting Maven central for Jars, and then 
GitHub+SourceForge for wars/other binaries.


Cheers,

Jim

On 03/07/2018 10:38 AM, Andrea Aime wrote:
On Wed, Mar 7, 2018 at 4:34 PM, Jim Hughes > wrote:


Hi all,

As a quick question, are there any impediments to publishing
GeoTools and GeoServer jars on Maven Central?


JAI, I think? :-)

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.




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

Re: [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

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

2018-03-07 Thread Andrea Aime 
On Wed, Mar 7, 2018 at 4:34 PM, Jim Hughes  wrote:

> Hi all,
>
> As a quick question, are there any impediments to publishing GeoTools and
> GeoServer jars on Maven Central?
>

JAI, I think? :-)

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___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

2018-03-07 Thread Jim Hughes 

Hi all,

As a quick question, are there any impediments to publishing GeoTools 
and GeoServer jars on Maven Central?


I believe the requirements could be met easily enough: 
http://central.sonatype.org/pages/requirements.html. (I've done this for 
LocationTech projects like JTS and GeoMesa, and I'd be happy to help.)


Cheers,

Jim

On 03/07/2018 10:06 AM, Nuno Oliveira wrote:

Hi all,

I agree with Andrea ... so far my experience with the OSGeo maven 
repository doesn't
give me too much confidence for such an important move and one trouble 
per 2.5 years

is not that bad indeed.

Regards,

Nuno Oliveira

On 03/07/2018 02:24 PM, Andrea Aime wrote:

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
> 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!

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

2018-03-07 Thread Andrea Aime 
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

Re: [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

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

2018-03-07 Thread Nuno Oliveira 

Hi all,

I agree with Andrea ... so far my experience with the OSGeo maven repository 
doesn't
give me too much confidence for such an important move and one trouble per 2.5 
years
is not that bad indeed.

Regards,

Nuno Oliveira

On 03/07/2018 02:24 PM, Andrea Aime wrote:

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 
> 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-de...@lists.sourceforge.net 

https://lists.sourceforge.net/lists/listinfo/geoserver-devel





-- 


Regards,

Andrea Aime

==GeoServer Professional Services from the

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

2018-03-07 Thread Andrea Aime 
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-de...@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

Re: [Geotools-devel] [Geoserver-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-de...@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

Re: [Geotools-devel] Replace JScience JSR275 with JSR363

2018-03-07 Thread César Martínez Izquierdo 
Thanks Andrea and Jody for your very kind offers.

I will be at the Bonn code sprint. I've committed to work on some
other tasks, but I think I could keep some time (maybe a day?) for
pushing this task.
In any case, I'll try to advance some work before the code sprint.

I think I will start by updating the proposal you linked and trying to
figure out how to use unit-ri/unit-se (JSR 363 implementations).
Any suggestion is welcome.

Regards,

César


On 7 March 2018 at 08:41, Jody Garnett  wrote:
> I saw the activity on jira and found the “withdrawn” proposal -
> https://github.com/geotools/geotools/wiki/Replace-JSR-275-Units-Library
>
> If we can update this with a plan I would be pleased to work on this during
> the OSGeo code sprint.
> On Tue, Mar 6, 2018 at 9:21 AM Jens Auer  wrote:
>>
>> Hi,
>>
>> I have to admit that I sent the mails last year and wanted to work on
>> migrating to jsr363. However, when I quickly ran into problems when I wanted
>> to use jsr363 in our project in a limited way just in our own classes. We
>> have multiple dependencies that depend on JScience /jsr275, and using both
>> jsr363 and jsr275 in a project leads to many problems because both use the
>> javax.measure package and some identical class names. I guess it would have
>> been easier if jsr363 used another package, but because of these issues I
>> stopped working on the migration.
>>
>> Best wishes,
>> Jens
>>
>> -Ursprüngliche Nachricht-
>> Von: César Martínez Izquierdo 
>> Gesendet: Freitag, 2. März 2018 11:28
>> An: geotools-devel@lists.sourceforge.net
>> Cc: jens.a...@betaversion.net; Jody Garnett 
>> Betreff: Replace JScience JSR275 with JSR363
>>
>> Hi,
>> Last year there was a thread on the list regarding the migration from
>> JScience/JSR275 to JSR363, although I assume that no progress was finally
>> achieved:
>>
>>
>> https://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg38174.html
>>
>> I'd like to help on this effort, if there is still interest in migrating
>> to JSR363.
>>
>> The use of JSR275 is a problem since there are collisions on
>> package/classes/method signatures between JSR363 and JSR363, so you can't
>> combine Geotools with any library using JS363.
>>
>> Note that JSR275 is used by the "forked" GeoAPI APIs used in Geotools, so
>> this change will imply some method signature modifications on that API.
>>
>> Best regards,
>>
>> César Martínez
>>
>>
>> --
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>César Martínez Izquierdo
>>GIS developer
>>-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
>>SCOLAB: http://www.scolab.es
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>
>> ---
>> Diese E-Mail wurde von AVG auf Viren geprüft.
>> http://www.avg.com
>>
>>
> --
> --
> Jody Garnett



-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel