Re: [Geoserver-devel] [ExternalEmail] Re: Community modules and the whole development process

On Tue, May 17, 2011 at 6:05 AM, Ben Caradoc-Davies wrote: > On 17/05/11 10:31, Gabriel Roldán wrote: >> Well, I think it could result in an explosion of publicly available >> prototypes, since anyone would be able to work on his own public repo >> without having to request commit access to svn, a

Re: [Geoserver-devel] [ExternalEmail] Re: Community modules and the whole development process

On 17/05/11 10:31, Gabriel Roldán wrote: > Well, I think it could result in an explosion of publicly available > prototypes, since anyone would be able to work on his own public repo > without having to request commit access to svn, and able to say hey, if > you wanna try my module, just pull from

Re: [Geoserver-devel] [ExternalEmail] Re: Community modules and the whole development process

Well, I think it could result in an explosion of publicly available prototypes, since anyone would be able to work on his own public repo without having to request commit access to svn, and able to say hey, if you wanna try my module, just pull from this url. And you can as easily branch out your r

Re: [Geoserver-devel] [ExternalEmail] Re: Community modules and the whole development process

Another benefit of keeping community modules in a central repo is that it keeps them open for public scrutiny, comment, and involvement, even when they are a work-in-progress. In my view, this increases openness and transparency. Even prototype modules can have unexpected new users come out of

Re: [Geoserver-devel] Community modules cleanup

Exceptionally good point. I had not considered that. On 16/05/11 22:31, Andrea Aime wrote: > What worries me about moving them "outside" is that they lose the > connection with > the branch they were meant to be buildable into. -- Ben Caradoc-Davies Software Engineering Team Leader CSIRO Earth

Re: [Geoserver-devel] how to add publicly accessible REST resource

Afaik there is no way to get an anonymously accessible resource under rest without modifying the security config manually. What you can do is set up a rest service that lives under its own path, not rest. Check out the python module for an example. http://svn.codehaus.org/geoserver/trunk/src/commu

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

See -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach o

Re: [Geoserver-devel] community module request

Ah cool. Would you be willing for us to put that in to a GeoServer community module? Or to help you get it in? So we can eventually migrate it to an extension and have it as a core part of the code? Looks like it's GPL licensed which is fine, but we will need a contributor's agreement to get it

[Geoserver-devel] Build failed in Hudson: geoserver-2.1.x #232

See -- [...truncated 18695 lines...] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592)

Re: [Geoserver-devel] how to add publicly accessible REST resource

On Mon, May 16, 2011 at 7:52 PM, Gabriel Roldán wrote: > Hey all, > > what do I have to do if want to add a resource under /rest/ that's > publicly accessible through GET method? > > right now it looks like the only way is adding an exception in main > module's applicationSecurityContext.xml like

[Geoserver-devel] how to add publicly accessible REST resource

Hey all, what do I have to do if want to add a resource under /rest/ that's publicly accessible through GET method? right now it looks like the only way is adding an exception in main module's applicationSecurityContext.xml like in: /rest/geosearch/**=anonymousProcessingFilter,consoleExceptionTra

Re: [Geoserver-devel] Community modules cleanup

On Mon, May 16, 2011 at 4:49 PM, Justin Deoliveira wrote: >> If they are not recent we could just remove them from 2.1.x and trunk and >> leave them on 2.0.x? > Yup, that works too. Although if we want to keep things a little cleaner > moving forward we might consider not including any community m

Re: [Geoserver-devel] Community modules cleanup

On Mon, May 16, 2011 at 8:31 AM, Andrea Aime wrote: > On Mon, May 16, 2011 at 4:10 PM, Justin Deoliveira > wrote: > > Page updated with modules I care about. And question... are we going to > > outright remove the modules from svn... or move them to some other space > > outside the source tree. R

Re: [Geoserver-devel] File Formats for adding user groups

Good proposal, since I use the file extension properties it should look like groups.properties group1=user1,user2, and group_roles.properties group1=ROLE_A,ROLE_B Looking into the java doc, you can substitute = with : Anyways, it is a good idea to use the property file syntax. Quoting Ju

Re: [Geoserver-devel] community module request

Hi Jose, Request to join the project as a developer accepted. Welcome to the project! For good measure it would be good (if you have not done so already) to review the community module guide. http://docs.geoserver.org/stable/en/developer/policies/community-modules.html And actually come to tink

Re: [Geoserver-devel] Community modules cleanup

On Mon, May 16, 2011 at 4:10 PM, Justin Deoliveira wrote: > Page updated with modules I care about. And question... are we going to > outright remove the modules from svn... or move them to some other space > outside the source tree. Reason being that there are a few in there that I > probably don

Re: [Geoserver-devel] File Formats for adding user groups

In terms of keeping things consistent what about using an = syntax for groups.properties and group2roles.properties? Seems more consistent with users.properties. Seems to make more sense give that the file is a .properties file as well. Or maybe we should change the extension to .csv? :) No stron

Re: [Geoserver-devel] Community modules cleanup

Page updated with modules I care about. And question... are we going to outright remove the modules from svn... or move them to some other space outside the source tree. Reason being that there are a few in there that I probably don't want to delete outright.. but wouldn't mind if they were outside

[Geoserver-devel] Build failed in Hudson: geoserver-2.1.x #231

See Changes: [aaime] [GEOS-3528] Filtering capabilities for coverage plugins [aaime] [GEOS-4551] Avoid extra-read operation when read coverage is null. (RenderedImageMapOutputFormat) [aaime] Switching over a depreacted call to

[Geoserver-devel] [jira] Created: (GEOS-4557) Show the store type in the store list page

Show the store type in the store list page -- Key: GEOS-4557 URL: http://jira.codehaus.org/browse/GEOS-4557 Project: GeoServer Issue Type: Improvement Reporter: Andrea Aime Assi

Re: [Geoserver-devel] community module request

Hi Jose I once wrote a spatialite outputformat for Geoserver. It does not use any spatialite stuff and uses only org.sqlite.jdbc. It's like dumping the features into an empty sqlite database. You can find the sources here: http://code.google.com/p/cataisrepository/source/browse/#svn%2Ftrunk%2Fg e

[Geoserver-devel] [jira] Created: (GEOS-4556) SLD encoding with REST Configuration

SLD encoding with REST Configuration Key: GEOS-4556 URL: http://jira.codehaus.org/browse/GEOS-4556 Project: GeoServer Issue Type: Bug Components: REST Affects Versions: 2.1.0, 2.1-RC5, 2.1-R

Re: [Geoserver-devel] Community modules and the whole development process

Hi guys, my 2 c ... I mainly develop under windows and using git successfully ... most of our projects are git based and for sure we enjoy the power and flexibility of this instument. Said that I personally agree with Justin and Ben, I guess speaking about community modules we should mainly take i

Re: [Geoserver-devel] community module request

Hello Jose, welcome ... interesting module, I'm positive also to put this on community so that we can make a review and hopefully soon promote this to an extension. Thanks and kind regards, Alessio. --- Ing. Alessio Fabiani Founder / CT