Re: [Geoserver-devel] 1.4.x and trunk

[Alessio F. <ale...@gm...>]

Hi David,

if you are interested the Geoserver-WCS branch is aligned with 1.3.0 (SVN
merged) and uses GeoTools 2.2.x succesfully.
Maybe it can be a good start point for you to do a porting to gt 2.2.x.

Cheers,
               Alessio.

On 2/28/06, db...@op... <db...@op...> wrote:
>
> Okay, I talked to some of the Udiggers and apparently their unstable
> development branch is going to use geotools 2.2.x and they are "happy"
> with it.
>
> The udig stable branch, as far as I know, is still based on geotools
> 2.1.x (see the udig mailing list and their homepage) - just like
> geoserver 1.3.x (stable).
>
> As far as moving to new geotools versions in the future, I'd like to
> have a bit more of a conservative approach.  Geotools is definitely
> NOT conservative, so I think we have to be.  For one thing, I don't
> just want to move to the latest geotools unless its a *real* stable
> branch (not just someone saying "okay, lets call what we have now 2.#,
> label is "stable" so we can forget about supporting it). That means we
> need geotools to think that its good, and are planning to maintain it.
> Also, we shouldn't move to it until udig does too.
>
> So, before we move to a new geotools:
>
> 1.  Geotools needs to say that the "new" branch is stable, good, and
> recommend that all users use it (or transition to it).  This should be
> on their front page as the "version we recommend people use, report
> bugs against, and submit patches for".
> 2.  We evaluate the branch and see if its "good" and if we want to move
> to it.
> 3.  We wait (or get) udig to move to it
> 4.  We move to it.
>
>
> I'm a bit concerned with 2.2.x because it wasn't really advertised as
> existing. The messages about its formation are basically "we're really
> gonna be stirring up the API now, we better put out 2.2 now or we'll
> never be able to".  It appears that the official announcement was
> just a message saying, "I took the liberty of creating the 2.2.x
> branch." Not exactly confidence instilling!
>
>
>
>
> I am very concerned that geoserver will start following the path that
> geotools has taken (add lots of "new" exciting things but don't
> actually maintain what's already there).  Unfortunately, this path has
> caused a lot of frustration for their developers and users.  So much
> so that they are actually losing developers and credibility. I do not
> want to see this happen to geoserver.
>
> I see a lot of talk about "new" exciting R&D work for geoserver, but
> very little about maintaining and improving whats actually already
> there.
>
> There's *a lot* of work to do in geoserver that does NOT include any
> changes to geotools or re-architecturing geoserver.  There's also a
> *gigantic* amount of basic maintenance and bug fixes required in
> geotools. I'm not even talking about adding any new features - just
> getting the ones that are already there working well!  I just want to
> hear that we're actually going to be spending resources improving
> things -- not just adding new things.  This work isn't glamorous or
> fun, but it necessary.  Its doubly necessary since this is the
> opposite of what's happening in geotools.  We need users (potential
> and current) to know that we take useablity and stability (in terms of
> things working well) seriously. We need focus!
>
>
>
> But, onto the 1.4 in specifics.
>
> So, the main change in 1.4 is moving to geotools 2.2.  But, the most
> obvious one is that everything has been shuffled around and there's a
> new build system.
>
> Here's some comments/questions:
>
> 0. This shuffle needs to be evaluated.  Is it good?  Is there still
> more to do?  I havent seen any discussion about it - I have no clue
> whats happened.
>
> 1. We need to update ALL the documentation to account for this.
> There's no use in having "How does a GetFeature request work?"
> documentation if you get lost in the 1st step.  We also need new
> documentation so current developers can figure out whats going on - I
> know I'm lost.
>
> If it isnt updated, then we have two other major problems:
>
> a) people who are new to geoserver will not take us at all
> seriously if documentation and reality are massivily out-of-alignment.
> b) by not updating existing documentation you are telling the
> saints who actually write it that their efforts are in vain.  It hard
> enough to get people to write documentation, but impossible if you're
> going to obsolute it and not correct it.
>
> 2. The build system is still a bit clunky.  It takes me just under 10
> minutes to do a build.  Under the old system it would take at most 1.5
> minutes - most of the time it would take less than 1/2 a minute.
>
>   a) I need an easy way of being able to do a geotools build and
> have geoserver restart with the new jars.  Under the old system I had
> a 3 line script that would (a) build geotools (b) copy the gt main jar
> to the geoserver lib/ directory (for future builds) and (c) copy the
> jar to the deployed server's lib/ directory.  That way I could just
> stop geoserver, run my script, and then restart geoserver.  I'd have
> the same configuration with the new jars up in less than a minute
> (most of that time spent building geotools).  This makes doing
> geotools development (and testing) easy.  I'm completely lost in the
> new system.
>
>   b) I also need a way to build a new geoserver.jar and put it
> inside the deployed server.  There is an ant task to do this (I think
> its called "move geoserver.jar") - its only 2 lines long.  This allows
> me to quickly make changes to geoserver and run test them in the same
> configuration.
>
> In fact, the only time I do a full geoserver build is when I modify
> the .jsp file or deploy a new configuration (and if I did the latter
> more often I'd have an ant task to just refresh the .jsps in the
> deployed server).  10 minutes is *forever*.  If I do that 6 times, it
> means that I've wasted an entire hour.  I *hate* being that
> unproductive.
>
> 3. I'd like to hear what the raster branch people think.  Its probably
> going to take them a while to merge their old-and-modified-version to
> the new-and-modified-and-shuffled version.
>
> 4. Are all the changes taking place on the current trunk in 1.4?
> Who's moving changes between the stable branch and trunk?  How about
> moving bug fixes between 1.4 and the stable branch?
>
> 5. Who's doing maintance?  Do they have actual time to do it?
>
> 6. I'd like to continue having a new stable release every 2-4 weeks.
> That means  releases on the stable branch, not 1.4 releases.  1.4 can
> release on whatever schedule it wants - just make sure that we clearly
> differenciate between the two so people dont accidently download one..
>
> 7. Dont merge big changes onto trunk until they are actually *very*
> good.
>
>
>
>
> Geoserver has greatly improved over the last year I've been involved -
> thats mostly because I concentrated on making it useable and doing all
> the really boring work of fixing bugs and systematically going through
> geoserver and geotools to make sure things work.  And by "work" I mean
> (1) they're not buggy (2) they do what they're supposed to do (3) they
> are easy to use (4) there's documentation on them.  I think everyone
> can agree that there needs to be a lot more work done - both in
> geoserver,
> and certainly in geotools.  I'd like to see this continue.  I really
> want to make sure (just to repeat myself a fourth time) that there
> is a significant effort made in maintainance and improving things -
> not just adding new features.  From the way people are talking I dont
> know if this is the same as other people's goals. Sure, its fun to add
> the new stuff, but its extreamly important to make sure whats there is
> improving too.  We're asking people to trust their spatial data
> infrastructure (including updating it) to us.
>
> *I* want to actually use geoserver to do a bunch of geowiki stuff - I
> need a stable platform to do that.
>
> dave
>
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Geoserver-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>