+1
Il giorno 08/giu/2011 09.12, "Andrea Aime" ha
scritto:
> On Wed, Jun 8, 2011 at 3:43 AM, Justin Deoliveira
wrote:
>> Yeah, a 2.1.1 release sounds good to me. I am actually waiting for it to
be
>> release to backport the label obstacle fix and ship that to the customer.
>> Also with regard to
On Wed, Jun 8, 2011 at 3:43 AM, Justin Deoliveira wrote:
> Yeah, a 2.1.1 release sounds good to me. I am actually waiting for it to be
> release to backport the label obstacle fix and ship that to the customer.
> Also with regard to backport there are actually two other issues I was
> hoping to ba
Yeah, a 2.1.1 release sounds good to me. I am actually waiting for it to be
release to backport the label obstacle fix and ship that to the customer.
Also with regard to backport there are actually two other issues I was
hoping to backport:
http://jira.codehaus.org/browse/GEOS-4343
http://jira.co
It would be worth to release 2.1.1 now IMHO and fix the rest for 2.1.2.
Simone.
Il giorno 07/giu/2011 21.37, "Andrea Aime" ha
scritto:
> Hi all,
> GeoServer 2.1.0 has been released almost one month ago, so I was
> wondering if it's
> time to think about making a 2.1.1
>
> The changelog so far it
Hi all,
GeoServer 2.1.0 has been released almost one month ago, so I was
wondering if it's
time to think about making a 2.1.1
The changelog so far it's the following, with 29 tickets closed:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+fixVersion+%3D
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> That's why I ended up discarding it the first round of evaluations. It
>> may work, but we have to lower the barrier of what we want out of our UI.
> So what would we need to relax to use GWT? Probably the ability to
> "drop" more functionality int
Andrea Aime wrote:
> That's why I ended up discarding it the first round of evaluations. It
> may work, but we have to lower the barrier of what we want out of our UI.
So what would we need to relax to use GWT? Probably the ability to
"drop" more functionality into GeoServer in jar form.. leaving
Andrea Aime wrote:
> [EMAIL PROTECTED] ha scritto:
>> So the talk wasn't enough to make any strong statements, but I was
>> left with the impression that unless you want to Grails for the sake
>> of Groovy, then there was little reason to consider anything but GWT
>> or Wicket (ie. Tapestry and
Chris Holmes ha scritto:
> Arne and I are right now at:
>
> Choosing Your Java™ Technology-Based Web Framework: A Comparison
>
> https://www28.cplan.com/cc191/sessions_catalog.jsp?ilc=191-1&ilg=english&isort=&isort_type=&is=yes&icriteria9=TS-6457
>
Btw, I looked at the abstract and there is no
[EMAIL PROTECTED] ha scritto:
> So the talk wasn't enough to make any strong statements, but I was left
> with the impression that unless you want to Grails for the sake of
> Groovy, then there was little reason to consider anything but GWT or
> Wicket (ie. Tapestry and Struts 2 got grounded).
>
So the talk wasn't enough to make any strong statements, but I was
left with the impression that unless you want to Grails for the sake
of Groovy, then there was little reason to consider anything but GWT
or Wicket (ie. Tapestry and Struts 2 got grounded).
I'm not the best person to ask, but
Just to chime in with my thoughts. Chris's suggestion of pure REST +
templating is quite tempting, just from a simplicity standpoint. easy to
understand how it works, low entry barrier, etc...
However in the end I think I agree with Andrea, an approach based on
this we will end up writing a lot
Arne and I are right now at:
Choosing Your Java™ Technology-Based Web Framework: A Comparison
https://www28.cplan.com/cc191/sessions_catalog.jsp?ilc=191-1&ilg=english&isort=&isort_type=&is=yes&icriteria9=TS-6457
So hopefully this will provide us with the answer at the end ;)
Andrea Aime wrote
Chris Holmes ha scritto:
> Ok, cool. Yeah, that was my fear with it, but then I saw that Hudson's
> user interface looked pretty nice. But it looks like you've already
> done a pretty full evaluation. Oh well, it was a nice dream to have for
> a bit :)
Eh, I was started the same way, I downl
Ok, cool. Yeah, that was my fear with it, but then I saw that Hudson's
user interface looked pretty nice. But it looks like you've already
done a pretty full evaluation. Oh well, it was a nice dream to have for
a bit :)
Chris
Andrea Aime wrote:
Chris Holmes ha scritto:
...
Ok, I don't w
Chris Holmes ha scritto:
...
> Ok, I don't want to dictate technology choices at all, since I won't
> be working with the codebase. But I do want REST as a first class
> citizen, in some ways even more so than the UI. So from my
> perspective it seems like having a technology that can handle bot
Andrea Aime wrote:
Chris Holmes ha scritto:
Apologies for not being all up on this thread, hopefully soon I'll
find some time to sit down and digest it all. But I wanted to throw
out a thought on UI.
Instead of picking a full blown UI framework we could consider just
using a template lang
Chris Holmes wrote:
> There obviously are some open questions in this approach, like what is
> lacking versus the full blown UI technologies - things like
> internationalization, ect. But I think we should do our UI technology
> evaluation hand in hand with our rest stuff.
I don't think I have
Chris Holmes ha scritto:
> Apologies for not being all up on this thread, hopefully soon I'll find
> some time to sit down and digest it all. But I wanted to throw out a
> thought on UI.
>
> Instead of picking a full blown UI framework we could consider just
> using a template language, like f
Apologies for not being all up on this thread, hopefully soon I'll find
some time to sit down and digest it all. But I wanted to throw out a
thought on UI.
Instead of picking a full blown UI framework we could consider just
using a template language, like freemarker, to provide the UI through
So in Tuesday's meeting we figured out the scope for Geoserver 1.7,
renaming this subject line to match ...
Andrea Aime wrote:
> The "eat your own dog food" argument is good, but I expect the REST
> api to have its own battery of unit and functional tests (my position
> atm is to vote -1 for any c
Luca Morandini ha scritto:
> Andrea Aime wrote:
>> My plan was to tackle this by making the UI pluggable, but still pure
>> java.
>
> Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
Wicket is as pure java as it gets, you only have to write a (pure) html
file with ids an
Andrea Aime wrote:
>
> My plan was to tackle this by making the UI pluggable, but still pure
> java.
Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
> That is, each module has its own configuration UI module, if you
> don't want to use it, don't include its jar and yo
Saul Farber ha scritto:
> 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
Jody Garnett ha scritto:
> 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 toge
Luca Morandini ha scritto:
> 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
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
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
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:
>>
>> 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
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
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 going to be a bit shaky for the first few release
Chris Holmes wrote:
> So at TOPP we're taking a bit of a hiatus from paid work to focus on
> some core improvements on GeoServer which should hopefully make future
> development even faster. We've focused a lot on user facing features
> in the past couple years, neglecting some core annoyances.
So at TOPP we're taking a bit of a hiatus from paid work to focus on
some core improvements on GeoServer which should hopefully make future
development even faster. We've focused a lot on user facing features in
the past couple years, neglecting some core annoyances.
Chief among those is the cor
41 matches
Mail list logo
