Hi!
I have a simple question for you, does GeoServer supported by Openlayers, how I
can retrieve layer data which created by GeoServer from OpenLayers?
Openlayers.layer.GeoServer(... )
Thank you !
Zhanping
________________________________
From: "[email protected]"
<[email protected]>
To: [email protected]
Sent: Tue, October 12, 2010 8:35:09 PM
Subject: Geoserver-devel Digest, Vol 53, Issue 24
Send Geoserver-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Geoserver-devel digest..."
Today's Topics:
1. Re: how to package a datastore plugin? (Ian Turton)
2. [jira] Created: (GEOS-4173) does not work proxy extention
module (Lazarev Eugene (JIRA))
3. Re: how to package a datastore plugin? (Justin Deoliveira)
4. Re: upgrading to wicket 1.4 (Justin Deoliveira)
5. Re: upgrading to wicket 1.4 (Ben Caradoc-Davies)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Oct 2010 12:08:51 -0400
From: Ian Turton <[email protected]>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Justin Deoliveira <[email protected]>
Cc: Geoserver-devel <[email protected]>, David
Winslow <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <[email protected]> wrote:
> For future reference this is actually decently documented in the developer
> guide.
> http://docs.geoserver.org/stable/en/developer/policies/community-modules.html
What I'm missing is what the maven command I need to execute to build
the zip file is and/or where to look for the zip file?
Plus there are a couple of errors on that page where .. warning is
not being processed probably a missing blank line.
Ian
--
Ian Turton
------------------------------
Message: 2
Date: Tue, 12 Oct 2010 13:48:32 -0500 (CDT)
From: "Lazarev Eugene (JIRA)" <[email protected]>
Subject: [Geoserver-devel] [jira] Created: (GEOS-4173) does not work
proxy extention module
To: [email protected]
Message-ID:
<11043648.79102.1286909312611.javamail.haus-j...@codehaus01.managed.contegix.com>
Content-Type: text/plain; charset=ISO-8859-1
does not work proxy extention module
------------------------------------
Key: GEOS-4173
URL: http://jira.codehaus.org/browse/GEOS-4173
Project: GeoServer
Issue Type: Bug
Components: Configuration, Global, REST
Affects Versions: 2.1-beta1, 2.0.2
Environment: proxy-2.0.3-SNAPSHOT
rest-2.0.3-SNAPSHOT
geoserver 2.0.2
Reporter: Lazarev Eugene
Assignee: Justin Deoliveira
Attachments: GeoServer_Demo_requests.png,
GeoServer_Demo_requests_proxy.png, GeoServer_Geoserver_Proxy_Administration.png
I tried to everything, all of that does not help, I could not get it to work, I
think this is a bug.
you can log on to http://svn.ugi.ru:1580/geoserver/
login: admin
pass: geoserver
to test it
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------
Message: 3
Date: Tue, 12 Oct 2010 13:26:07 -0600
From: Justin Deoliveira <[email protected]>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Ian Turton <[email protected]>
Cc: Geoserver-devel <[email protected]>, David
Winslow <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
If you have the release descriptor written (ext-whatever.xml) and it is
lives in either release or community/release you must update either pom.xml
or community/pom.xml to add it to list of descriptors that get an artifact
built. Just search for ext-*.xml in the file.
Then you do a mvn assembly:attached from either the root of source tree or
root of community depending on where your descriptor lives. The result will
be a zip file under target/release.
-Justin
On Tue, Oct 12, 2010 at 10:08 AM, Ian Turton <[email protected]> wrote:
> On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <[email protected]>
> wrote:
> > For future reference this is actually decently documented in the
> developer
> > guide.
> >
> http://docs.geoserver.org/stable/en/developer/policies/community-modules.html
>
> What I'm missing is what the maven command I need to execute to build
> the zip file is and/or where to look for the zip file?
>
> Plus there are a couple of errors on that page where .. warning is
> not being processed probably a missing blank line.
>
> Ian
> --
> Ian Turton
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Tue, 12 Oct 2010 13:28:06 -0600
From: Justin Deoliveira <[email protected]>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Andrea Aime <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Cool, so far we have 2 +0's and 1 +1. So seems there is some interest.
So pushing forward I guess we should:
(a) flush out the rest of the key errors by manually visiting all pages
(adding test cases along the way)
(b) write up an official proposal for the purpose of voting
Sound good?
On Tue, Oct 12, 2010 at 3:23 AM, Andrea Aime
<[email protected]>wrote:
> On Tue, Oct 12, 2010 at 1:26 AM, Justin Deoliveira <[email protected]>
> wrote:
> > Hi all,
> > Recently i have come across a few extensions for wicket that I figure
> would
> > be nice but require wicket 1.4. That and since 1.4 seems to be the
> current
> > stable release I thought I would take a crack at an upgrade. Not the
> easiest
> > upgrade by a long shot but I have a working setup in my github repo [1].
> > Before describing what I did I am curious to hear what people think about
> an
> > upgrade? Is now the right time? Or should we push off to 2.2? Personally
> i
> > guess i am +0 on the upgrade. On the one hand there are no crucial issues
> > that will be fixed by the upgrade, if anything we will still have issues
> as
> > i am sure there are cases where keys are being referenced that do not
> exist
> > in the property file. we just don't have the test coverage to catch it.
> > Before this patch goes through every single page will have to visited
> > manually... that or we up test coverage to 100% :) But on the other hand
> 95%
> > of the work is done and if we don't upgrade now the patch will become
> > outdated, etc...
>
> I'm favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
> far away and Wicket 1.4 would be replaced by 1.5 by then.
> I prefer to see a "one step at a time" approach and switch to Wicket 1.4
> before
> GeoServer beta2 is relased.
>
> > 6) LayerGroupEditPageTest
> > This one i was actually not sure about. It seems the test makes
> > some assumptions about how the layer list is structured and perhaps it
> > changed.
> > ---
> >
>a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
>a
> > +++
> >
>b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
>a
> > @@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
> > LayerGroupBaseTest {
> > tester.assertRenderedPage(LayerGroupEditPage.class);
> > // remove the first and second elements
> >
> >
>tester.clickLink("form:layers:layers:listContainer:items:1:itemProperties:4:component:link");
>;
> > // the regenerated list will have ids starting from 4
> > -
> >
>
>tester.clickLink("form:layers:layers:listContainer:items:4:itemProperties:4:component:link");
>
> > +
> >
>
>//tester.clickLink("form:layers:layers:listContainer:items:4:itemProperties:4:component:link");
>
> > // manually regenerate bounds
> > tester.clickLink("form:generateBounds");
> > // print(page, true, true);
> >
> > Hopefully the author can chime in.
>
> Yeah, to click a link in a list container we need to go through the
> full path, I know of no
> other way to make it work. What you can do is to use the debug
> facilities in our testing
> harness to have the structure of the page be printed and see how the
> new link path
> looks like. See print(Compoenent, boolean, boolean)
>
> > 7) CoverageStoreEditPageTest,DataAccessEditPageTest
> > These pages have custom validator on the form that check the data store
> name
> > to ensure that it (a) gets set and (b) does not already exist in the
> > catalog. There is also the validator that gets implicitly set since the
> > "name" field is required. It seems the order in which they execute is now
> > different and the latter executes first. For example:
> > ---
> >
>a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
>a
> > +++
> >
>b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
>a
> > @@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
> > GeoServerWicketTestSupport {
> > tester.clickLink("rasterStoreForm:save");
> >
> > tester.assertRenderedPage(CoverageStoreEditPage.class);
> > - tester.assertErrorMessages(new String[] { "Store name is
> required"
> > });
> > + tester.assertErrorMessages(new String[] { "Field 'Data Source
> Name'
> > is required." });
> > }
>
> Ah, I see. Patch looks good.
>
> Btw, also had a quick look at the full patch on github, looks good too.
>
> Cheers
> Andrea
>
> -----------------------------------------------------
> Ing. Andrea Aime
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -----------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 5
Date: Wed, 13 Oct 2010 08:34:57 +0800
From: Ben Caradoc-Davies <[email protected]>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Justin Deoliveira <[email protected]>
Cc: "[email protected]"
<[email protected]>, Andrea Aime
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Sounds good to me. Count me as +1.
On 13/10/10 03:28, Justin Deoliveira wrote:
> Cool, so far we have 2 +0's and 1 +1. So seems there is some interest.
>
> So pushing forward I guess we should:
>
> (a) flush out the rest of the key errors by manually visiting all pages
> (adding
>test cases along the way)
> (b) write up an official proposal for the purpose of voting
>
> Sound good?
>
> On Tue, Oct 12, 2010 at 3:23 AM, Andrea
>Aime<[email protected]<mailto:[email protected]>> wrote:
> On Tue, Oct 12, 2010 at 1:26 AM, Justin
>Deoliveira<[email protected]<mailto:[email protected]>> wrote:
>> Hi all,
>> Recently i have come across a few extensions for wicket that I figure would
>> be nice but require wicket 1.4. That and since 1.4 seems to be the current
>> stable release I thought I would take a crack at an upgrade. Not the easiest
>> upgrade by a long shot but I have a working setup in my github repo [1].
>> Before describing what I did I am curious to hear what people think about an
>> upgrade? Is now the right time? Or should we push off to 2.2? Personally i
>> guess i am +0 on the upgrade. On the one hand there are no crucial issues
>> that will be fixed by the upgrade, if anything we will still have issues as
>> i am sure there are cases where keys are being referenced that do not exist
>> in the property file. we just don't have the test coverage to catch it.
>> Before this patch goes through every single page will have to visited
>> manually... that or we up test coverage to 100% :) But on the other hand 95%
>> of the work is done and if we don't upgrade now the patch will become
>> outdated, etc...
>
> I'm favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
> far away and Wicket 1.4 would be replaced by 1.5 by then.
> I prefer to see a "one step at a time" approach and switch to Wicket 1.4
before
> GeoServer beta2 is relased.
>
>> 6) LayerGroupEditPageTest
>> This one i was actually not sure about. It seems the test makes
>> some assumptions about how the layer list is structured and perhaps it
>> changed.
>> ---
>>a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
>>a
>> +++
>>b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
>>a
>> @@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
>> LayerGroupBaseTest {
>> tester.assertRenderedPage(LayerGroupEditPage.class);
>> // remove the first and second elements
>>
>>tester.clickLink("form:layers:layers:listContainer:items:1:itemProperties:4:component:link");
>>;
>> // the regenerated list will have ids starting from 4
>> -
>>
>>tester.clickLink("form:layers:layers:listContainer:items:4:itemProperties:4:component:link");
>>
>> +
>>
>>//tester.clickLink("form:layers:layers:listContainer:items:4:itemProperties:4:component:link");
>>
>> // manually regenerate bounds
>> tester.clickLink("form:generateBounds");
>> // print(page, true, true);
>>
>> Hopefully the author can chime in.
>
> Yeah, to click a link in a list container we need to go through the
> full path, I know of no
> other way to make it work. What you can do is to use the debug
> facilities in our testing
> harness to have the structure of the page be printed and see how the
> new link path
> looks like. See print(Compoenent, boolean, boolean)
>
>> 7) CoverageStoreEditPageTest,DataAccessEditPageTest
>> These pages have custom validator on the form that check the data store name
>> to ensure that it (a) gets set and (b) does not already exist in the
>> catalog. There is also the validator that gets implicitly set since the
>> "name" field is required. It seems the order in which they execute is now
>> different and the latter executes first. For example:
>> ---
>>a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
>>a
>> +++
>>b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
>>a
>> @@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
>> GeoServerWicketTestSupport {
>> tester.clickLink("rasterStoreForm:save");
>>
>> tester.assertRenderedPage(CoverageStoreEditPage.class);
>> - tester.assertErrorMessages(new String[] { "Store name is required"
>> });
>> + tester.assertErrorMessages(new String[] { "Field 'Data Source Name'
>> is required." });
>> }
>
> Ah, I see. Patch looks good.
>
> Btw, also had a quick look at the full patch on github, looks good too.
>
> Cheers
> Andrea
>
> -----------------------------------------------------
> Ing. Andrea Aime
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -----------------------------------------------------
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
--
Ben Caradoc-Davies <[email protected]>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
End of Geoserver-devel Digest, Vol 53, Issue 24
***********************************************
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
