I agree with Luca on this one. I think "eating our own dog-food" is the
surest and best way to properly develop and constantly test the REST
api. Plus it puts all gui's on a level playing field.
FlexJSON + the config back-end + REST for configuration would seem to
allow everyone to just get on w
Done. Welcome to the project!! :)
Lucas Reed wrote:
> Justin, here is my Codehaus ID: lreed
>
> If you could grant me commit access that would be great.
>
> -Lucas
>
> -
> This SF.net email is sponsored by the 2008 JavaOne(
Justin, here is my Codehaus ID: lreed
If you could grant me commit access that would be great.
-Lucas
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still
Hi again,
thank you for your reply. I created a featureType fitting the
requirements (name = type = "gml:FeatureOfInterest1_iSPACE001"). Now,
the WFS1.1 request works for GML3; however, only the BBOX and not the
data themselves are returned for each feature, s. below. No error
message is throw
Hello,
I implemented a GeoServer datastore, which fetches an XML structure from
a URL. It is accessible on http://rmap.researchstudio.at:8080/geoserver
(typeName="gml:umwelt2") It works for WFS1.1 requests if I set the
outputFormat to "GML2". If I request GML3, the error below is thrown. It
se
Jody Garnett wrote:
>
> I am not sure if this idea holds any appeal. It may be a bad product
> idea to introduce a REST API as a distinct layer; it would be way too
> easy make new functionality quickly via REST and forget to keep the web
> client up to date and in sync.
On the other hand...
1
Andrea Aime wrote:
> They are separated in the new version of SLD, but you are still
> expected to use SLD 1.1 with a WMS no? SE 1.1 by itself does not
> seem very useful to me. I mean, to do most maps you have to take
> multiple feature type styles and lump them together in the proper
> order. Hec
> I thought the rest api was meant for geoserver configuration, not
> only for access. I thus expected an API for configuration to have a 1-1
> relationship between the rest api and the configuration.
I think we just have a different of opinion here... but I dont think it
necessarily have to. I e
GeoServer Documentation link is broken on Windows installs
--
Key: GEOS-1908
URL: http://jira.codehaus.org/browse/GEOS-1908
Project: GeoServer
Issue Type: Bug
Components: Docu
Jody Garnett wrote:
>> Well the way I see it going is that the rest stuff will be rewritten
>> against the new configuration classes. I dont think it will be too much
>> to switch over... and we can still keep the rest of the code base
>> againast the old model... and things will still be in syn
Justin Deoliveira ha scritto:
>
>>
>> I thought you wanted to get rest stuff on 1.7.x before branching (whilst
>> writing stuff directly against the new config would be trunk business?).
>> Moreover, are the concept of map and workspace covered in the new
>> configuration api?
>>
> Confused... I d
Jody Garnett ha scritto:
> I suspect that the Cocoon prototype meets all of our requirements
> exception "fashion". Both cocoon and wicket provide a nice formal split
> between model and view; one using XSLT and the other using a fill in the
> blank template. Personally I have let whatever XSLT
Justin Deoliveira wrote:
> Well the way I see it going is that the rest stuff will be rewritten
> against the new configuration classes. I dont think it will be too much
> to switch over... and we can still keep the rest of the code base
> againast the old model... and things will still be in sy
>
> I thought you wanted to get rest stuff on 1.7.x before branching (whilst
> writing stuff directly against the new config would be trunk business?).
> Moreover, are the concept of map and workspace covered in the new
> configuration api?
>
Confused... I did mean that. I also meant including t
Justin Deoliveira ha scritto:
> I use maven 2.0.6 without any problems. Our build server uses 2.0.8.
Hmmm... given that gt2 is going to switch to 2.0.9 next week,
and given that I would not like very much to have a different maven
for gt2 and gs, I'm going to have a look into this one.
Cheers
And
Justin Deoliveira ha scritto:
>>
>> Hmmm. REST api is going to finally free all the people that are
>> struggling trying to programmatically configure GeoServer, so it's
>> cool all right.
>> But (you expected a but, right?) how do we implement a good REST api
>> like http://geoserver.org/display/
>
> Hmmm. REST api is going to finally free all the people that are
> struggling trying to programmatically configure GeoServer, so it's
> cool all right.
> But (you expected a but, right?) how do we implement a good REST api
> like http://geoserver.org/display/GEOSDOC/GeoServer+Resources without
NullPointerException on a Delete request -- do to unknown typeName?
---
Key: GEOS-1907
URL: http://jira.codehaus.org/browse/GEOS-1907
Project: GeoServer
Issue Type: Bug
Well, I just picked 2.0.4 from the maven site.
Alex
On Tue, May 6, 2008 at 9:03 AM, Tobia Di Pisa <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to use geoserver and I had your same problem. I had the last
> version of
>
> maven (2.0.9) and I have tried to downgrade it with the previous versions
I use maven 2.0.6 without any problems. Our build server uses 2.0.8.
-Justin
Alexander Petkov wrote:
> What maven version is everyone using?
> I have installed the latest (2.0.9 at this time) and for some reason
> geoserver does not build with it.
> I had to downgrade to a previous version in ord
Justin Deoliveira ha scritto:
> Yeah I saw that as well... and yes that is an issue on 1.6.x. But the
> real issue is the opengeo snapshot dependency from opengeo. I sent email
> about this yesterday but got no answer. CC'ing andrea as I am dubbing
> him "master of short build times"
Ha ha ha :
What maven version is everyone using?
I have installed the latest (2.0.9 at this time) and for some reason
geoserver does not build with it.
I had to downgrade to a previous version in order to complete the
compile. Here is the error snippet:
===
urls[29] = file:/
Yeah I saw that as well... and yes that is an issue on 1.6.x. But the
real issue is the opengeo snapshot dependency from opengeo. I sent email
about this yesterday but got no answer. CC'ing andrea as I am dubbing
him "master of short build times"
As a temporary solution what I will do for now i
See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/137/changes
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use
See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/136/changes
Changes:
[groldan] added easymock as test dependency for wms
[groldan] a single comment
[groldan] added some GetMapResponse unit tests
--
[...truncated 695 lines...]
at
So I think it is not geowebcache itself that is missing, but the gwc
module. release/pom.xml requires community/gwc , but running mvn clean
install inside release doesn't cause it to be built.
Of course you can only notice this problem on a machine where gwc has
never been built before :(
Not
Justin Deoliveira ha scritto:
> My thoughts:
>
> Config stuff goes well, almost ready to commit, a few loose ends to tie
> up... but all unit + cite tests pass.. i have hand tested most of the
> UI, etc...
>
> End of June for release candidate of 1.7.0 should be doable... but i
> fear its goin
27 matches
Mail list logo
