Re: [Geoserver-devel] 2.18.3 release artefacts ready for test

[bradh]

I checked docs and war. Seems OK on initial login and layer preview, although I thought we had a PDF users manual and I didn't see that.BradOn 23 Apr 2021 2:55 am, Jody Garnett  wrote:Checked downloads, and they are fine.Noticed some INFO messages in the logs that appear to detailed:22 Apr 09:52:33 INFO [geoserver.wms] - Request: getServiceInfoINFO: ===INFO: Marlin software rasterizer           = ENABLEDINFO: Version                              = [marlin-0.9.3-Unsafe]INFO: sun.java2d.renderer                  = org.marlin.pisces.MarlinRenderingEngineINFO: sun.java2d.renderer.useThreadLocal   = trueINFO: sun.java2d.renderer.useRef           = softINFO: sun.java2d.renderer.edges            = 4096INFO: sun.java2d.renderer.pixelWidth       = 4096INFO: sun.java2d.renderer.pixelHeight      = 2176INFO: sun.java2d.renderer.profile          = qualityINFO: sun.java2d.renderer.subPixel_log2_X  = 8INFO: sun.java2d.renderer.subPixel_log2_Y  = 3INFO: sun.java2d.renderer.tileSize_log2    = 6INFO: sun.java2d.renderer.tileWidth_log2   = 7INFO: sun.java2d.renderer.blockSize_log2   = 5INFO: sun.java2d.renderer.forceRLE         = falseINFO: sun.java2d.renderer.forceNoRLE       = falseINFO: sun.java2d.renderer.useTileFlags     = trueINFO: sun.java2d.renderer.useTileFlags.useHeuristics = trueINFO: sun.java2d.renderer.rleMinWidth      = 64INFO: sun.java2d.renderer.useSimplifier    = falseINFO: sun.java2d.renderer.usePathSimplifier= falseINFO: sun.java2d.renderer.pathSimplifier.pixTol = 0.125INFO: sun.java2d.renderer.clip             = trueINFO: sun.java2d.renderer.clip.runtime.enable = falseINFO: sun.java2d.renderer.clip.subdivider  = trueINFO: sun.java2d.renderer.clip.subdivider.minLength = 100.0INFO: sun.java2d.renderer.doStats          = falseINFO: sun.java2d.renderer.doMonitors       = falseINFO: sun.java2d.renderer.doChecks         = falseINFO: sun.java2d.renderer.useLogger        = falseINFO: sun.java2d.renderer.logCreateContext = falseINFO: sun.java2d.renderer.logUnsafeMalloc  = falseINFO: sun.java2d.renderer.curve_len_err    = 0.01INFO: sun.java2d.renderer.cubic_dec_d2     = 1.0INFO: sun.java2d.renderer.cubic_inc_d1     = 0.2INFO: sun.java2d.renderer.quad_dec_d2      = 0.5INFO: Renderer settings:INFO: CUB_DEC_BND  = 256.0INFO: CUB_INC_BND  = 51.2INFO: QUAD_DEC_BND = 128.0INFO: INITIAL_EDGES_CAPACITY               = 98304INFO: INITIAL_CROSSING_COUNT               = 1024INFO: ===--Jody GarnettOn Thu, 22 Apr 2021 at 02:45, Ian Turton  wrote:https://build.geoserver.org/view/release/job/geoserver-release/27/artifact/distribution/2.18.3/please let me know if you run into any problemsIan-- Ian Turton
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

Re: [Geoserver-devel] Advice on UI approach

[bradh]

Seems like we normally start with freemarker templates, and that might be appropriate in your case. Otherwise its pretty open with what works in terms of Wicket - I don't think that the admin UI is a great source of UX design patterns,  so not a lot of constraints. One thing that you might want to consider is how the translation into other languages would work. There are a lot of variations out there...BradOn 7 Apr. 2021 02:07, peter.rushfo...@gmail.com wrote:Hi, I’ve been working on developing a way to process strings templated with attribute name placeholders, when serializing a WFS GetFeature / WMS/WMTS GetFeatureInfo response.  The strings will look like something like this, for example: “This string can contain zero or more attribute ${name} placeholders. The placeholders can be for any ${attribute}, not only name.” . I want to build a user interface to allow the user to enter the text part of those strings, but to select the attribute names from a list or palette.   Do you have any opinions about what would be a good / appropriate GeoServer way of accomplishing this task?   I was thinking about doing the simplest thing that could possibly work, which seems to me might be similar to how the Proxy Base URL text input works –allow the user to type the placeholder and other text into the field, maybe with a supporting select of attribute names. Thank you! Peter___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Version control for local Geoserver Repository

[bradh]

You could rebase your changes. Or just move your extension out of the tree.Its your code - if it isn't going to be part of GeoServer do it however you like.Brad.On 13 Oct 2020 3:03 pm, maven apache  wrote:I am building a local geoserver extension which does not have the plan to make it open source, and I only use that extension with geoserver myself. I think this does not breach the GPL License used by Geoserver. If yes, plesae let me know.
The extension started from a tag v2.17.0:
git pull https://github.com/geoserver/geoserver.git
git checkout -b local_branch 2.17.0
//coding for the extension
Now once we want to sync with the current stable version of geoserver: 2.18.0, I tried this:
git checkout master
git pull --tags
git checkout local_branch 
git merge 2.18.0
Now there are so many files changed/confliction because of the version changed in the pom.xml:
org.geoserver
geoserver
pom
2.18.0
GeoServer
I am afraid this may break the git history. 
Then I wonder how does geoserver handle this problem? Since every time a new stable version is released, the version number will be updated too. But I do not find the commits for the version update.Even though I read the development guide at https://docs.geoserver.org/stable/en/developer/source.html#source-code, I still can not find a solution.Any suggestions or the best practice for this customization workflow?Thanks.

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

Re: [Geoserver-devel] (Cross post) Deprecation cleanup branches ready

[bradh]

Andrea,

 

I tried to read the changes – its beyond me at the moment.

 

I did build the geotools, geowebcache and geoserver branches locally (on ubuntu 
1904 and openjdk11) and booted the resulting war file on tomcat9. Looks good.

 

I can only express my gratitude for the lone geowolf effort, and recommend that 
it be merged before its lost in merge conflicts.

 

Brad

 

From: Andrea Aime  
Sent: Sunday, 5 May 2019 3:39 AM
To: Geotools-Devel list ; Geoserver-devel 
; geowebcache-devel 

Subject: [Geoserver-devel] (Cross post) Deprecation cleanup branches ready

 

Hi all,

sorry for the cross-post, this mail talks about a deprecation cleanup work that 
involves all three projects.

 

If you have participated to any PSC meeting in the last few months, or read the 
minutes, you probably

know that I've been working on a deprecated API cleanup on all three projects, 
with the following objectives:

*   Remove all deprecated API calls, where possible, or suppress the 
deprecated API call warning, otherwise
*   Remove all API that has been deprecated over the years, with the 
exception if APIs that are not yet deprecated in the stable series
*   Make the build fail if any deprecated API is used (unless explicitly 
suppressed), thus preventing both careless usage of deprecated API, and easy 
going deprecation of existing API without a clear replacement strategy

The work used all the spare time I could dedicate to coding in the last two 
months, here are links to the pull requests with some numbers:

*   GeoTools: https://github.com/geotools/geotools/pull/2309 (161 commits, 
1063 modified files, 5000 lines of code modified, 13000 removed)
*   GeoWebCache: https://github.com/GeoWebCache/geowebcache/pull/747 (32 
commits, 102 modified files, 488 lines modified, 400 removed)
*   GeoServer: https://github.com/geoserver/geoserver/pull/3449 (74 
commits, 687 files modified, 2490 lines modified, over 6000 removed)

The GeoTools and GeoWebCache PRs are green, the GeoServer one fails because of 
classes not implementing any longer methods that were

deprecated, it should go green once the other two are merged.

The PRs are breaking, so merging one of them will cause downstream projects 
builds to fail, they are meant to be merged together.

 

In terms of mechanics, no new tool has been used, the java compiler itself has 
been instructed to fail the compile in case of deprecated

API usage.

 

In terms of stability of the changes, I did the best I could, but you can see 
from the numbers of the PRs that this

has a been a sizable one man code sprint, so it's unlikely that it won't have 
any kind of side effect

Just like after every other code sprint, I expect some cleanup to follow after 
merge, once we have the code deployed and running on some server

(thankfully GeoSolutions has one server deploying a fresh master nightly build 
3 times a day, we should get some early feedback from it soon).

 

Now, there are a few things that I'd need out of you (well, some of you!):

*   Trying out the 3 builds in a sequence, to double check everything is 
fine, as Travis cannot provide guarantees for the GeoServer one)
*   Review and improvements to the PRs (all core devs can commit directly 
on my branch, anyone else can do PRs)
*   If you have a project that depends on GeoTools, GeoWebCache or 
GeoServer, try to build it against the branches and provide feedback (in case 
of doubt about a missing API, you can check the stable branch and get the same 
deprecated API direction I used)
*   Feedback, discussion, concerns? Let me know!

Ah... want to know something more about what I've found during the cleanup? 
Lots, with many things worth cursing about, including:

*   Deprecated methods/objects with no comment and no replacement 
*   Deprecations in implementation classes but the interface mandates the 
method without deprecating it
*   Deprecations pointing to replacement that are also deprecated and with 
no replacement
*   Quoting: "@deprecated Replacement to be determined." Seriously?
*   Deprecating API, providing replacement, and leaving hundreds of calling 
points in the codebase, losing the best occasion to check if the deprecation 
and replacement actually make sense (somtimes all you need it to call the 
replacement method and do a inline refactor)
*   Deprecated with replacement indications making no sense to a random 
reader (aka me). Remember to be clear, deprecation is not a reminder to 
yourself but something affecting users which need to move to a non deprecated 
approach.
*   Deprecating object/method because normally it should not be used, but 
there are some legit cases to do so... just add a comment for it instead of 
deprecating
*   Deprecating a method because maybe in the future you will remove it 
(there were such deprecations 10+ years old, face it, you're not clairvoyant)

Once the branches are in, the built-in compile 

Re: [Geoserver-devel] April release train starting

[bradh]

PDF manual has right version and a lot of pages.

 

Deployed the .war on tomcat9 on geoserver 19.04 with default JVM (openjdk 
11.0.3).

 

Restarted – runs up OK. Logged in, expected UI shows.

 

Tasmania and NYC layer previews work OK. 

Spearfish layers show a ServiceException (NullPointerException). <-- Problem

 

The GetCapabilities all work.

Tried a couple of demo requests and the WCS builder, seems fine.

 

In the logs, when I try a spearfish layer:

2019-04-26 17:35:41,548 INFO [geoserver.wms] - 

Request: getServiceInfo

2019-04-26 17:35:42,959 ERROR [geoserver.ows] - 

java.lang.NullPointerException

at 
org.geoserver.wms.MapLayerInfo.getOtherStyleNames(MapLayerInfo.java:213)

at 
org.geoserver.wms.map.AbstractOpenLayersMapOutputFormat.styleNames(AbstractOpenLayersMapOutputFormat.java:277)

at 
org.geoserver.wms.map.AbstractOpenLayersMapOutputFormat.produceMap(AbstractOpenLayersMapOutputFormat.java:112)

at 
org.geoserver.wms.map.OpenLayersMapOutputFormat.produceMap(OpenLayersMapOutputFormat.java:60)

at 
org.geoserver.wms.map.OpenLayersMapOutputFormat.produceMap(OpenLayersMapOutputFormat.java:21)

at org.geoserver.wms.GetMap.executeInternal(GetMap.java:707)

at org.geoserver.wms.GetMap.run(GetMap.java:287)

at org.geoserver.wms.GetMap.run(GetMap.java:110)

at 
org.geoserver.wms.DefaultWebMapService.getMap(DefaultWebMapService.java:251)

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:566)

at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)

at 
org.geoserver.kml.WebMapServiceKmlInterceptor.invoke(WebMapServiceKmlInterceptor.java:38)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

at 
org.geoserver.gwc.wms.CacheSeedingWebMapService.invoke(CacheSeedingWebMapService.java:55)

at 
org.geoserver.gwc.wms.CacheSeedingWebMapService.invoke(CacheSeedingWebMapService.java:31)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

at 
org.geoserver.gwc.wms.CachingWebMapService.invoke(CachingWebMapService.java:72)

at 
org.geoserver.gwc.wms.CachingWebMapService.invoke(CachingWebMapService.java:52)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

at 
org.geoserver.ows.util.RequestObjectLogger.invoke(RequestObjectLogger.java:50)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)

at com.sun.proxy.$Proxy67.getMap(Unknown Source)

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:566)

at org.geoserver.ows.Dispatcher.execute(Dispatcher.java:877)

at 
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:264)

at 
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:177)

at 
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:52)

at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1038)

at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942)

at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:998)

at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:890)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)

at 
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:875)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)

at 

Re: [Geoserver-devel] geoserver 2.15.0 artifacts ready for testing

[bradh]

I am clearly pretty late to the party, but I tested a fresh install of Ubuntu 
18.04.02 and Ubuntu 19.04 (nightly) with tomcat8 and geoserver.war. No plugins 
attempted.

 

Did some layer previews, a few random GetCapabilities. No problems noted with 
either configuration.

 

Thanks for the release work.

 

Brad

 

From: Jody Garnett  
Sent: Friday, 1 March 2019 2:32 AM
To: Rahkonen Jukka (MML) 
Cc: GeoServer 
Subject: Re: [Geoserver-devel] geoserver 2.15.0 artifacts ready for testing

 

Thanks! I will hit the next stage then, and ask Andrea to publish the blog 
post.  

 

On Wed, Feb 27, 2019 at 11:54 PM Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi> > wrote:

Windows installer tested on Windows 10 and JRE 8, 32-bit by using default 
settings. Success.

 

-Jukka Rahkonen-

 

Lähettäjä: Jody Garnett mailto:jody.garn...@gmail.com> 
> 
Lähetetty: keskiviikko 27. helmikuuta 2019 22.09
Vastaanottaja: GeoServer mailto:geoserver-devel@lists.sourceforge.net> >
Aihe: Re: [Geoserver-devel] geoserver 2.15.0 artifacts ready for testing

 

I have tested the bin release, is anyone else in position to test?


--

Jody Garnett

 

 

On Tue, 26 Feb 2019 at 22:10, Jody Garnett mailto:jody.garn...@gmail.com> > wrote:

Release artifacts are available here:

- https://build.geoserver.org/geoserver/release/2.15.0/

 

Blog post draft also created; review required before publication.


--

Jody Garnett

-- 

--

Jody Garnett

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

Re: [Geoserver-devel] PSC: GeoServer 2019 Budget request

[bradh]

+0. Do we need to bid for sprint funding for the post-contract activity?

 

Brad

 

From: Jody Garnett  
Sent: Monday, 21 January 2019 8:10 AM
To: GeoServer 
Subject: [Geoserver-devel] PSC: GeoServer 2019 Budget request

 

After feedback and revision via email and chat we have:

*   https://wiki.osgeo.org/wiki/GeoServer_Budget_2019

The board meeting tomorrow will be looking at the above page, please have a 
read and +1/0/-1 as needed.


--

Jody Garnett

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

Re: [Geoserver-devel] TeamEngine Docker (was GeoServer 2019 budget)

[bradh]

Thanks for raising the ticket, but I think the missing deps were expected 
(noted in the teamengine-docker README).

 

I also hit the lack of deps so wanted to simplify the docker image build if 
possible, but also some prioritisation / narrowing of the tests might help us 
to focus the effort. If you had to pick a top 3 or 5, what tests are most 
important?

 

Brad

 

From: Andrea Aime  
Sent: Sunday, 13 January 2019 7:45 PM
To: Brad Hards 
Cc: Jody Garnett ; GeoServer 

Subject: Re: TeamEngine Docker (was GeoServer 2019 budget)

 

On Sat, Jan 12, 2019 at 11:50 PM mailto:br...@frogmouth.net> > wrote:

I took a look at the docker tools, and it looks like we can build an 
“everything” docker image, or a docker image per test suite. The process is 
slightly annoying, perhaps we want to publish our versions of the tests to an 
OSGEO Maven repo.

We don’t really care about “everything” in terms of ETS, 

 

We definitely don't want to run every test. But do we have to?

If building a custom docker image takes work, how bad would it be to build an 
image with everything, deploy it, and run just the tests we want?

I tried and the build failed due to lack of deps, I've inquired with OGC about 
their availability:

https://github.com/opengeospatial/teamengine-docker/issues/26

 

Anyhow, thinking out loud (and let's verify if feasible):

*   We build the full VM (or a custom one), ideally with a Jenkins build 
that updates, builds, and redeploys the image, possibly adding a well known 
user into it.
*   The image could be left running, or started up on demand
*   The tests are run periodically using the REST API

The advantage of using our own image are, in my mind:

*   No network latency, faster tests
*   No dependency on remote server avalability (think downtimes, upgrades, 
maintenance)
*   Better control on what we run, and have liberty on eventually using a 
custom version of some suite (version numbers are properties)

Control is an important bit for the feasibility of this approach, as we can do 
the upgrades when we can allocate time to also handle the fixes/adjustments to 
our code, the deploy data and configuaration, and the eventual CITE tests fixes

 

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. 

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

[Geoserver-devel] TeamEngine Docker (was GeoServer 2019 budget)

[bradh]

I took a look at the docker tools, and it looks like we can build an 
“everything” docker image, or a docker image per test suite. The process is 
slightly annoying, perhaps we want to publish our versions of the tests to an 
OSGEO Maven repo.

We don’t really care about “everything” in terms of ETS, so it might help to 
narrow the problem if we can exclude and prioritise tests suites (either for 
the "everything" case, or for per-suite docker images).

As a starting point for discussion, here is my opinion, noting that some of the 
DGIWG and NSG stuff might be "special case". From (one of) the pom.xml:

1.13 - Priority 2

1.12 - Priority 2

1.12 - Priority 2

1.12 - Priority 2

1.32 - Priority 2

1.29 - Priority 1

0.1-SNAPSHOT - Priority 4

1.16 - Priority 1

1.24 - Priority 1

1.1 - Priority 3

1.17 - Priority 3

1.1 - No support?

1.25 - Priority 4

1.0 - Priority 3

0.3 - Priority 4

1.12 - Priority 3

0.5 - No support?

0.1 - No support?

0.8 - No support

0.8 - No support

1.6 - No support

1.4 - No support

1.13 - No support

1.13 - No support

1.7 - No support

1.10 - No support

1.0 - No support

1.3 - Priority 4

0.6 - Priority 3

0.4 - No support?

0.4 - No support?

0.1 - No support?

0.3 - No support?

0.2 - No support?

0.3 - No support?

0.1-SNAPSHOT - No 
support?
 



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

Re: [Geoserver-devel] GeoServer 2.13.4 pre-release artifacts ready for testing

[bradh]

User manual PDF looks OK, has the right version.

User and developer HTML manuals look OK, have the right version.

Javadoc HTML looks OK, has the right version.

 

Booted the WAR on Ubuntu 18.04. Versions look reasonable. Did some light 
checking of GetCapabilities, layer previews.

 

No problems noted.

 

Brad

 

From: Andrea Aime  
Sent: Sunday, 23 December 2018 1:29 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] GeoServer 2.13.4 pre-release artifacts ready for 
testing

 

Hi all,

the 2.13.4 pre-release artifacts are available here:

https://build.geoserver.org/geoserver/release/2.13.4/

 

At the time of writing the windows installer is not there yet, but should be 
incoming.

 

Anyone wants to give it a kick?

 

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. 

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

Re: [Geoserver-devel] Reminder: GeoTools/GeoServer meeting at 19:30 UTC tomorrow

[bradh]

Even if I could occasionally make 0630 (which will revert to 0530 once daylight 
savings ends here), I’m not really awake enough to contribute much. So optimise 
for those doing most of the work (hence needing most of the coordination), and 
I’ll do what I can to match that if I’m travelling.

 

Brad

 

From: Andrea Aime  
Sent: Tuesday, 11 December 2018 4:52 AM
To: Torben Barsballe 
Cc: Geoserver-devel ; Geotools-Devel 
list 
Subject: Re: [Geoserver-devel] Reminder: GeoTools/GeoServer meeting at 19:30 
UTC tomorrow

 

On Mon, Dec 10, 2018 at 6:41 PM Torben Barsballe mailto:tbarsba...@boundlessgeo.com> > wrote:

https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting
 

 =2016=11=29=19=30=0=1

 

(There's been some discussion about moving this meeting to the earlier 16:00 
UTC timeslot, but no real consensus as of yet... assuming this is unchanged for 
now).

 

I'd like to hear from Brad if he's going to participate, given that 19:30 UTC 
seems to correspond to 6:30AM his time :-)

I'm all for keeping the meetings open to as many as possible, as long as the 
opportunity is actually used :-)

 

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. 

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

Re: [Geoserver-devel] Release train for 2.14.1 starting later this week

[bradh]

PDF, HTML and Javadoc download / unzip OK and have the 2.14.1 version number.

.war doesn’t start on tomcat8 with Oracle JDK 11 or OpenJDK 11 on Ubuntu. Looks 
like the problem is missing jaxb dependencies.
After fixing that, it starts up a bit further, but gives a backtrace that 
starts  with:
org.springframework.web.util.NestedServletException: Handler dispatch failed; 
nested exception is java.util.ServiceConfigurationError: 
org.geoserver.web.GeoServerNodeInfo: service type not accessible to unnamed 
module @2de2cc8a


It came up OK with openjdk8: Oracle Corporation: 1.8.0_181 (OpenJDK 64-Bit 
Server VM)

• GeoServer Version 2.14.1 
• Git Revision 40d642d60e6043f3d44deb26ac6172a4e885 
• Build Date 20-Nov-2018 02:04 
• GeoTools Version 20.1 (rev ef377c748a46efd4a84bfa0df939aac71ade0863) 
• GeoWebCache Version 1.14.1 (rev 
1.14.x/4bb10e75710629ad5571e69b75684cf49256ad67) 

I logged in, tried a couple of layer previews, checked that at least some of 
the GetCapabilities looked OK.

Added the WPS and CSW plugins, checked those capabilities worked. 

Seems OK based on initial smoke testing.



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

Re: [Geoserver-devel] GeoServer PSC: GeoSolutions proposal to use OSGeo UK funds for QGIS styling interoperability

[bradh]

Brad Hards: +1.

 

Assuming that the proposal is approved by the PSC (looks like we have enough 
votes, although I haven’t counted), and the proposing org accepts, I will add 
another US$1500. I trust the proposing org to judge whether to provide a better 
polished version of the proposed scope or additional features.

 

Brad

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

Re: [Geoserver-devel] propose change to meet schedule

[bradh]

3am or 4:30am or 6am isn’t really going to make any difference to me. I’d 
prefer something that worked really well for the majority than something that 
is a poor compromise for everyone.

 

I will occasionally make it (depending on travel and work commitments), so just 
do what works well for the other PSC members.

 

From: Jody Garnett  
Sent: Thursday, 15 November 2018 7:01 AM
To: Brad Hards 
Cc: GeoServer 
Subject: Re: [Geoserver-devel] propose change to meet schedule

 

good point brad, happy to withdraw the proposal.


--

Jody Garnett

 

 

On Tue, 13 Nov 2018 at 13:01, mailto:br...@frogmouth.net> 
> wrote:

I’m not going to make it (3am). That shouldn’t be a determinant on whether it 
works better for the majority though.

 

From: Jody Garnett mailto:jody.garn...@gmail.com> > 
Sent: Wednesday, 14 November 2018 6:48 AM
To: GeoServer mailto:geoserver-devel@lists.sourceforge.net> >
Subject: [Geoserver-devel] propose change to meet schedule

 

With our geographic dispersal rating taking a hit we discussed changing the 
meeting schedule in todays GeoServer / GeoTools meeting.

 

proposing:

- bi-weekly meeting

- 16:00 UTC

- half an hour meeting

 

The thinking being that we are meeting more often so the meeting can be 
shortened. 16:00 UTC does not need to adjust for daylight savings time. The 
bi-weekly meeting is a good pace to discuss items in person as they came up.

--

Jody Garnett

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

Re: [Geoserver-devel] Proposal: allow configuring services available for a given layer

[bradh]

+1 on the concept.

 

Is there a plan for a REST API for this?

 

For the backwards compatibility problem, I concur with the default approach for 
an existing data dir (preserve existing behaviour).

 

For the new service part of the problem (“Users plugging-in a new service while 
selective service configurations are already in place”), you could add a second 
interface that says whether the new service is enabled or disabled on layers by 
default. It seems unlikely that most developers would want opt-in for their 
shiny new service,  so its probably not worth the effort.

 

Brad

 

From: Andrea Aime  
Sent: Wednesday, 14 November 2018 1:05 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] Proposal: allow configuring services available for a 
given layer

 

Hi all,

here is a proposal to allow configuring OGC services available for a given 
layer (as an alternative to installing and configuring GeoFence):

 

https://github.com/geoserver/geoserver/wiki/GSIP-172---Allow-configuring-services-on-a-per-layer-basis

 

Please discuss, or if you're happy about it, vote? :-)

 

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. 

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

Re: [Geoserver-devel] propose change to meet schedule

[bradh]

I’m not going to make it (3am). That shouldn’t be a determinant on whether it 
works better for the majority though.

 

From: Jody Garnett  
Sent: Wednesday, 14 November 2018 6:48 AM
To: GeoServer 
Subject: [Geoserver-devel] propose change to meet schedule

 

With our geographic dispersal rating taking a hit we discussed changing the 
meeting schedule in todays GeoServer / GeoTools meeting.

 

proposing:

- bi-weekly meeting

- 16:00 UTC

- half an hour meeting

 

The thinking being that we are meeting more often so the meeting can be 
shortened. 16:00 UTC does not need to adjust for daylight savings time. The 
bi-weekly meeting is a good pace to discuss items in person as they came up.

--

Jody Garnett

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

Re: [Geoserver-devel] GeoServer builds and runs on JDK11

[bradh]

I tried the surefire upgrade and it worked fine locally (with JDK8). 

 

Put up https://github.com/geotools/geotools/pull/2102 to see what Travis and 
AppVeyor say.

 

Brad

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

Re: [Geoserver-devel] GeoServer builds and runs on JDK11

[bradh]

Nice work.

 

I had a quick look at the GWC changes. The lang3 and surefire upgrades look 
like they could go on master now. Also the oracle releases maven repo removal 
looks like it could go in.

That surefire upgrade is probably worth doing on other projects too.

 

We probably should find better matchers for the tests that are brittle to order 
and format. A bit more work now, but less churn when Java moves on again.

 

Brad

From: Andrea Aime  
Sent: Monday, 15 October 2018 5:39 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] GeoServer builds and runs on JDK11

 

Hi,

you have seen what this is about from the subject... before delving into the 
details, let's have a look at the results:

 

[INFO] Ysld GeoServer Plugin .. SUCCESS [ 15.820 s]

[INFO] MongoDB Data Store . SUCCESS [  0.803 s]

[INFO] REST SLD service ... SUCCESS [03:59 min]

[INFO] GeoFence security integration .. SUCCESS [01:19 min]

[INFO] GeoFence Server  SUCCESS [01:55 min]

[INFO] GeoServer Release Module 2.15-SNAPSHOT . SUCCESS [  0.820 s]

[INFO] 

[INFO] BUILD SUCCESS

[INFO] 

[INFO] Total time: 14:04 min (Wall Clock)

[INFO] Finished at: 2018-10-14T16:04:18+02:00

[INFO] 

~/devel/git-gs/src (jdk11_build) $ mvn -version

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
2018-02-24T20:49:05+01:00)

Maven home: /home/aaime/apps/apache-maven-3.5.3

Java version: 11, vendor: Oracle Corporation

Java home: /usr/lib/jvm/jdk-11

Default locale: it_IT, platform encoding: UTF-8

OS name: "linux", version: "4.15.0-34-generic", arch: "amd64", family: "unix"

 

(forget about that vendor indication, it's actually OpenJDK):

 

~/devel/git-gs/src (jdk11_build) $ java -version

openjdk version "11" 2018-09-25

OpenJDK Runtime Environment 18.9 (build 11+28)

OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

 

 



 

In order for the above to happen two PRs need to be applied, in addition to the 
ones already presented

for imageio-ext and geotools:

*   GeoWebCache: https://github.com/GeoWebCache/geowebcache/pull/695
*   GeoServer: https://github.com/geoserver/geoserver/pull/3182

As you can see by the numbers of commits in those two, it has not been as easy 
as with GeoTools and friends,

but the number of modified files is overall not big, nothing particularly fancy.

 

Bits worth noticing:

*   HashMap iteration order changed once more, a few tests needed to be 
amended
*   XML encoding of numbers and CDATA changed (different precision, 
different spacing around CDATA), some tests had to be amended
*   Changing the size of a thread pool at runtime incurs into stricter 
checks than before
*   GeoServerExtensions integration with SPI broke, I fell down on the 
GeoTools FactoryRegistry code, not sure if what was done is the best way to 
handle it, I'm open to suggestions: 
https://github.com/geoserver/geoserver/pull/3182/files#diff-8414b5ac2b07c761343e3d61d80cf320R154
 
*   The security LDAP module now builds (before it was trying to access a 
class that's truly gone due to a debugging statement in the embedded LDAP 
server being used), but tests do not run (get skipped) because now the embedded 
server won't start... even all I did was to bump it a couple of bugfix versions 
(bumping just one had the same result). That, and the newer version of the 
server is still a milestone and the spring ldap integration is declared not to 
work with it. Think we need someone that understands LDAP to make it actually 
run tests again.
*   Commons-lang3 had to be upgraded to the latest version, as some 
utilities triggered Java version number parsing and failed. No biggie, but GWC 
had to be upgraded from commons-lang 2, which makes up most of the file changes 
in the PR
*   Hazelcast has been upgraded to the latest version, which is a beta, but 
also the first run supposed to be running on JDK11. Still triggers some 
warnings, checking their issue tracker it seems at least some are being worked 
on before final release.

Going back to the performance topic the build times are a joke, using JDK8 and 
a "-T8" build I normally build on 7:30 to 8:00, with JDK11 it takes around 14 
minutes!

Are we screwed? We'll see, in the meantime I did a quick and silly benchmark 
against topp:states:

 

 ab -n 3600 -c 16  "http://localhost:8080/geoserver/topp/wms?SERVICE=WMS 

 

Re: [Geoserver-devel] Java 11 upgrade, looking for internal API usage

[bradh]

The slower tests shouldn’t be affected by the compiler right? 

 

So that means the *runtime* is noticeably slower. That isn’t good news. May 
need a plan follow-on activities for more performance-oriented stuff later. 
Maybe towards the end of the sprint we can work out a plan for tooling that 
could help on that.

 

Brad

 

From: Andrea Aime  
Sent: Saturday, 13 October 2018 8:04 PM
To: Jody Garnett 
Cc: Geoserver-devel 
Subject: Re: [Geoserver-devel] Java 11 upgrade, looking for internal API usage

 

On Fri, Oct 12, 2018 at 8:42 AM Andrea Aime mailto:andrea.a...@geo-solutions.it> > wrote:

That must of been a lot of warnings, or is the new compiler just slower? 

 

No idea, did not check, but it's something that we want to investigate, the 
time increase is just insane and going to badly affect our

productivity.

 

Compiler seems slower, jdk 8 builds geotools in 2:20 without tests on jdk8, but 
takes 3:35 in the same conditions on jdk 11... pff

However that means there is another ~1:30 lost running tests... it just seems 
slower overall

 

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. 

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

Re: [Geoserver-devel] proposal: Approve up to $1000 to support code sprint participants

[bradh]

+1

 

Brad

 

From: Jody Garnett  
Sent: Wednesday, 10 October 2018 7:41 AM
To: GeoServer 
Subject: [Geoserver-devel] proposal: Approve up to $1000 to support code sprint 
participants

 

I would like to ask the GeoServer PSC to approve the following proposal:

 

Approve up to $1000 to support code sprint participants.

 

Our budget for the year is outlined here 
  where we asked 
the that $1000 be made available for general project expenses. While I had kind 
of hoped to make our contributors tshirts funding this code sprint is far more 
important.

 

We tend to focus on technical proposals via GSIP, for this one can I ask PSC 
members to respond to the email by the end of the week Oct 12th:

*   Alessio Fabiani
*   Andrea Aime
*   Ben Caradoc-Davies
*   Brad Hards
*   Ian Turton
*   Jody Garnett +1 (Initial motion)
*   Jukka Rahkonen
*   Kevin Smith
*   Simone Giannecchini

--

Jody Garnett

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

Re: [Geoserver-devel] Travis CI build failure on hazelcast

[bradh]

Luca,

Please understand that the GeoServer project does not control the Travis
infrastructure.

I have restarted the build, but if that doesn't help, you can also
"resubmit" the CI build by closing and re-opening the PR.

Brad

-Original Message-
From: Luca Morandini  
Sent: Monday, 24 September 2018 10:23 AM
To: geoserver-devel@lists.sourceforge.net
Subject: [Geoserver-devel] Travis CI build failure on hazelcast

Folks,

I cannot complete a PR because Travis reports an error that does not seem
relate to my branch (GEOS-8933):

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 25:42 min (Wall Clock) [INFO] Finished at:
2018-09-24T00:10:06Z [INFO] Final Memory: 91M/326M [INFO]

[ERROR] Failed to execute goal com.coveo:fmt-maven-plugin:2.4.0:check
(default) on project gs-restconfig: Found 1 non-complying files, failing
build -> [Help 1] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project gs-wps-cluster-hazelcast: Compilation failure
[ERROR] error: error reading
/home/travis/.m2/repository/com/hazelcast/hazelcast/3.3.1/hazelcast-3.3.1.ja
r;
/home/travis/.m2/repository/com/hazelcast/hazelcast/3.3.1/hazelcast-3.3.1.ja
r
(Permission denied)

Could someone look into it?

Cheers,

Luca Morandini
Data Architect - AURIN project
Melbourne eResearch Group
School of Computing and Information Systems University of Melbourne Room
255.02, Level 2, 333 Exhibition St.
Melbourne, 3000 VIC
Skype: lmorandini
LinkedIn: https://www.linkedin.com/in/lmorandini



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



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

Re: [Geoserver-devel] [GSIP-164] Promoting geofence and geofence-server as extensions modules

[bradh]

Alessio: thanks – that answers my question and allays my concerns. I am still 
+1 in any case.

 

Brad

 

From: Alessio Fabiani  
Sent: Friday, 31 August 2018 10:43 PM
To: Brad Hards ; Emanuele Tajariol 
Cc: Andrea Aime ; Alessio Fabiani 
; Geoserver-devel 

Subject: Re: [Geoserver-devel] [GSIP-164] Promoting geofence and 
geofence-server as extensions modules

 

Dear all,

I agree that the test coverage might be indeed increased, nevertheless even if 
the percentage is not so high, notice that the core classes have a very good 
coverage.

 

As an instance the lower value (15%) on GeoFence module regards a package 
containing just POJOs used by the client to unmarshal instances through Spring 
Remoting. They are just plain classes representing some GeoFence objects ( 
org.geoserver.geofence.rest.xml).

 

On the other side most of the core classes have almost 100% coverage.

 

I would love (and for sure I will) add more tests on the rules and roles 
caching features and on the AuthenticationManager.

 

Until now the tests I have added should also cover:

 

1. The load of the context from spring

2. All the possible REST operations that can be done through the APIs

3. Most of the operations that currently are possible via the WEB GUI

 

For sue something missing would be:

 

1. More tests on the Limits filters by area

2. Tests on the possibility of making specific attributes 
hidden/read-only/writable

 

Especially for those two, manual testing of course has been done successfully. 
Automatic testing should be added.

 

If you think that it would be better to add them at this stage, I can spend 
some more time before promoting the module, otherwise I can collect all those 
observations on some specific JIRAs.

 

Thoughts? Feedbacks?

 

Also @Emanuele Tajariol    as the original author 
of the GSIP, what do you think about that?

 

Thanks everyone for dedicating time to this topic.

 

Alessio.

 

 

 

 

 

 

 

 

 

Il giorno sab 25 ago 2018 alle ore 01:21 mailto:br...@frogmouth.net> > ha scritto:

I should have noted I already added my vote on the GSIP. 

 

I was looking for Alessio’s opinion on the quality of the tests – test coverage 
(especially by line) isn’t the only thing that adds to value.

 

Brad

 

From: Andrea Aime mailto:andrea.a...@geo-solutions.it> > 
Sent: Saturday, 25 August 2018 12:02 AM
To: Brad Hards mailto:br...@frogmouth.net> >
Cc: Alessio Fabiani mailto:alessio.fabi...@geo-solutions.it> >; Geoserver-devel 
mailto:geoserver-devel@lists.sourceforge.net> >
Subject: Re: [Geoserver-devel] [GSIP-164] Promoting geofence and 
geofence-server as extensions modules

 

Hi Brad,

the test coverage requirements are indeed on the low side, maybe we should 
discuss a separate GSIP about increasing them.

But as far as rules go, Alessio's proposal is within them.

 

Cheers

Andrea

 

On Sat, Aug 18, 2018 at 3:38 AM mailto:br...@frogmouth.net> > wrote:

The proposal wiki page still says 2.13. Are you targeting 2.14 or 2.15?

 

Also code coverage still seems pretty low for a security feature. Are you 
satisfied that the important parts have appropriate validation?

 

Brad

 

From: Alessio Fabiani mailto:alessio.fabi...@geo-solutions.it> > 
Sent: Friday, 17 August 2018 1:57 AM
To: Geoserver-devel mailto:geoserver-devel@lists.sourceforge.net> >
Subject: [Geoserver-devel] [GSIP-164] Promoting geofence and geofence-server as 
extensions modules

 

Dear PSC,

recently I worked on making geofence modules stable and complete enough to be 
evaluated as official GeoServer extensions.

 

Currently I have updated the checklist here

 

https://github.com/geoserver/geoserver/wiki/GSIP-164

 

and pushed a set of PRs [1][2][3][4] resulting in the following code coverage 
results


 





 

[1] https://github.com/geoserver/geoserver/pull/3058

[2] https://github.com/geoserver/geoserver/pull/3052

[3] https://github.com/geoserver/geoserver/pull/3046

[4] https://github.com/geoserver/geoserver/pull/3024

 

-- 

==

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

@alfa7691
Founder/Technical Lead

 

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


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 

Re: [Geoserver-devel] [GSIP-164] Promoting geofence and geofence-server as extensions modules

[bradh]

I should have noted I already added my vote on the GSIP. 

 

I was looking for Alessio’s opinion on the quality of the tests – test coverage 
(especially by line) isn’t the only thing that adds to value.

 

Brad

 

From: Andrea Aime  
Sent: Saturday, 25 August 2018 12:02 AM
To: Brad Hards 
Cc: Alessio Fabiani ; Geoserver-devel 

Subject: Re: [Geoserver-devel] [GSIP-164] Promoting geofence and 
geofence-server as extensions modules

 

Hi Brad,

the test coverage requirements are indeed on the low side, maybe we should 
discuss a separate GSIP about increasing them.

But as far as rules go, Alessio's proposal is within them.

 

Cheers

Andrea

 

On Sat, Aug 18, 2018 at 3:38 AM mailto:br...@frogmouth.net> > wrote:

The proposal wiki page still says 2.13. Are you targeting 2.14 or 2.15?

 

Also code coverage still seems pretty low for a security feature. Are you 
satisfied that the important parts have appropriate validation?

 

Brad

 

From: Alessio Fabiani mailto:alessio.fabi...@geo-solutions.it> > 
Sent: Friday, 17 August 2018 1:57 AM
To: Geoserver-devel mailto:geoserver-devel@lists.sourceforge.net> >
Subject: [Geoserver-devel] [GSIP-164] Promoting geofence and geofence-server as 
extensions modules

 

Dear PSC,

recently I worked on making geofence modules stable and complete enough to be 
evaluated as official GeoServer extensions.

 

Currently I have updated the checklist here

 

https://github.com/geoserver/geoserver/wiki/GSIP-164

 

and pushed a set of PRs [1][2][3][4] resulting in the following code coverage 
results


 





 

[1] https://github.com/geoserver/geoserver/pull/3058

[2] https://github.com/geoserver/geoserver/pull/3052

[3] https://github.com/geoserver/geoserver/pull/3046

[4] https://github.com/geoserver/geoserver/pull/3024

 

-- 

==

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

@alfa7691
Founder/Technical Lead

 

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


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.

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

Re: [Geoserver-devel] Proposing Steve Ikeoka for commit rights

[bradh]

+1 from me too.

 

From: Andrea Aime  
Sent: Wednesday, 22 August 2018 4:20 AM
To: Geoserver-devel ; sikeoka 

Subject: [Geoserver-devel] Proposing Steve Ikeoka for commit rights

 

Hi all,

I'm writing to propose Steve Ikeoka, cc'ed, for commit rights on the GeoServer 
repository.

Steve has made a significant number of pull requests (47 merged, 1 in queue, 
see [1]),

and properly aligned with the contribution guidelines.

 

Please discuss and/or vote :)

 

Cheers

Andrea

 

[1] https://github.com/geoserver/geoserver/pulls/sikeoka


 

-- 

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. 

--
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] GeoServer 2.12.5 artifacts available for testing

[bradh]

I downloaded and smoke tested the WAR on Tomcat8.

*   GeoServer Version 2.12.5 
*   Git Revision 7190246d22191fc81c4630f8e5d71eaa7ba74057 
*   Build Date 20-Aug-2018 22:46 
*   GeoTools Version 18.5 (rev fd3cdc83359516506d5c2fec602c36cc66e0f31b) 
*   GeoWebCache Version 1.12.5 (rev 
1.12.x/20078bd305cebc790a5a458769087c776cfbba14) 

Added the CSW plugin and verified present

 

Checked some layer preview for vector and raster, openlayers and PNG.

 

Tried a couple of demo requests and WCS builder examples.

 

Not very comprehensive testing, but all as expected.

 

Brad

 

From: Torben Barsballe  
Sent: Tuesday, 21 August 2018 9:27 AM
To: geoserver-devel 
Subject: [Geoserver-devel] GeoServer 2.12.5 artifacts available for testing

 

GeoServer 2.12.5 artifacts are available for testing here: 
https://build.geoserver.org/geoserver/release/2.12.5

 

Any help testing is appreciated.

 

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] Reminder: GeoTools / GeoServer meeting at 15:30 UTC on Tuesday

[bradh]

Please accept my apologies - 0130 in my time zone isn't achievable at the
moment.

Brad

-Original Message-
From: Ben Caradoc-Davies  
Sent: Tuesday, 7 August 2018 6:04 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] Reminder: GeoTools / GeoServer meeting at 15:30
UTC on Tuesday

GeoTools / GeoServer committee meeting on Skype at 15:30 UTC on Tuesday:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+/+GeoServ
er+Meeting=2018=8=7=15=30=0=1

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


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


--
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] Promoting SLDservice community module to extension

[bradh]

I’m +0 on this. Are you actually looking for votes on the GSIP at this time?

 

Brad

 

From: Mauro Bartolomeoli  
Sent: Wednesday, 1 August 2018 1:12 AM
To: Geoserver-devel 
Subject: Re: [Geoserver-devel] Promoting SLDservice community module to 
extension

 

GSIP is here: https://github.com/geoserver/geoserver/wiki/GSIP-170

 

Mauro

 

 

Il giorno dom 29 lug 2018 alle ore 22:05 Andrea Aime 
mailto:andrea.a...@geo-solutions.it> > ha 
scritto:

Gsssipit!

 

Cheers

Andrea

 

Il Ven 27 Lug 2018, 19:21 Mauro Bartolomeoli 
mailto:mauro.bartolome...@geo-solutions.it> > ha scritto:

Hi, I would like to propose SLDservice promotion to extension.

 

Some of the requirements for promotion:

 

- [x] The modules have at least a "handful" of users: recent interest in 
improvements to the module show that some people are using it.

- [x] The modules have a designated and active maintainer: I contributed 
several improvements recently, and would like to become the mantainer of the 
module.

- [ ] The modules are considered "stable" by the majority of the PSC.

- [x] The modules maintain 40% test coverage: (about 41% with Jacoco)

- [x] The modules have no IP violations.

- [x] The module has a page in the user manual:

- [x] The maintainer (Mauro Bartolomeoli) has signed the GeoServer Contributor 
Agreement, also as a maintaner of other GeoServer features (WMTS cascading).

 

If no objection arise, I would proceed creating a GSIP for this.


 

-- 

Regards,

Mauro Bartolomeoli

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

Dott. Mauro Bartolomeoli
@mauro_bart
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy

mobile: +39 393 904 1756
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.

 

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

Mauro Bartolomeoli

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

Dott. Mauro Bartolomeoli
@mauro_bart
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy

mobile: +39 393 904 1756
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.

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 

Re: [Geoserver-devel] [Geotools-devel] Reminder: GeoTools / GeoServer meeting at 19:30 UTC on Tuesday

[bradh]

Sorry, still a bit early in my time zone.

Brad

-Original Message-
From: Ben Caradoc-Davies  
Sent: Tuesday, 24 July 2018 7:08 AM
To: Geotools-Devel list 
Subject: [Geotools-devel] Reminder: GeoTools / GeoServer meeting at 19:30
UTC on Tuesday

GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+/+GeoServ
er+Meeting=2018=7=24=19=30=0=1

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


--
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-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
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] Thinking out loud... should the next GeoServer be "GeoServer 22.0"?

[bradh]

Just that Andrea suggested the next version of GeoServer be 22.0 (see Subject 
line) with some pseudo-math support argument. I'm not particularly worried 
about what we call it (GS 20.0 works for me), but consistency would be helpful.

-Original Message-
From: Ben Caradoc-Davies  
Sent: Friday, 13 July 2018 9:35 AM
To: br...@frogmouth.net; 'Andrea Aime' ; 
'Geoserver-devel' 
Subject: Re: [Geoserver-devel] Thinking out loud... should the next GeoServer 
be "GeoServer 22.0"?

I do not understand why 22.0. I could understand 2.14.0 -> 14.0 (like
Solaris) and then max(GT_VERSION, GS_VERSION). Is 22.0 a typo, or /r/wsh?

On 13/07/18 11:21, br...@frogmouth.net wrote:
> Or the next geotools is 22.0. Version numbers are pretty cheap, wasting a few 
> isn't a big deal.
> 
> -Original Message-
> From: Ben Caradoc-Davies 
> Sent: Friday, 13 July 2018 9:06 AM
> To: br...@frogmouth.net; 'Andrea Aime' ; 
> 'Geoserver-devel' 
> Subject: Re: [Geoserver-devel] Thinking out loud... should the next GeoServer 
> be "GeoServer 22.0"?
> 
> On 13/07/18 10:13, br...@frogmouth.net wrote:
>> Having geoserver and geotools use the same version numbers would probably be 
>> easier to remember.
> 
> This. Which would make the next GeoServer 20.0. GeoWebCache could get the 
> same treatment.
> 
> Unless we want to call them all 2018.10 (given that 18.x is already in 
> the past).  :-P
> 
> Kind regards,
> 
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited  New Zealand
> 
> 

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


--
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] Thinking out loud... should the next GeoServer be "GeoServer 22.0"?

[bradh]

Slightly tangential: The date-based thing might work well if we're going to do 
the Enterprise versioning packaging.

-Original Message-
From: Ben Caradoc-Davies  
Sent: Friday, 13 July 2018 9:06 AM
To: br...@frogmouth.net; 'Andrea Aime' ; 
'Geoserver-devel' 
Subject: Re: [Geoserver-devel] Thinking out loud... should the next GeoServer 
be "GeoServer 22.0"?

On 13/07/18 10:13, br...@frogmouth.net wrote:
> Having geoserver and geotools use the same version numbers would probably be 
> easier to remember.

This. Which would make the next GeoServer 20.0. GeoWebCache could get the same 
treatment.

Unless we want to call them all 2018.10 (given that 18.x is already in the 
past).  :-P

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


--
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] Thinking out loud... should the next GeoServer be "GeoServer 22.0"?

[bradh]

Or the next geotools is 22.0. Version numbers are pretty cheap, wasting a few 
isn't a big deal.

-Original Message-
From: Ben Caradoc-Davies  
Sent: Friday, 13 July 2018 9:06 AM
To: br...@frogmouth.net; 'Andrea Aime' ; 
'Geoserver-devel' 
Subject: Re: [Geoserver-devel] Thinking out loud... should the next GeoServer 
be "GeoServer 22.0"?

On 13/07/18 10:13, br...@frogmouth.net wrote:
> Having geoserver and geotools use the same version numbers would probably be 
> easier to remember.

This. Which would make the next GeoServer 20.0. GeoWebCache could get the same 
treatment.

Unless we want to call them all 2018.10 (given that 18.x is already in the 
past).  :-P

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


--
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] Thinking out loud... should the next GeoServer be "GeoServer 22.0"?

[bradh]

I would suggest adopting semantic versioning, which means everything will be 
major versions (because of the geotools versioning). Having geoserver and 
geotools use the same version numbers would probably be easier to remember.

 

I do get Chris’ concern (its mainly a US DoD thing – version numbers define the 
amount of testing and the authorities / paper work required; makes no sense at 
all, just policy). One work around could be an “Enterprise GeoServer” product 
(which could have some / all of the extensions bundled into the war.zip / 
-bin.zip) and uses a 1.0.aMxb (where Mx is “maintenance release”). Then a is 
the major release and b is the minor release versions. Would that work for you 
Chris?

 

From: Andrea Aime  
Sent: Friday, 13 July 2018 2:33 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] Thinking out loud... should the next GeoServer be 
"GeoServer 22.0"?

 

Hi,

thinking out loud, so don't take me too seriously but... should we follow the 
GeoTools example and

switch GeoServer version numbering to a "x.y" approach, just like GeoTools did?

 

I keep on having people asking me things like "but is Geoserver 2.13.1 much 
different than 2.8.3?"

Heck yes, it's years of development in between... it's a major jump, even if 
the number may not make

it look like that.

 

GeoServer 1.x ended at 1.7, so GeoServer 2.14.0 should likely be renamed to 22 
(7 + 14 + 1, counting

also 2.0.0 in the mix).

 

We were keeping 3.x for a "epic storm" kind of change, but even when we 
switched to 2.x we maintained

seamless upgrades, so I guess it's not just in our style to do that kind of 
change, and we can probably

drop the "2."

 

Opinions?

 

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. 

--
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] Permission to create Quality of Service Community Module

[bradh]

No objections to the community module.

 

It looks like the standards work is still in progress. Is this intended to move 
out of community module land after the standard is finalised? Would it be an 
extension or folded in to the main WMS / WFS code base?

 

Brad

 

From: fernando.m...@geo-solutions.it  
Sent: Friday, 6 July 2018 2:21 PM
To: geoserver-devel@lists.sourceforge.net
Subject: [Geoserver-devel] Permission to create Quality of Service Community 
Module

 


Hi Geoserver PSC and dev community, I hope all of you are doing well.

This email is for to request permission to create a community module (likely 
named "gs-qos") that provides OGC Quality of Service Getcapabilities metadata 
for WMS and WFS.

I wrote a proposal with detailed information about how this new module would 
work, any comment is welcome:

QoS Proposal 
  

 
Thanks, and have a nice day.
 

 

Regards,

Fernando Mino

==

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

==

Fernando Mino

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.

 

--
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] GeoServer: self deleting layers/featuretypes

[bradh]

This might have been better posted to geoserver-users, but presumably
whatever does the setup could just add a cron job to do a REST API delete
later. 

Brad



--
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] Integrating App-Schema and Apache Solr

[bradh]

I was more thinking about this as an output format / representation of the 
complex feature. As a future consideration (if we ever had time) your work 
could be extended to automatically infer a mapping definition from the 
geopackage with related tables.

 

Brad

 

From: Nuno Oliveira  
Sent: Friday, 1 June 2018 5:55 AM
To: br...@frogmouth.net; 'Geoserver-devel' 
; 'GeoTools Developers' 

Subject: Re: [Geoserver-devel] Integrating App-Schema and Apache Solr

 

Ah! my apologies Brad your reply got lost in the mail flow :(
That's an interesting reference indeed, thank you. 

In this situation, I'm kind of tied to the App-Schema mappings files structure 
and the code that's does the work behind the scenes. 

Maybe in the future this could be used to provide an alternative syntax to the 
current App-Schema features chaining syntax, although the App-Schema chaining 
mechanism handle a few more complicated use cases ...

On 05/03/2018 02:59 PM, br...@frogmouth.net   wrote:

Hi Nuno,

 

I’m not sure if you’ve seen it, but there has been some work on adding related 
tables support to GeoPackage

This is public at http://www.geopackage.org/18-000.html (or 
https://github.com/jyutzler/geopackage-related-tables which is basically the 
source code for the spec).

 

If I got it right, this should provide for discoverable feature to feature(s) 
linkage, along with feature to attribute sets. Note that the original scope was 
feature-to-media (e.g. photos of a location), which is less applicable to 
app-schema. 

 

Brad

 

From: Nuno Oliveira   
 
Sent: Monday, 30 April 2018 3:01 AM
To: Geoserver-devel   
; GeoTools Developers  
 

Subject: [Geoserver-devel] Integrating App-Schema and Apache Solr

 

Dear all,
sorry for the cross posting on both mailing list ... but well App-Schema "as a 
leg" on both projects
and this may be interesting for people on both mailing lists.

... and my apologies for the wall of text that follows ... what can I say 
complex features are really
a complex subject :) 

Lately I have been working in integrating App-Schema with Apache Solr [1] which 
is a well know
solution for indexing and (faceting) searching document. 

We already have an Apache Solr store in both GT and GS, configuring a layer for 
it requires the user
to provide some extra information, e.g. which index fields should be 
considered, should multivalued 
fields be used, should empty fields be used and which is attribute should be 
considered the 
default geometry.

The first step for the integration between Apache Solr and App-Schema is to 
allow App-Schema to
use Apache Solr has it one of its data store. When in the context of App-schema 
we already have 
most of the information we need, we already say indirectly through the mappings 
which fields of 
the index we are interested in, which ones are multivalued (), etc 
...

The Apache-Solr data store configuration doesn't fit in the usual MAP 
parameters configuration
model ... and we also need to automatically detect during the parsing of the 
data stores 
configuration that we are dealing with an Apache Solr data store and do all the 
possible 
automatic steps.

I have come up with the following syntax for the Apache Sorl data store 
configuration, please find
the complete mappings file attached to this mail (mappings_solr.xml):

(...)


stations
http://localhost:8983/solr/stations


station_location
4326
POINT




(...)

All the other necessary information will be automatically inferred from the 
App-Schema mappings
file when possible, at the exception of multivalued fields. An Apache Solr 
multivalued field
handles \ contains multiple values for the same attribute.

Apache Solr multivalued fields are related with App-Schema multivalued fields, 
i.e. simple attributes
(String, numeric, dates, etc ...) that can be encoded multiple times. Currently 
in App-Schema
this attributes can be mapped using a denormalized data store (database) or 
using a specific 
feature chaining syntax when client properties are involved.

Here I would like to extend the App-Schema notion of multivalued attributes and 
allow each data 
data store to contribute a specific handler with a custom syntax has needed:

  * Apache Solr could use multivalued attributes
  * MongoDB could use JSON arrays
  * SQL could define explicit foreign key relation

Please find full examples of mappings using custom handlers attached to this 
mail (multi_*). For SQL
data stores the syntax looks like this:

(...)

st:comment

id
meteo_stations_comments
station_id
comment


(...)

A station can have multiple comment associated to it, this comment 

Re: [Geoserver-devel] GeoServer 2.13.1 Artifacts available for testing

[bradh]

PDF user manual looks OK: Reasonable version and date info, downloads fine and 
appears complete.

Booted WAR on tomcat 8 (Ubuntu 17.10). Looks fine:

• GeoServer Version 2.13.1 
• Git Revision cae7496cb49213c27458c47551fb4797d03825e0 
• Build Date 20-May-2018 00:44 
• GeoTools Version 19.1 (rev 5f248795f65bd55eb889f5803163e50479404bdd) 
• GeoWebCache Version 1.13.1 (rev 
1.13.x/e219127b6e89d08f40b0796852db0636bdc322a2) 

Logged in, has expected release data.
Checked some layer previews, checked some Capabilities. No problems noted.

Brad


--
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] Integrating App-Schema and Apache Solr

[bradh]

Hi Nuno,

 

I’m not sure if you’ve seen it, but there has been some work on adding related 
tables support to GeoPackage

This is public at http://www.geopackage.org/18-000.html (or 
https://github.com/jyutzler/geopackage-related-tables which is basically the 
source code for the spec).

 

If I got it right, this should provide for discoverable feature to feature(s) 
linkage, along with feature to attribute sets. Note that the original scope was 
feature-to-media (e.g. photos of a location), which is less applicable to 
app-schema. 

 

Brad

 

From: Nuno Oliveira  
Sent: Monday, 30 April 2018 3:01 AM
To: Geoserver-devel ; GeoTools 
Developers 
Subject: [Geoserver-devel] Integrating App-Schema and Apache Solr

 

Dear all,
sorry for the cross posting on both mailing list ... but well App-Schema "as a 
leg" on both projects
and this may be interesting for people on both mailing lists.

... and my apologies for the wall of text that follows ... what can I say 
complex features are really
a complex subject :) 

Lately I have been working in integrating App-Schema with Apache Solr [1] which 
is a well know
solution for indexing and (faceting) searching document. 

We already have an Apache Solr store in both GT and GS, configuring a layer for 
it requires the user
to provide some extra information, e.g. which index fields should be 
considered, should multivalued 
fields be used, should empty fields be used and which is attribute should be 
considered the 
default geometry.

The first step for the integration between Apache Solr and App-Schema is to 
allow App-Schema to
use Apache Solr has it one of its data store. When in the context of App-schema 
we already have 
most of the information we need, we already say indirectly through the mappings 
which fields of 
the index we are interested in, which ones are multivalued (), etc 
...

The Apache-Solr data store configuration doesn't fit in the usual MAP 
parameters configuration
model ... and we also need to automatically detect during the parsing of the 
data stores 
configuration that we are dealing with an Apache Solr data store and do all the 
possible 
automatic steps.

I have come up with the following syntax for the Apache Sorl data store 
configuration, please find
the complete mappings file attached to this mail (mappings_solr.xml):

(...)


stations
http://localhost:8983/solr/stations


station_location
4326
POINT




(...)

All the other necessary information will be automatically inferred from the 
App-Schema mappings
file when possible, at the exception of multivalued fields. An Apache Solr 
multivalued field
handles \ contains multiple values for the same attribute.

Apache Solr multivalued fields are related with App-Schema multivalued fields, 
i.e. simple attributes
(String, numeric, dates, etc ...) that can be encoded multiple times. Currently 
in App-Schema
this attributes can be mapped using a denormalized data store (database) or 
using a specific 
feature chaining syntax when client properties are involved.

Here I would like to extend the App-Schema notion of multivalued attributes and 
allow each data 
data store to contribute a specific handler with a custom syntax has needed:

  * Apache Solr could use multivalued attributes
  * MongoDB could use JSON arrays
  * SQL could define explicit foreign key relation

Please find full examples of mappings using custom handlers attached to this 
mail (multi_*). For SQL
data stores the syntax looks like this:

(...)

st:comment

id
meteo_stations_comments
station_id
comment


(...)

A station can have multiple comment associated to it, this comment are stored 
in meteo_stations_comments 
table which has a foreign key to stations  table base on columns id and 
station_id. The target value can be an
OCQL expression.

In the case of Apache Solr the syntax would look like this:

(...)

st:comment
station_comment

(...)

I have a prototype of all of this already working, all of the things above 
required creating a few extensions
points in App-Schema:

* in the mappings configuration parsing module to handle the custom syntaxes of 
each data store 
* in the App-Schema feature iterator to give a chance to custom handlers to do 
their job

This changes open the doors to the usage of non relational data stores with 
App-Schema and IMHO this syntaxes 
promote \ allow clearer mappings files, of curse this changes and new syntaxes 
will need to be clearly documented 
in the  App-Schema documentation. 

All comments about this are welcome.

Kind regards,

Nuno Oliveira



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

Re: [Geoserver-devel] Some funny discovery about time parsing: no more than 100 times!

[bradh]

Andrea,

 

I agree it’s a bug fix, but the reason we differentiate is mostly about 
stability. Maybe leave it a bit longer than a bug-fix backport and not as long 
as a feature release? Where it is on the scale is subjective, and I’m sure you 
can make that judgement better than any of us.

 

Brad

 

From: Andrea Aime  
Sent: Tuesday, 1 May 2018 3:01 AM
To: Ben Caradoc-Davies 
Cc: Geoserver-devel 
Subject: Re: [Geoserver-devel] Some funny discovery about time parsing: no more 
than 100 times!

 

On Wed, Apr 25, 2018 at 3:29 AM, Ben Caradoc-Davies  > wrote:

Andrea,

that definitely qualifies as a bug fix. An exception is much preferred over 
silent truncation.

 

Merged on master, but was not small and required many changes, also in the UI:

https://github.com/geoserver/geoserver/pull/2859/commits/51b17298fdcc3c2f63c89d421dfee01ff124764d

 

Now what, in terms of backport... is this a bug fix or a new feature? It's kind 
of both :)

 

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] GeoServer 2.12.3 pre-release artifacts ready for test

[bradh]

Andrea,

 

Thanks for the release work. I downloaded the war and htmldocs, booted the war 
on tomcat8:

*   GeoServer Version 2.12.3 
*   Git Revision 86938b34177ae82a43126a54babab2ab3df42863 
*   Build Date 22-Apr-2018 08:14 
*   GeoTools Version 18.3 (rev 6fda2a4abc4bf6b36032096ba418f61811901c28) 
*   GeoWebCache Version 1.12.3 (rev 
1.12.x/887e07552fd0b9dc834dbd4fe3cc644cf242ee74) 

Checked some capabilities, a few layer previews, logged in. Pretty light 
testing, no extension modules, but all looks good from what I tested – nothing 
objectionable in the logs.

 

Opened up the htmldocs, both developer and user look OK, have the right version 
number.

 

Brad

 

From: Andrea Aime  
Sent: Sunday, 22 April 2018 6:35 PM
To: Geoserver-devel 
Subject: [Geoserver-devel] GeoServer 2.12.3 pre-release artifacts ready for test

 

Hi,

if you have time, please give the 2.12.3 release artifacts a kick, and let us 
know if any major problem

shows up:

 

https://build.geoserver.org/geoserver/release/2.12.3/

 

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] Reminder: GeoTools / GeoServer meeting at 15:30 UTC on Tuesday

[bradh]

Please accept my apologies.

Brad



--
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] Codebase reformat using Google/AOSP format

[bradh]

+1 for the GeoServer part.

 

For the avoidance of doubt, I’m positive for doing it on geotools and 
geowebcache, but I’m not voting for those.

 

Brad

 

From: Andrea Aime  
Sent: Sunday, 15 April 2018 7:47 PM
To: Geotools-Devel list ; Geoserver-devel 
; geowebcache-devel 

Subject: [Geoserver-devel] Codebase reformat using Google/AOSP format

 

Hi all,

sorry for the cross posting, but this proposal is best applied on all projects 
toghether, and would

have the same contents on all projects (if really needed, I can copy/paste on 
GeoServer's wiki):

 

https://github.com/geotools/geotools/wiki/Codebase-Reformat


 

The last discussion and vote showed that everybody is comfortable with the AOSP 
format, so that's

the one that has been chosen.

 

Please vote :-)

 

Once voting is done we'll have to coordinate a bit in order to avoid major 
issues with pull request

merging (although I believe some work will end up having merge issues anyways, 
don't think we

can review and merge all outstanding pull requests).

 

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] Reminder: GeoTools / GeoServer meeting at 15:30 UTC on Tuesday

[bradh]

Please accept my apologies - can't make this time.

Brad

-Original Message-
From: Ben Caradoc-Davies  
Sent: Tuesday, 20 March 2018 6:34 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] Reminder: GeoTools / GeoServer meeting at 15:30
UTC on Tuesday

GeoTools / GeoServer committee meeting on Skype at 15:30 UTC on Tuesday:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+/+GeoServ
er+Meeting=2018=3=20=15=30=0=1

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


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


--
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] access to a layer's queryable flag through REST

[bradh]

I had a quick look at the code (not for 2.8.5, which is way too old - you
really should upgrade), and I don't see it referenced in the REST API. 

It could be added to the REST API or some other interface - feel free to
submit a PR or feature request. See
http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html
and
http://docs.geotools.org/latest/userguide/welcome/support.html#issue-tracker
for more guidance.

Brad



--
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] GSIP 165 - Add isolated workspaces concept to GeoServer, quick vote :)

[bradh]

+1.

There was one part of the GSIP:
It is only possible to create two or more workspaces with the same namespace in 
GeoServer if only one of them is non isolated, in the example above st2 is the 
isolated workspace.

Which I found a bit confusing.

Just so I'm clear, is the intent: "It is possible to create two or more 
workspaces with the same namespace in GeoServer if at most one of them is non 
isolated"?

That is, you can have two workspaces with the same namespaces if both of the 
workspaces are isolated?

Brad



--
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] Allowing access to HTTP headers from log patterns

[bradh]

+1. 

 

To me this seems like core diagnostics capability – if you need it on a machine 
where you’re doing differential diagnostics without direct access to it, then 
adding a plugin later is probably going to be difficult.

 

Brad

 

--
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] geoserver 2.12.2 preflight artifacts available for testing

[bradh]

I checked the war started on tomcat8 on Ubuntu 16.04, and did a few light 
checks. Added the CSW extension, checked it had a GetCapabilities.

 

GeoServer Version

2.12.2

Git Revision

c513fdd977af572e39712bcc425b0bcbf753f108

Build Date

23-Jan-2018 01:28

GeoTools Version

18.2 (rev 7e69b317326f940171e3c75dc8ffd2d60c6ec0d8)

GeoWebCache Version

1.12.2 (rev 1.12.x/8e746f758aabae3ab832c30757de6fafa4c39d0a)

 

Also fresh new JVM: Oracle Corporation: 1.8.0_151 (OpenJDK 64-Bit Server VM)

 

No issues noted.


Brad

From: Jody Garnett [mailto:jody.garn...@gmail.com] 
Sent: Tuesday, 23 January 2018 5:17 PM
To: GeoServer 
Subject: [Geoserver-devel] geoserver 2.12.2 preflight artifacts available for 
testing

 

Available here: https://build.geoserver.org/geoserver/release/2.12.2, and 
release notes 

 .

 

While I have tested the bin download, windows and mac require extra 
encouragement; perhaps during tomorrows meeting.

 

Andrea I included your requested revision.


--

Jody Garnett

--
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] Reminder: GeoTools / GeoServer meeting at 15:30 UTC on Tuesday

[bradh]

Please accept my apologies for this meeting.

-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Tuesday, 23 January 2018 6:32 AM
To: Geoserver-devel 
Subject: [Geoserver-devel] Reminder: GeoTools / GeoServer meeting at 15:30
UTC on Tuesday

GeoTools / GeoServer committee meeting on Skype at 15:30 UTC on Tuesday:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+/+GeoServ
er+Meeting=2018=1=23=15=30=0=1

--
Ben Caradoc-Davies 
Director
Transient Software Limited  New Zealand


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


--
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] KML/KMZ support broken?

[bradh]

If you need a quick fix for the swapped coordinates, this might help:

diff --git 
a/src/kml/src/main/java/org/geoserver/kml/sequence/PlainFolderSequenceFactory.java
 
b/src/kml/src/main/java/org/geoserver/kml/sequence/PlainFolderSequenceFactory.java

index c32e3280e..4a973aac5 100644

--- 
a/src/kml/src/main/java/org/geoserver/kml/sequence/PlainFolderSequenceFactory.java

+++ 
b/src/kml/src/main/java/org/geoserver/kml/sequence/PlainFolderSequenceFactory.java

@@ -113,8 +113,8 @@ public class PlainFolderSequenceFactory extends 
AbstractFolderSequenceFactory {

 }

 LatLonBox gobox = go.createAndSetLatLonBox();

-gobox.setEast(box.getMinX());

-gobox.setWest(box.getMaxX());

+gobox.setEast(box.getMaxX());

+gobox.setWest(box.getMinX());

 gobox.setNorth(box.getMaxY());

 gobox.setSouth(box.getMinY());

 }

 

(I’ll make the tests and turn that into a PR at some point after the ticket 
gets created).


Brad

 

From: br...@frogmouth.net [mailto:br...@frogmouth.net] 
Sent: Monday, 22 January 2018 9:59 PM
To: 'Idan Miara' 
Cc: 'Geoserver-devel' ; 'Andrea Aime' 

Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

I would agree that the LatLonBox values appear to be swapped in the 
GroundOverlay. This will occur in KML compressed or plain, but maybe not in 
network link. Can you please file a Jira ticket for that?

 

The Document/Folder structure is almost certainly valid, and lack of handling 
is a bug in QGIS (or some supporting library).

 

Brad

 

From: Idan Miara [mailto:i...@miara.com] 
Sent: Monday, 22 January 2018 9:36 PM
To: br...@frogmouth.net  
Cc: Andrea Aime  >; Geoserver-devel 
 >
Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

Hi Brad & Andrea

 

Thanks for your kind replys.

I can reproduce the problem with a fresh Geoserver platform independent zip 
installation (Master or 2.12.1, same results) as follows:

 

Layer Preview-> nurc:Img_Sample -> Select KML (compressed)

unzip nurc-Img_Sample.kmz. you will get wms.kml (attached) and a png raster.

 

Please note in this KML file: 

-130.85168

-62.0054

which is wrong becuse it should be swapped as west should be
I'm didn't read the KML spec, but As Andrea kindly noted, this might be a QGIS 
limitation.
Save as wms1.kml  (attached).

load it with QGIS, you will get the raster but horizontally swapped. I guess 
QGIS interperate east-130.85168

-62.0054

Save as wms2.kml  (attached).

wms2.kml loads perfectly fine in QGIS.

 

Note that all 3 files load correctly in Google Earth Pro.

 

 

Kind regards,

Idan

 

 

 

 

On 22 January 2018 at 02:21,  
> wrote:

Hi Idan,

 

Just to follow up on Andrea’s suggestions, I did some testing with a current 
GeoServer (master) build and 

Google Earth EC 7.3.0.3832 (32-bit) with some rasters from the standard release 
(nurc:ImgSample and nurc:Pk50095). They looked fine – definitely no reversed 
images, so its unlikely to be a general problem.

 

I did try downloading the KML but my QGIS 2.18.15 didn’t recognise it as a 
raster layer, and drag and drop resulted in empty attribute tables.

 

Brad

 

From: Andrea Aime [mailto:andrea.a...@geo-solutions.it 
 ] 
Sent: Monday, 22 January 2018 5:13 AM
To: Idan Miara  >
Cc: Geoserver-devel  >
Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

Hi Idan,

are you sure there is a bug in GeoServer and not a limitation in QGIS instead?

The second issue you report is definitely a problem in QGIS, a KML document can 
have whatever structure it wants, nesting

documents, layers and features as desired, see:

https://developers.google.com/kml/documentation/kmlreference

 

The issue with order of coordinates is also strange, as KML mandates a specific 
order (lon/lat) and we never received 

a complaint about it. It could be related to your particular TIFF?

Try to reproduce with a demo TIFF layer and let's see how that works (I wanted 
to have a look myself but I have no time).

 

Final note, unless you're interested in changing the GeoServer code yourself, 
this is the wrong list, your question

seems more like a GeoServer users list (asking there you'd also have a 4 times 
larger audience).

 

Cheers

Andrea

 

 

On Wed, Jan 17, 2018 at 2:34 PM, Idan Miara  > wrote:

Hi,

I'm trying to get a KMZ (KML compressed) file from Geoserver (2.12.1) and load 
it in 

Re: [Geoserver-devel] KML/KMZ support broken?

[bradh]

I would agree that the LatLonBox values appear to be swapped in the 
GroundOverlay. This will occur in KML compressed or plain, but maybe not in 
network link. Can you please file a Jira ticket for that?

 

The Document/Folder structure is almost certainly valid, and lack of handling 
is a bug in QGIS (or some supporting library).

 

Brad

 

From: Idan Miara [mailto:i...@miara.com] 
Sent: Monday, 22 January 2018 9:36 PM
To: br...@frogmouth.net
Cc: Andrea Aime ; Geoserver-devel 

Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

Hi Brad & Andrea

 

Thanks for your kind replys.

I can reproduce the problem with a fresh Geoserver platform independent zip 
installation (Master or 2.12.1, same results) as follows:

 

Layer Preview-> nurc:Img_Sample -> Select KML (compressed)

unzip nurc-Img_Sample.kmz. you will get wms.kml (attached) and a png raster.

 

Please note in this KML file: 

-130.85168

-62.0054

which is wrong becuse it should be swapped as west should be
I'm didn't read the KML spec, but As Andrea kindly noted, this might be a QGIS 
limitation.
Save as wms1.kml  (attached).

load it with QGIS, you will get the raster but horizontally swapped. I guess 
QGIS interperate east-130.85168

-62.0054

Save as wms2.kml  (attached).

wms2.kml loads perfectly fine in QGIS.

 

Note that all 3 files load correctly in Google Earth Pro.

 

 

Kind regards,

Idan

 

 

 

 

On 22 January 2018 at 02:21,  
> wrote:

Hi Idan,

 

Just to follow up on Andrea’s suggestions, I did some testing with a current 
GeoServer (master) build and 

Google Earth EC 7.3.0.3832 (32-bit) with some rasters from the standard release 
(nurc:ImgSample and nurc:Pk50095). They looked fine – definitely no reversed 
images, so its unlikely to be a general problem.

 

I did try downloading the KML but my QGIS 2.18.15 didn’t recognise it as a 
raster layer, and drag and drop resulted in empty attribute tables.

 

Brad

 

From: Andrea Aime [mailto:andrea.a...@geo-solutions.it 
 ] 
Sent: Monday, 22 January 2018 5:13 AM
To: Idan Miara  >
Cc: Geoserver-devel  >
Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

Hi Idan,

are you sure there is a bug in GeoServer and not a limitation in QGIS instead?

The second issue you report is definitely a problem in QGIS, a KML document can 
have whatever structure it wants, nesting

documents, layers and features as desired, see:

https://developers.google.com/kml/documentation/kmlreference

 

The issue with order of coordinates is also strange, as KML mandates a specific 
order (lon/lat) and we never received 

a complaint about it. It could be related to your particular TIFF?

Try to reproduce with a demo TIFF layer and let's see how that works (I wanted 
to have a look myself but I have no time).

 

Final note, unless you're interested in changing the GeoServer code yourself, 
this is the wrong list, your question

seems more like a GeoServer users list (asking there you'd also have a 4 times 
larger audience).

 

Cheers

Andrea

 

 

On Wed, Jan 17, 2018 at 2:34 PM, Idan Miara  > wrote:

Hi,

I'm trying to get a KMZ (KML compressed) file from Geoserver (2.12.1) and load 
it in QGIS (2.18.14).

The input raster is a RGB Tiff.

CRS: WGS84 Lat/Lon

The output KMZ that I get via the Layer preview is broken. 
I could fix it and load it successfully in QGIS in the following way if I edit 
the inner KML:

1. swap east and west (in the original kml east 
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 

Re: [Geoserver-devel] KML/KMZ support broken?

[bradh]

Hi Idan,

 

Just to follow up on Andrea’s suggestions, I did some testing with a current 
GeoServer (master) build and 

Google Earth EC 7.3.0.3832 (32-bit) with some rasters from the standard release 
(nurc:ImgSample and nurc:Pk50095). They looked fine – definitely no reversed 
images, so its unlikely to be a general problem.

 

I did try downloading the KML but my QGIS 2.18.15 didn’t recognise it as a 
raster layer, and drag and drop resulted in empty attribute tables.

 

Brad

 

From: Andrea Aime [mailto:andrea.a...@geo-solutions.it] 
Sent: Monday, 22 January 2018 5:13 AM
To: Idan Miara 
Cc: Geoserver-devel 
Subject: Re: [Geoserver-devel] KML/KMZ support broken?

 

Hi Idan,

are you sure there is a bug in GeoServer and not a limitation in QGIS instead?

The second issue you report is definitely a problem in QGIS, a KML document can 
have whatever structure it wants, nesting

documents, layers and features as desired, see:

https://developers.google.com/kml/documentation/kmlreference

 

The issue with order of coordinates is also strange, as KML mandates a specific 
order (lon/lat) and we never received 

a complaint about it. It could be related to your particular TIFF?

Try to reproduce with a demo TIFF layer and let's see how that works (I wanted 
to have a look myself but I have no time).

 

Final note, unless you're interested in changing the GeoServer code yourself, 
this is the wrong list, your question

seems more like a GeoServer users list (asking there you'd also have a 4 times 
larger audience).

 

Cheers

Andrea

 

 

On Wed, Jan 17, 2018 at 2:34 PM, Idan Miara  > wrote:

Hi,

I'm trying to get a KMZ (KML compressed) file from Geoserver (2.12.1) and load 
it in QGIS (2.18.14).

The input raster is a RGB Tiff.

CRS: WGS84 Lat/Lon

The output KMZ that I get via the Layer preview is broken. 
I could fix it and load it successfully in QGIS in the following way if I edit 
the inner KML:

1. swap east and west (in the original kml east 
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 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 

Re: [Geoserver-devel] Speeding up the GeoServer build by splitting some modules

[bradh]

I certainly have no objections to things being faster.

 

My only concern was on the geotools side, if there was an API change. I don’t 
see that as a consideration on geoserver though (application vs library).

 

I’m not really able to help with it at the moment though, although I may be 
able to apply some test effort.

 

Brad

 

From: Andrea Aime [mailto:andrea.a...@geo-solutions.it] 
Sent: Saturday, 14 October 2017 2:30 AM
To: Geoserver-devel 
Subject: Re: [Geoserver-devel] Speeding up the GeoServer build by splitting 
some modules

 

Hi,

as with the thread on geotools-devel, there seems to be a distinct lack of 
enthusiams

for the topic.

Can at least get a sense if there are people opposed to the changes I'm 
proposing?

I'd like to know before starting to split modules apart :-)

 

Cheers

Andreda

 

 

On Wed, Oct 11, 2017 at 6:36 PM, Andrea Aime  > wrote:

Hi,

following up the geotools-devel thread on speeding up the build, I've made some 
checks on 

GeoServer as well.

 



Please let's not start a discussion about tests being integration and thus 
slow, we all know that,

but I'm trying to discuss something that can be done with limited resources 
here,

not planning the next 10 years of development or selling an idea for the next 
code sprint :-)

(it's a fair conversation topic, if you want to start it please just do so in a 
separate mail thread).



 

Compared to GeoTools the build takes longer because, among other reasons, it 
parallelizes a lot less.

The "chain of death" keeping the build in low parallel mode is, roughly:

main->wfs->wms->restconfig->app-schema-test

 

The main module takes here 1:20, and everything else depends on it. A large 
chunk of that time is

spent running security related tests.

I'm only semi serious here, but as far as I can see, it could be beneficial to 
move the securty

tests to their own module (e.g., security/core) while leaving the security 
classes in main.

I'm just semi-serious because I realize splitting apart the classes and their 
tests is not that great,

but at the same time, it could easily shave off 30-60 seconds off the critical 
path.

 

The WMS dependency onto WFS is hard to un-tangle, I've tried already some years 
ago and

eventually gave up, it would require its own mini-sprint imho... so off the 
board for this discussion.

 

Restconfig is where things get interesting and actually doable in a relatively 
short time.

Restconfig is a slow module to build, and has to wait onto all core OGC 
services to be built, but it

does not have to be that way: I propose we split the service support part into 
a small per service

module, e.g.:

*   gs-restconfig-wfs
*   gs-restconfig-wms
*   gs-restconfig-wcs
*   gs-restconfig-wps (missing today, no way to configure WPS from REST)
*   gs-restconfig-csw (missing today, no way to configure CSW from REST)

Basically gs-restconfig would contain the core abstract service controller 
class, and the "one class modules"

would add the templates, extra code, and tests (side effect, we'd make the 
service rest configuration

actually pluggable). 

There are also 4-5 a few tests hitting the OGC services as part of the tests, 
those could also be moved

to the service specific restconfig module.

This way the main gs-restconfig module could start building as soon as gs-main 
has completed.

 

The other module that should be split imho is the app-schema-test one, in the 
current build, and 

on my current machine, it runs alone for 55 seconds after any other module has 
terminated building.

The reason being that it depends on too many things, wfs, wms, restconfig. 

I believe the module mostly does WFS tests with a few WMS and I believe just 
one REST test, so can

we split it into three parts that can start running as soon as their 
dependencies are made available?

*   app-schema-wfs-test
*   app-schema-wms-test
*   app-schema-rest-test

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,