[Geoserver-devel] Spring 2, it works

Hi all, As an FYI relating to GEOS-1831, i managed to get GeoServer trunk up and running in Spring 2.5.2. I have not done any rigorous testing, but hitting the UI, some basic get capabilities cals, and the map preview seem to work ok. I also tried the Acegi stuff and it seems to work fine. I w

[Geoserver-devel] GeoServer Resources

Hey- I'd be interested to hear thoughts on an architecture proposal for GeoServer: http://geoserver.org/display/GEOSDOC/GeoServer+Resources This builds off of work that David Winslow has been doing and has written up here: http://geoserver.org/display/GEOSDOC/RESTful+User+Management+API http://

Re: [Geoserver-devel] binary spatial operators with functions

GeoTools WFSDataStore special cases geoserver in order to be lenient in this case. Jody > Hi all, > > When handling an issue report yesterday: > > http://jira.codehaus.org/browse/GEOS-1829 > > For the fix I submitted the patch which allows BinarySpatialOperator > (like "Touches") to contain a "Fu

[Geoserver-devel] [jira] Created: (GEOS-1832) WMS GetCapabilities returns EPSG: when there are no feature types defined

WMS GetCapabilities returns EPSG: when there are no feature types defined Key: GEOS-1832 URL: http://jira.codehaus.org/browse/GEOS-1832 Project: GeoServer

[Geoserver-devel] Hudson build is back to normal: geoserver-1.6.x #118

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/118/changes - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.double

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #117

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/117/changes Changes: [groldan] GEOS-1815, respect character encoding for WMS xml responses -- started Updating https://svn.codehaus.org/geoserver/branches/1.6.x/geoserver U communit

Re: [Geoserver-devel] GeoServer fails with Spring 2.5

I think the only reason for not upgrading was Acegi... but it definitely supports spring 2.0.x and 2.5.x. I guess the only other reason is "if it aint broke, don't fix it". But I agree... spring 1.x is pretty much officially archived (only available from the archives)... so it may be time to up

Re: [Geoserver-devel] GeoServer fails with Spring 2.5

What are our reasons for not upgrading GeoServer to Spring 2.5? It seems like 1.2 is not all that supported any more, and that being on 2.5 might give us better compatibility with other projects? Plus if we have bugs they are more likely to get fixed - if we have a bug with 1.2 it'd be like p

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #14

See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/14/changes Changes: [groldan] GEOS-1815,added Service.getCharset() and sets the encoding charset to the WCS transformers -- started Updating https://svn.codehaus.org/geoserver/trunk/geoserv

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #116

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/116/changes Changes: [groldan] GEOS-1815, remove get/setCharset from OWS [groldan] GEOS-1815, set the encoding to the describeCoverage transformer -- started Updating https://svn.codehaus.o

Re: [Geoserver-devel] Releases

Sorry, it just got pointed out to me the ambiguity of 'next friday'. Release will be Friday, April 4th, the first friday of the month. Chris Chris Holmes wrote: Hey all, so first I want to apologize for being opaque on the process of when releases have been cut recently, not giving people a ch

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #115

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/115/changes Changes: [groldan] GEOS-1815, fixed DescribeCoverage and WCS GetCapabilities to encode responses in the proper charset [groldan] GEOS-1815, move OWS.getCharset() to Service (extends OWS) and make it explicitly delega

Re: [Geoserver-devel] EPSG limitation

Francesco, all we decided to take action on this one for good. Add yourself as a watcher of to be notified when its done. regards, Gabriel On Wednesday 26 March 2008 04:21:43 pm Justin Deoliveira wrote: > (please keep questions on the public list). >

Re: [Geoserver-devel] GeoServer fails with Spring 2.5

Hi Vitali, I too tried this before and ran into similar issues, but did not spend too much time looking into this. I am creating a jira issue for this: http://jira.codehaus.org/browse/GEOS-1831 Sooner or later we will officially move to Spring 2. When will be a community decision, but ironing

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #13

See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/13/changes -- started Updating https://svn.codehaus.org/geoserver/trunk/geoserver Fetching 'http://svn.codehaus.org/geoserver/trunk/configuration/minimal' at -1 into 'http://gridlock.openpla

[Geoserver-devel] [jira] Created: (GEOS-1831) make geoserver runnable in spring 2

make geoserver runnable in spring 2 --- Key: GEOS-1831 URL: http://jira.codehaus.org/browse/GEOS-1831 Project: GeoServer Issue Type: Bug Reporter: Justin Deoliveira Assignee: Justin Deo

[Geoserver-devel] GeoServer fails with Spring 2.5

Hello! We are using GeoServer as a part of web application (several GeoServer's modules: data, platform, main, ows,..). It serves as an engine to load/persist features directly from/to their datastores and lets us to reuse rich configuration of datastores and feature types in XML, gives direct a

[Geoserver-devel] [jira] Created: (GEOS-1830) Allow to limit the list of available CRS's in WMS GetCapabilities

Allow to limit the list of available CRS's in WMS GetCapabilities - Key: GEOS-1830 URL: http://jira.codehaus.org/browse/GEOS-1830 Project: GeoServer Issue Type: Improvement

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #114

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/114/changes -- started Updating https://svn.codehaus.org/geoserver/branches/1.6.x/geoserver Fetching 'http://svn.codehaus.org/geoserver/trunk/configuration/minimal' at -1 into 'http://gridlo

Re: [Geoserver-devel] EPSG limitation

(please keep questions on the public list). As a workaround, one thing you can do is: 1. Download the wms capabilities document 2. Manually remove all the SRS's you do not want 3. Publish the the capabilities document (via web server) on the same server as geoserver The problem with this is of

[Geoserver-devel] binary spatial operators with functions

Hi all, When handling an issue report yesterday: http://jira.codehaus.org/browse/GEOS-1829 For the fix I submitted the patch which allows BinarySpatialOperator (like "Touches") to contain a "Function" as the second argument, in place of a "Geometry" or an "Envelope". Example: the_geom

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

A few general thoughts: * The only configuration framework I've ever dealt with that wasn't a one-off I wrote was the one in doxygen (which is, of course, a one-off by the doxygen guys). One thing I like about it that we could possibly copy for our configuration tool is that it has two views, a

Re: [Geoserver-devel] EPSG limitation

Hi Fransesco, (this is probably a more suitable question for the users list). The answer is no. I know its a pain to process the capabilities document, but there is no good way to limit it at this time. It is something we will be taking into account while redoing the core configuration work.

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Andrea Aime wrote: > Luca Morandini ha scritto: >> A Java programmer can build good UIs too, I suspect. >> Look, I've never heard of a "saw craftsman" as unable to make an elegant >> wood table: let's separate the tool from the product. > > We're thinking of different things here. As Dijstra wise

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #113

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/113/changes -- started Updating https://svn.codehaus.org/geoserver/branches/1.6.x/geoserver Fetching 'http://svn.codehaus.org/geoserver/trunk/configuration/minimal' at -1 into 'http://gridlo

[Geoserver-devel] EPSG limitation

Hi, Is it possible to limit the available SRS returned from *GeoServer* WMS? GetCapabilities returns an enormeous list (3900+) :( I need help... Thanks -- Francesco @ MacOSX "TiGeR 10.4.9" - Check out the new SourceForg

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Luca Morandini ha scritto: ... > Having said that, framework like Struts2 (via the plugin you mentioned) > and RESTlet let you directly connect URI to Java classes methods, while > Cocoon has an intermediate layer (the sitemap) for routing URIs: you may > see this either as added complexity or i

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Andrea Aime wrote: > > The only web frameworks that can do both UI and REST calls are the > action based ones, in a component based one (Wicket, JSF) web services > have nothing to do with UI building, whilst in an action based one > you're throwing out a document in response to a call so they ca

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Luca Morandini ha scritto: > Well, in an ideal world, the same developer should: > 1) Develop the service. > 2) Build the UI for said service. > 3) Write the documentation. > > Since this rarely happen, it might be wise to allocate different people > to do these three things. We're trying, but

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Andrea Aime wrote: > Luca Morandini ha scritto: >> So, my idea would be to first build the API, then (or concurrently) the >> admin UI. > > This idea of making the UI a separate web application worries me. > So far we've tried to be the champions of the "easy to use", at least > for the first step

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Luca Morandini ha scritto: > Justin Deoliveira wrote: >> I can see a couple of benefits. It could possibly reduce the download >> size if we wanted to release the webapp separately. Which may be >> something to consider once we have a good REST api. Or perhaps users who >> have a set data direct

[Geoserver-devel] IRC logs, March 25 2008

(I'm posting the logs here because apparently there is no more news space on the Geoserver.org confluence? Where did it go?) -- Summary: - Google soc - 1.6.3 release and related bugs - UI framework talk -

Re: [Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

Chris Holmes ha scritto: ... > If we end up with a UI framework like wicket combined with a completely > separate REST API like Restlet that can be fine, but if something like > Struts 2 can handle much of the REST calls with a plug-in then that > might make less overall code, so it'd be easier