Re: [Geoserver-devel] Build with Maven fails

[Ben Caradoc-Davies]

Niklas,

I use the Maven Eclipse plugin to generate project information and then 
in Eclipse I use Import / Existing Projects into Workspace. I run this 
command in the top-level src directory:

mvn -DdownloadSources eclipse:clean eclipse:eclipse

Be sure to run this command from the top-level src directory to ensure 
that dependencies between GeoServer modules are resolved as dependencies 
inside your Eclipse workspace and not as dependencies on artifacts in 
your Maven repository.

Kind regards,
Ben.

On 29/12/16 02:42, Niklas Trzaska wrote:
> Dear developers,
>
> some days ago I opened a request for a feature:
>
> https://osgeo-org.atlassian.net/browse/GEOS-7914
>
> Now I wanted to follow the invitation to test the new feature but I do have
> some problems to get it running.
>
> I followed the instruction from
> http://docs.geoserver.org/latest/en/developer/quickstart/index.html#build-with-maven
>
> two times.
>
> First of all I tried to use the fork from
> https://github.com/bradh/geoserver/tree/geos7914
>
> The second time I followed the instruction and used the geoserver
> respository given in the instructions.
>
> In both cases *mvn clean install* was successfully
>
> [INFO]
> 
>
> [INFO] Reactor Summary:
>
> [INFO]
>
> [INFO] GeoServer .. SUCCESS [
> 13.813 s]
>
> [INFO] Core Platform Module ... SUCCESS [
> 26.618 s]
>
> [INFO] Open Web Service Module  SUCCESS [
> 23.803 s]
>
> [INFO] Main Module  SUCCESS [04:51
> min]
>
> [INFO] GeoServer Security Modules . SUCCESS [ 1.688
> s]
>
> [INFO] GeoServer JDBC Security Module . SUCCESS [
> 35.510 s]
>
> [INFO] GeoServer LDAP Security Module . SUCCESS [03:00
> min]
>
> [INFO] Web Coverage Service Module  SUCCESS [ 3.015
> s]
>
> [INFO] Web Coverage Service 1.0 Module  SUCCESS [
> 24.704 s]
>
> [INFO] Web Coverage Service 1.1 Module  SUCCESS [
> 27.004 s]
>
> [INFO] Web Coverage Service 2.0 Module  SUCCESS [
> 56.278 s]
>
> [INFO] Web Feature Service Module . SUCCESS [01:39
> min]
>
> [INFO] Web Map Service Module . SUCCESS [02:53
> min]
>
> [INFO] KML support for GeoServer .. SUCCESS [
> 32.195 s]
>
> [INFO] GeoWebCache (GWC) Module ... SUCCESS [01:06
> min]
>
> [INFO] REST Support Module  SUCCESS [
> 14.776 s]
>
> [INFO] REST Configuration Service Module .. SUCCESS [01:12
> min]
>
> [INFO] GeoServer Web Modules .. SUCCESS [ 0.076
> s]
>
> [INFO] Core UI Module . SUCCESS [01:17
> min]
>
> [INFO] WMS UI Module .. SUCCESS [
> 26.978 s]
>
> [INFO] GWC UI Module .. SUCCESS [
> 39.033 s]
>
> [INFO] WFS UI Module .. SUCCESS [
> 10.826 s]
>
> [INFO] Demos Module ... SUCCESS [
> 19.721 s]
>
> [INFO] WCS UI Module .. SUCCESS [
> 14.269 s]
>
> [INFO] Security UI Modules  SUCCESS [ 0.060
> s]
>
> [INFO] Security UI Core Module  SUCCESS [01:51
> min]
>
> [INFO] Security UI JDBC Module  SUCCESS [01:26
> min]
>
> [INFO] Security UI LDAP Module  SUCCESS [01:34
> min]
>
> [INFO] REST UI Module . SUCCESS [
> 12.147 s]
>
> [INFO] GeoServer Web Application .. SUCCESS [
> 22.329 s]
>
> [INFO] Community Space  SUCCESS [ 1.304
> s]
>
> [INFO] GeoServer Extensions ... SUCCESS [ 0.037
> s]
>
> [INFO]
> 
>
> [INFO] BUILD SUCCESS
>
> [INFO]
> 
>
> [INFO] Total time: 27:40 min
>
> [INFO] Finished at: 2016-12-28T13:50:03+01:00
>
> [INFO] Final Memory: 77M/319M
>
> [INFO]
> 
>
>
> During the import into eclipse I get the following error:
>
> *Errors occurred during the build.*
>
> *Errors running builder 'Java Builder' on project 'gs-main'.*
>
> *java.lang.NullPointerException*
>
>
>
> If I try to run the web-app as a java application despite the error I get:
>
>
>
> * at org.geoserver.web.Start.main(Start.java:122)*
>
> *Caused by: java.lang.Error: Unresolved compilation problems: *
>
> * Syntax error, parameterized types are only available if source level is
> 1.5 or greater*
>
> * Syntax error, 

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2016-12-27

[Andrea Aime]

On Wed, Dec 28, 2016 at 7:50 PM, Jody Garnett 
wrote:
| I would like to include the above table in your proposal page as it helps
me understand what the different layer groups types mean.

Err... ok, it needs fixing but I can amend the proposal to include a
corrected version of it. I'm surprised in that the first four rows are
things everybody should have known
already.


>> Because one can access unadvertised layers directly, and the layer name
>> can be inferred by other means, e.g., by performing
>>
> a GetFeaturInfo on the group.
>>
>
> Oh, so they are still accessable individual using GetMap?
>

A non advertised layer is still requestable directly. That's the point of
novelty of the opaque container, you can ask for the group, but there
is no way to take it apart in its constituents, even if the client is
custom made and can in theory ask for the layers
directly.


>
>>>
>>> *  Q: Are the access restrictions any different between “Named tree”
>> and ‘Opaque container”? - Ben cannot see a difference - Jody cannot see why
>> it matters (since the layers are not published here)*
>>
>> A named tree that allows access show the layers and allows direct access
>> to them. If it's denied by security, the
>> layers have the same destiny, unless contained in other visible groups.
>>
>> A opaque container is the "only" conduit to access the layers it
>> contains, layer cannot be accessed directly by name in GetMap
>> unless they are also contained in other visible groups.
>>
>
> So this question is mostly a variation on the above; if they are not
> accessible at all then security settings do not matter.
>
> So here is the clarification/confirmation: When accessed by "other
> visible group" they are under the security restrictions of that other
> group; the security restrictions from the "opaque container" do not have
> any affect.
>

Correct.


>
> basemap (opaque container) with restriction "basemap/*' for "operations"
> - roads
> - orthophoto
> infrastructure (named tree) with restrictions to "maintenance"
> - roads
>
> Someone from the public:
> - can see a capabilities document with "basemap" listed
> - they can draw basemap, but operations like GetFeatureInfo fail to return
> anything useful (since they have security restrictions preventing access to
> roads and orthophotos)
>

Nope, if the basemap is restricted to operations the public will not see
it. From your layout above, the public won't see anything.


>
> Someone from operations:
> - can see a capabilities document with "basemap listed" (but no further
> detail)
> - can use GetFeatureInfo to see some details about roads and orthophoto
> since they have security access to roads and orthophotos
>

Correct


>
> Someone from infrastructure:
> - can see basemap (just like a member of public) and can see
> infrastructure and its contents
>
- they can draw basemap, but operations like GetFeatureInfo will only
> respond to roads (not orthophoto) since that is the only layer they have
> security permission to see
>

No and no, see above, only someone from operations can see basemap.


> - they can draw infrastructure since it is a named tree
>

They can draw it since they have access to it _and_ it's a named tree.


> - they can draw and interact with roads (since they can access it via
> infrastructure)
>

Correct.

Let me make an example closer to the intended usage.

basemap (opaque container) with no restrictions
- roads
- orthophoto
referenceTree (named tree) restricted to "logged in user"
- roads
- orthophoto

Someone from the public can only see basemap, cannot many any request
directly asking roads and orthophoto, when a GetFeatureInfo is run against
basemap they will get information as usual since the access went through
the group.

Someone from the "logged in user" group can do anything on all layers,
since they are all visible to them.

Regards
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 

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2016-12-27

[Jody Garnett]

Thanks for the discussion Andrea / Ben:

Focusing on understanding GSIP-153 (rather than alternatives):


>>
>>
>>
>>
>>
>> *   Layer group Named Children Advertised Children Access
Restrictions Single named layer default layer default Named tree named
Lists children layer default Layer default Container Tree Lists children
layer default Layer default EO Tree Named delegate Lists children layer
default Layer default Opaque Container named Not advertised *
>
>
> The above table seems to be wrong in regards to access restrictions due to
> GSIP 152, if a layer
> shows up in a tree group that has been denied, then it won't be accessible
> at all (nor by the group, nor by itself),
> unless it's also available by another group (a layer can be part of
> multiple groups).
>

Yeah I think I got the wrong flavour here for "advertised children". For a
"basemap" / "opaque container" layer group the children are more than "not
advertised' they are "unnamed / not requestable" (unless published
elsewhere by another layer group).

I would like to include the above table in your proposal page as it helps
me understand what the different layer groups types mean.

>
>
>> * Q: Because the children are not advertised by “opaque container” why
>> does the access restrictions even matter?*
>>
>
> Because one can access unadvertised layers directly, and the layer name
> can be inferred by other means, e.g., by performing
> a GetFeaturInfo on the group.
>

Oh, so they are still accessable individual using GetMap?


> During the implementation I actually figured out that part of what I was
> proposing did not make sense, if a layer
> is only in a opaque container it's not available at all by itself, putting
> it there is the security itself, there is nothing
> more to do in terms of data security rules. I wanted to discuss this once
> I came back from vacations, but here we go...
>

This is what I was thinking ... you have a belt and suspenders to keep your
pants on.


>>
>> *  Q: Are the access restrictions any different between “Named tree”
> and ‘Opaque container”? - Ben cannot see a difference - Jody cannot see why
> it matters (since the layers are not published here)*
>
> A named tree that allows access show the layers and allows direct access
> to them. If it's denied by security, the
> layers have the same destiny, unless contained in other visible groups.
>
> A opaque container is the "only" conduit to access the layers it contains,
> layer cannot be accessed directly by name in GetMap
> unless they are also contained in other visible groups.
>

So this question is mostly a variation on the above; if they are not
accessible at all then security settings do not matter.

So here is the clarification/confirmation: When accessed by "other visible
group" they are under the security restrictions of that other group; the
security restrictions from the "opaque container" do not have any affect.

basemap (opaque container) with restriction "basemap/*' for "operations"
- roads
- orthophoto
infrastructure (named tree) with restrictions to "maintenance"
- roads

Someone from the public:
- can see a capabilities document with "basemap" listed
- they can draw basemap, but operations like GetFeatureInfo fail to return
anything useful (since they have security restrictions preventing access to
roads and orthophotos)

Someone from operations:
- can see a capabilities document with "basemap listed" (but no further
detail)
- can use GetFeatureInfo to see some details about roads and orthophoto
since they have security access to roads and orthophotos

Someone from infrastructure:
- can see basemap (just like a member of public) and can see infrastructure
and its contents
- they can draw basemap, but operations like GetFeatureInfo will only
respond to roads (not orthophoto) since that is the only layer they have
security permission to see
- they can draw infrastructure since it is a named tree
- they can draw and interact with roads (since they can access it via
infrastructure)

>
--
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] Build with Maven fails

[Andrea Aime]

Hi NIcklas,
"during the import in eclipse" is probably the key factor. How did you
import in eclipse?
I don't think anybody is using the native eclipse maven support as it's too
slow to develop again
with a large project such as GeoServer.
Did you try this?
http://docs.geoserver.org/latest/en/developer/maven-guide/index.html#eclipse


Also, from the errors it seems you have something (the IDE maybe) setup to
work with
java 5, but GeoServer requires Java 8 as a minimum

Cheers
Andrea


On Wed, Dec 28, 2016 at 2:42 PM, Niklas Trzaska <
niklastrza...@googlemail.com> wrote:

> Dear developers,
>
> some days ago I opened a request for a feature:
>
> https://osgeo-org.atlassian.net/browse/GEOS-7914
>
> Now I wanted to follow the invitation to test the new feature but I do
> have some problems to get it running.
>
> I followed the instruction from http://docs.geoserver.
> org/latest/en/developer/quickstart/index.html#build-with-maven
>
> two times.
>
> First of all I tried to use the fork from https://github.com/bradh/
> geoserver/tree/geos7914
>
> The second time I followed the instruction and used the geoserver
> respository given in the instructions.
>
> In both cases *mvn clean install* was successfully
>
> [INFO] 
> 
>
> [INFO] Reactor Summary:
>
> [INFO]
>
> [INFO] GeoServer .. SUCCESS [
> 13.813 s]
>
> [INFO] Core Platform Module ... SUCCESS [
> 26.618 s]
>
> [INFO] Open Web Service Module  SUCCESS [
> 23.803 s]
>
> [INFO] Main Module  SUCCESS
> [04:51 min]
>
> [INFO] GeoServer Security Modules . SUCCESS [
> 1.688 s]
>
> [INFO] GeoServer JDBC Security Module . SUCCESS [
> 35.510 s]
>
> [INFO] GeoServer LDAP Security Module . SUCCESS [03:00
> min]
>
> [INFO] Web Coverage Service Module  SUCCESS [
> 3.015 s]
>
> [INFO] Web Coverage Service 1.0 Module  SUCCESS [
> 24.704 s]
>
> [INFO] Web Coverage Service 1.1 Module  SUCCESS [
> 27.004 s]
>
> [INFO] Web Coverage Service 2.0 Module  SUCCESS [
> 56.278 s]
>
> [INFO] Web Feature Service Module . SUCCESS [01:39
> min]
>
> [INFO] Web Map Service Module . SUCCESS [02:53
> min]
>
> [INFO] KML support for GeoServer .. SUCCESS [
> 32.195 s]
>
> [INFO] GeoWebCache (GWC) Module ... SUCCESS [01:06
> min]
>
> [INFO] REST Support Module  SUCCESS [
> 14.776 s]
>
> [INFO] REST Configuration Service Module .. SUCCESS [01:12
> min]
>
> [INFO] GeoServer Web Modules .. SUCCESS [
> 0.076 s]
>
> [INFO] Core UI Module . SUCCESS
> [01:17 min]
>
> [INFO] WMS UI Module .. SUCCESS [
> 26.978 s]
>
> [INFO] GWC UI Module .. SUCCESS [
> 39.033 s]
>
> [INFO] WFS UI Module .. SUCCESS [
> 10.826 s]
>
> [INFO] Demos Module ... SUCCESS [
> 19.721 s]
>
> [INFO] WCS UI Module .. SUCCESS [
> 14.269 s]
>
> [INFO] Security UI Modules  SUCCESS [
> 0.060 s]
>
> [INFO] Security UI Core Module  SUCCESS [01:51
> min]
>
> [INFO] Security UI JDBC Module  SUCCESS [01:26
> min]
>
> [INFO] Security UI LDAP Module  SUCCESS [01:34
> min]
>
> [INFO] REST UI Module . SUCCESS [
> 12.147 s]
>
> [INFO] GeoServer Web Application .. SUCCESS [
> 22.329 s]
>
> [INFO] Community Space  SUCCESS [
> 1.304 s]
>
> [INFO] GeoServer Extensions ... SUCCESS [
> 0.037 s]
>
> [INFO] 
> 
>
> [INFO] BUILD SUCCESS
>
> [INFO] 
> 
>
> [INFO] Total time: 27:40 min
>
> [INFO] Finished at: 2016-12-28T13:50:03+01:00
>
> [INFO] Final Memory: 77M/319M
>
> [INFO] 
> 
>
>
> During the import into eclipse I get the following error:
>
> *Errors occurred during the build.*
>
> *Errors running builder 'Java Builder' on project 'gs-main'.*
>
> *java.lang.NullPointerException*
>
>
>
> If I try to run the web-app as a java application despite the error I get:
>
>
>
> * at org.geoserver.web.Start.main(Start.java:122)*
>
> *Caused by: java.lang.Error: Unresolved compilation problems: *
>
> * Syntax error, parameterized types are only available if source level is
> 1.5 or 

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2016-12-27

[Andrea Aime]

On Tue, Dec 27, 2016 at 9:49 PM, Ben Caradoc-Davies 
wrote:

> *GeoTools / GeoServer Meeting 2016-12-27*
>
> * Attending Ben Caradoc-Davies, Jody Garnett*
>

Forgot to send my apologies, my kids are home for vacations and I'm on baby
sitting duty
full time (I have vacations, my wife does not).


>
> * - - GSIP 153 Opaque container layer group
>  - Ben did not like
> any of Jody’s suggestions better than “opaque container” layergroup -
> Should a layer contained in an “opaque container” have the advertised
> checkbox grayed out?*
>

Nope, a layer can appear in multiple groups.


>
>
>
>
>
>
>
>
>
> * - - Ben: “Withheld”? “Unadvertised”? - Properties of a single class?
> Okay making a table to sort out what is what ... Layer group Named Children
> Advertised Children Access Restrictions Single named layer default layer
> default Named tree named Lists children layer default Layer default
> Container Tree Lists children layer default Layer default EO Tree Named
> delegate Lists children layer default Layer default Opaque Container named
> Not advertised *
>

The above table seems to be wrong in regards to access restrictions due to
GSIP 152, if a layer
shows up in a tree group that has been denied, then it won't be accessible
at all (nor by the group, nor by itself),
unless it's also available by another group (a layer can be part of
multiple groups).



> * Q: Because the children are not advertised by “opaque container” why
> does the access restrictions even matter?*
>

Because one can access unadvertised layers directly, and the layer name can
be inferred by other means, e.g., by performing
a GetFeaturInfo on the group.
During the implementation I actually figured out that part of what I was
proposing did not make sense, if a layer
is only in a opaque container it's not available at all by itself, putting
it there is the security itself, there is nothing
more to do in terms of data security rules. I wanted to discuss this once I
came back from vacations, but here we go...



>
>
>
> * Q: Are the access restrictions any different between “Named tree” and
> ‘Opaque container”? - Ben cannot see a difference - Jody cannot see why it
> matters (since the layers are not published here)*
>

A named tree that allows access show the layers and allows direct access to
them. If it's denied by security, the
layers have the same destiny, unless contained in other visible groups.

A opaque container is the "only" conduit to access the layers it contains,
layer cannot be accessed directly by name in GetMap
unless they are also contained in other visible groups.


>
>
>
> * - Q: Can we break out these qualities as checkboxes rather than as a
> “mode” setting?*
>

This would imply a redesign of the entire system. Feel free to make it into
a proposal and implement it, taking care of backwards compatibility.
GSIP-153 has been positively voted by the both of you (to be fair, I would
not have had the developer resources to implement what you propose
here anyways, GSIP-153 would have died there if you went forward with this
before voting).


>
>
> * - Tree - (true) controls if children are listed in the capabilities
> document; or - (false) layer group is is presented as a single layer in the
> capabilities document - Advertise Layer Group - (true) layer group is
> listed in the capabilities document - (false) layer group is not listed in
> the capabilities document*
>

>
> * - Advertise Children - (true) layers use their default “advertised”
> setting - (false) layers are not advertised in the capabilities document
> here (yes another layer group may wish to advertise them) *
>

>
> * - Named - (true) layer group name can be used to request the layer group
> be drawn (treats the layer group as a single layer that can be drawn using
> GetMap) - (false) layer group name is for internal use only, and cannot be
> used in a GetMap Request (treats the layergroup as a folder that cannot be
> requested using GetMap)*
>

A non named group is not "internal use only", it's a legit part of the
capabilites document tree, it just cannot be requested in GetMap (maybe we
are saying the same thing with different words).


>
>
> * - Delegate Layer - If a delegate is provided this layer will be drawn
> instead when the layer group is requested*
>

This weirdness is EO specific, I giving it a different name would only
cause confusion imho.


>
>
> * - - Restricted - Layer group is available as target for access control
> restrictions*
>

I don't get this one, all groups are targets for access control
restrictions as per GSIP-152 already. I however do not see a combination
that would allow a layer group to make layers truly unavailable in a
basemap fashion (that is, either access them thought the group, or they
are locked up for good).

Giving uses 6 separate flags would mean allowing for 64 different potential
configurations instead of the 5 proposed. Seems like a 

[Geoserver-devel] Build with Maven fails

[Niklas Trzaska]

Dear developers,

some days ago I opened a request for a feature:

https://osgeo-org.atlassian.net/browse/GEOS-7914

Now I wanted to follow the invitation to test the new feature but I do have
some problems to get it running.

I followed the instruction from
http://docs.geoserver.org/latest/en/developer/quickstart/index.html#build-with-maven

two times.

First of all I tried to use the fork from
https://github.com/bradh/geoserver/tree/geos7914

The second time I followed the instruction and used the geoserver
respository given in the instructions.

In both cases *mvn clean install* was successfully

[INFO]


[INFO] Reactor Summary:

[INFO]

[INFO] GeoServer .. SUCCESS [
13.813 s]

[INFO] Core Platform Module ... SUCCESS [
26.618 s]

[INFO] Open Web Service Module  SUCCESS [
23.803 s]

[INFO] Main Module  SUCCESS [04:51
min]

[INFO] GeoServer Security Modules . SUCCESS [ 1.688
s]

[INFO] GeoServer JDBC Security Module . SUCCESS [
35.510 s]

[INFO] GeoServer LDAP Security Module . SUCCESS [03:00
min]

[INFO] Web Coverage Service Module  SUCCESS [ 3.015
s]

[INFO] Web Coverage Service 1.0 Module  SUCCESS [
24.704 s]

[INFO] Web Coverage Service 1.1 Module  SUCCESS [
27.004 s]

[INFO] Web Coverage Service 2.0 Module  SUCCESS [
56.278 s]

[INFO] Web Feature Service Module . SUCCESS [01:39
min]

[INFO] Web Map Service Module . SUCCESS [02:53
min]

[INFO] KML support for GeoServer .. SUCCESS [
32.195 s]

[INFO] GeoWebCache (GWC) Module ... SUCCESS [01:06
min]

[INFO] REST Support Module  SUCCESS [
14.776 s]

[INFO] REST Configuration Service Module .. SUCCESS [01:12
min]

[INFO] GeoServer Web Modules .. SUCCESS [ 0.076
s]

[INFO] Core UI Module . SUCCESS [01:17
min]

[INFO] WMS UI Module .. SUCCESS [
26.978 s]

[INFO] GWC UI Module .. SUCCESS [
39.033 s]

[INFO] WFS UI Module .. SUCCESS [
10.826 s]

[INFO] Demos Module ... SUCCESS [
19.721 s]

[INFO] WCS UI Module .. SUCCESS [
14.269 s]

[INFO] Security UI Modules  SUCCESS [ 0.060
s]

[INFO] Security UI Core Module  SUCCESS [01:51
min]

[INFO] Security UI JDBC Module  SUCCESS [01:26
min]

[INFO] Security UI LDAP Module  SUCCESS [01:34
min]

[INFO] REST UI Module . SUCCESS [
12.147 s]

[INFO] GeoServer Web Application .. SUCCESS [
22.329 s]

[INFO] Community Space  SUCCESS [ 1.304
s]

[INFO] GeoServer Extensions ... SUCCESS [ 0.037
s]

[INFO]


[INFO] BUILD SUCCESS

[INFO]


[INFO] Total time: 27:40 min

[INFO] Finished at: 2016-12-28T13:50:03+01:00

[INFO] Final Memory: 77M/319M

[INFO]



During the import into eclipse I get the following error:

*Errors occurred during the build.*

*Errors running builder 'Java Builder' on project 'gs-main'.*

*java.lang.NullPointerException*



If I try to run the web-app as a java application despite the error I get:



* at org.geoserver.web.Start.main(Start.java:122)*

*Caused by: java.lang.Error: Unresolved compilation problems: *

* Syntax error, parameterized types are only available if source level is
1.5 or greater*

* Syntax error, annotations are only available if source level is 1.5 or
greater*

* Syntax error, 'for each' statements are only available if source level is
1.5 or greater*

* Type mismatch: cannot convert from Boolean to boolean*

* The method putSystemDefault(RenderingHints.Key, Object) in the type Hints
is not applicable for the arguments (Hints.Key, boolean)*

* The method putSystemDefault(RenderingHints.Key, Object) in the type Hints
is not applicable for the arguments (Hints.DoubleKey, double)*

* Syntax error, parameterized types are only available if source level is
1.5 or greater*

* Syntax error, parameterized types are only available if source level is
1.5 or greater*

* Syntax error, parameterized types are only available if source level is
1.5 or greater*

* Syntax error, parameterized types are only available 

Re: [Geoserver-devel] how a wms request is handled by geoserver

[Andrea Aime]

Hi Chandra,
there is no documentation about that, but you can start a debug session and
put breakpoints in these files/lines, that should give
you enough to figure it out by yourself:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L238
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/map/GetMapKvpRequestReader.java#L193
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/DefaultWebMapService.java#L316
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/GetMap.java#L119
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/map/RenderedImageMapOutputFormat.java#L280

Regards
Andrea


On Wed, Dec 28, 2016 at 8:40 AM, Chandra Mohan Sharma <
chandramohansharma@gmail.com> wrote:

> Dear Geoserver Developers
>
> I am very new to GeoServer development. I am using geoserver 2.10 in
> NetBeans. I wanted to know that when the geoserver is up and running, what
> is the exact sequence of operations for handling getmap operation request
> of WMS i.e. methods of which classes are called and in what sequence. It
> would be very helpful if anybody can tell from which operation of a class
> it starts. If some documentation is available or some help is available
> regarding it, kindly share a link with me. Thanking you in advance.
>
> regards
> Chandra Mohan Sharma
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 
==
GeoServer 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] GSIP 153 - opaque container layer group mode

[Andrea Aime]

On Tue, Dec 27, 2016 at 9:57 PM, Ben Caradoc-Davies 
wrote:

> Andrea,
>
> Jody and I brainstormed GSIP-153 in today's (very small) committee
> meeting. In a nutshell, have you considered a single layer group class with
> many properties, rather than multiple classes of layer group? Jody made a
> nice table and we listed the properties in bullet points. We also discussed
> some naming changes. Please see the meeting notes.
>

I'm quite baffled and disconcerted... some chronology:

   - December 15th, initial discussion on the concept.
   
http://osgeo-org.1560.x6.nabble.com/Proposing-a-new-layer-group-type-why-make-do-with-4-when-you-can-have-5-td5299963.html
   Only feedback from Ben, who agrees on the concept and suggest to write a
   proposal. I wait a few days for people to provide feedback to inform the
   proposal (to avoid rewriting it), no feedback, time to move on.
   - December 19th, proposal in, by Dec 23rd there are more than enough
   votes, and one trivial request for name change (no problem there)

Given the lack of objections on both the mail and the proposal I start the
implementation on Dec 21th, the implementation is now basically ready
(still have to debug and fix some kinks):
https://github.com/aaime/geoserver/tree/lg_opaque_container

By a quick glance over the discussion in the other mail it seems that
actually:

   - You did not bother reading the first mail, or did not understand it
   - You did not bother reading/understanding or discussing the proposal
   (you'd not have questions now otherwise)

So what are the +1 you casted on the proposal worth?
The proposal mechanism, when it works, provides several beneficial
guarantees:

   - The community has a say on what gets implemented
   - The community has insurance that the work is resources and will be
   completed
   - The implementers knows they won't have to redo the design of their
   work from the ground up once the proposal is voted

The community has been given two occasions to discuss and bend the
proposal, and none was exploited. I'll now try to have a look at it, but my
budget is gone in the existing implementation (still only have a bit to
handle review comments). Would it be wrong of me to expect not simply
discussion but also coding and documentation help from those that changed
their mind now?

I'd really urge everybody to think _before_ casting a vote, not after doing
so. If you are unsure, it's also ok to ask for some time to think, just say
so in public.
If this case is an exception, well, that happens, but if it becomes common,
the proposal mechanism is basically dead and done for.

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!