Hi,
I'd just like to clarify that uDig 1.1.x based on Geotools 2.2.x but making no changes to it beyond bug fixes and uDig 1.0.6 (released in December) is the last release that will use 2.1.x. The 1.0.x branch no longer sees any development.
Cheers,
Jesse
-------- Original Message --------
Subject: [Geoserver-devel] 1.4.x and trunk
Date: Tue, 28 Feb 2006 03:27:56 -0500
From: dblasby@anonymised.com
CC: geoserver-devel@lists.sourceforge.netOkay, 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=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
