> > we already use several
> > "commons" libraries for the same purpose. Is there any chance we could
> > replace our use of commons collections and so forth? We do use use commons
> > ObjectPool as a cache for example in geotools.
> >
>
>
>
> Here's a patch the replaces commons-pool in on GeoTools
> modules/library/*
> <https://github.com/groldan/geotools/commit/7399772222d603916c1919a36b09f09ad25d6f72>
> It's surely not perfect, referencing is a scary beast and I made it in
> a rush. But it saves us 840 lines of code (counted with cloc), and
> IMHO has the potential to make the module less scary.
> Besides we get to use a caching library for caches instead of a pooling
> library.
>
>
You drive a hard margin; there is like no way I can argue with a patch that
simplifies the crazy
caching code in gt-referencing (especially since I introduced ObjectPool to
remove the earlier cost caching code etc..).
Still I want to release the 8.x stream before doing anything much more to
GeoTools.
We are welcome to peruse this library for GeoServer prior to that point. I also
have some uDig code that used the earlier google collections library that I can
fix up (and get some experience).
So you are getting two bits of feedback:
- Yes - but not for GeoTools until after 8.0
- A good trade if we cut down or out the other dependencies (coming from
GeoTools)
So can we put this off until after 8.x? Or if we have to we could arrange a
couple day sprint to work on a github fork as a team and cut down on
dependencies etc.
At the very least I don't want to mess up 8.x with an experiment this late in
the game.
Cheers,
Jody
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
