Re: [Geotools-devel] advise code sprint participants to book travel

2018-10-09 Thread Jody Garnett 
> 3) GeoTools PMC
>
> The GeoTools PMC has an allocated budget of *$3000* which we have not
> spent. Some of that was to help members attend the Bonn code sprint which
> ended up not being needed.
>
> The GeoTools Budget Request
>  also
> highlighted this Java 11 activity as a risk item we were planning for.
>
> I will make a separate email to the GeoTools PSC
>

In writing this up I noted that we had only been approved for $1500. An
additional $1500 had been donated to work on a specific subject (SLD
interoperability).

>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

2018-10-09 Thread Jody Garnett 
I would like to ask the GeoTools PMC to approve the following proposal:

*Approve up to $1500 to support code sprint participants*


Our budget request is here
 where we
asked for $1500 help attend bonn code sprint to look at JAI replacement. We
did not end up using these funds. *Aside: In addition to the $1500
requested we have had an additional donation of $1500 for SLD
interoperability we should use this calendar year.*

If I can ask PMC members to respond to this email by the end of the week
Oct 12th:

   - Andrea Aime
   - Ben Caradoc-Davies
   - Ian Turton
   - Jody Garnett +1 (initial motion)
   - Nuno Oliveira
   - Simone Giannecchini
   - Torben Barsballe

--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] advise code sprint participants to book travel

2018-10-09 Thread Jody Garnett 
It has been a challenge to keep the code sprint budget current:
 Java 2018 Code Sprint


Even today I found a couple individuals who were making plans not to travel
because it did not look like we could get funding together and were waiting
for guidence.

Proposal:  *I would like to advise participants to book travel today with
the assurance that they will be reimbursed.*

Here is why I am confident that we can do so - even with "just" our PSC
budget we can support the travel requests thus far:

1) The code-sprint-budget has been sent to the OSGeo Board as part of a
request to host a code sprint. If there is no other feedback I will make a
motion for the board to review and approve our request. This would
potentially give us the go-ahead by the end of the week, rather than
waiting until the next board meeting.

Based on this I asked the board to approve a code-sprint request for *$2000*
based on the number of participants wishing to travel last week.  More
importantly this is a request to host, OSGeo as hosting organization would
pick up any cost overrun so our participants are not doing so out of pocket.

2) GeoServer PSC

The GeoServer PSC has an allocated budget of* $**1,000* which we have not
spent. I kind of hoped we could make up geoserver t-shirts for contributors
- but a code sprint is more important.

I will make a separate email to the GeoServer PSC

3) GeoTools PMC

The GeoTools PMC has an allocated budget of *$3000* which we have not
spent. Some of that was to help members attend the Bonn code sprint which
ended up not being needed.

The GeoTools Budget Request
 also
highlighted this Java 11 activity as a risk item we were planning for.

I will make a separate email to the GeoTools PSC

4) GeoWebCache

GeoWebCache is an OSGeo community project and can make budget requests via
the incubation committee if needed.

I will ask the GWC email list to consider participation.

References:
- https://wiki.osgeo.org/wiki/OSGeo_Budget_2018
- https://github.com/geotools/geotools/wiki/GeoTools-Budget-Request-2018

--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Backport of App-Schema Solr integration to 2.14.1

2018-10-09 Thread Nuno Oliveira 

Dear all,
my apologies for the cross posting, but this topic touches both GeoServer and 
GeoTools.


As you may have noticed, lately several enhancements for the integration between
Apache Solr and App-Schema have been contributed, to GeoTools:

 * https://github.com/geotools/geotools/pull/1995
 * https://github.com/geotools/geotools/pull/2081

... and to GeoServer:

 * https://github.com/geoserver/geoserver/pull/3040
 * https://github.com/geoserver/geoserver/pull/3143

I would like to backport this enhancements on time for the GS 2.14.1 and GT 20.1
releases (18-11-2018), this will respect the one (1) month cool-down rule.

This enhancements touches App-Schema and Solr modules, they don't add any 
backward
compatibility, they are additive by nature. We are currently testing this with a 
client.


Does anyone foreseen any blocker on back-porting this enhancements ?

Kind 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

---

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.

___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] OGR Module Support

2018-10-09 Thread Andrea Aime 
Hi Jared,
the module was dropped out of build because it was breaking the build, and
had no maintainer.
So in order to bring it back to "life" it needs someone appointed as a
maintainer (you?) and
do whatever is necessary to fix its build. There is no requirement to bring
it up fully, e.g., you
might decide to only push up the JNI version of it, for example.

See the original thread in which it was demoted:
https://sourceforge.net/p/geotools/mailman/geotools-devel/thread/CA%2BnxMTtFWqB1cFThvQ2LTKg36Scvqvj_P8_d7SS_tavcxCXvrg%40mail.gmail.com/#msg36284051

Cheers
Andrea


On Mon, Oct 8, 2018 at 1:14 AM Jared Erickson 
wrote:

> Hi all!
>
> I would like to get the GeoTools OGR modules back into a status where they
> are published to a maven repo.  The GeoScript Groovy projects uses these
> modules so I would like to volunteer to keep them compiling.  What do I
> need to do to get them publishing to maven again?
>
> Thanks,
> Jared
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-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
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Quiet builds in preparation for the code sprint

2018-10-09 Thread Andrea Aime 
Hi,
saw no objections, going to merge in order to avoid PR rotting (it's
touching so many
files that the likeliness of a conflict is on the high side)

Cheers
Andrea


On Sun, Oct 7, 2018 at 11:25 AM Andrea Aime 
wrote:

> Hi,
> during the incoming sprint I believe we'll spend a lot of time looking at
> build logs.
> So I thought it would have been nice to have a clean log, but right now
> it's littered with printouts
> and stack traces that have been accumulated over the years.
>
> So I have set out to do three things:
>
>1. Setup a quiet logging profile that we can use to avoid all these
>logs (used by default)
>2. Comment out all System.out and System.err
>3. Turn all print stack trace into logging statements
>
> The result is in this massive pull request:
> https://github.com/geotools/geotools/pull/2094
>
> Step 1 was simple enough. Open to suggestion to make it better.
>
> Step 2 was a pain. There are lots of System.out and System.err spread out
> pretty much everywhere
> (not just in tests). I did a quick replace via regular expressions, made
> it compile again, and then
> started looking one by one the cases that were not in the tests and see if
> it made sense to turn
> them into logging statements instead.
> Took a ton of time but the result seems reasonable.
> Contributions to make it better are more than welcomed, there are for sure
> other places that could use
> transformation from sysout to logging statement, but it's just too much
> work for a single person
> acting in spare time.
>
> Step 3 was reasonably simple using regular expressions (400+ of them!),
> although I had to compromise a bit here
> too, the replacement was done using a import-less statement:
> java.util.logging.Logger.getGlobal().log(java.util.logging.Level.INFO,
> "", e);
> Again, the logging level might be tuned class by class, some classes might
> do without the package prefixes,
> and some might use their existing LOGGER... but again, that would have
> required more effort than I can spend.
>
> Despite the limitations of the work, I believe the changes are leaving the
> codebase better than they found it,
> and the build output much cleaner.
>
> I also searched for ways to make the build fail if anything was written by
> tests on the standard output
> (to keep things clean after this change) or standard error, but could not
> find anything useful so far,
> looks like the way to go would be to use PMD, but that also slows down the
> build a lot and would require
> a fair amount of configuration and discussion work... something for
> another day :-)
>
> 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
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>


-- 

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
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or