"Writting our own code" versus "introducing an other dependency" is probably a
case-by-case basis. In the particular case of Joda library, we have a standard
Java class (GregorianCalandar) with lot of defaults, but doing enough work for
allowing us to wait for the inclusion of a Joda-like library in JDK 7. Writing
the org.geotools.temporal package on top of GregorianCalander didn't took two
weeks and result in a single small class, compared to the ~400 kb of Joda JAR.
One one side, peoples don't want to rewrite stuff. On the other side, peoples
point us that the number of dependencies is a GeoTools killer for some
potential
users. The referencing module has be mentioned as an example of a GeoTools
module not used by some projects because it is not downloadable as a single
JAR.
Adding Joda in the mix would make things worst.
The "don't rewrite stuff" approach is exactly what has lead me to leverage
javax.media.jai.Range in the referencing module, thus making it dependent on
JAI. It has been a strong complain against referencing. Jody and myself have
spent days producing a replacement (it was not so simple that it may looks
like). The argument was that introducing a dependency to a library as big as
JAI
for a single class was exagerated.
So as you can see there is really a strong pressure for rewriting our own stuff
in some cases. JAI's NumberRange was a very strong case. I think that Joda is
an
other case since we can (for now) work on top of GregorianCalendar and
DateFormat.
Martin
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
