On Sunday, 8 May 2011 at 6:54 PM, Mathieu Baudier wrote:
* As long as FactoryFinders work the library will function
> > And leaves me with the following problem to wrestle with:
> > - Can we "fix" FactoryRegistery (and fold out code in behind it?)
> > - Or do we need to just flat out replace it
> I
> * As long as FactoryFinders work the library will function
> And leaves me with the following problem to wrestle with:
> - Can we "fix" FactoryRegistery (and fold out code in behind it?)
> - Or do we need to just flat out replace it
I just bumped in the Apache Commons Discovery project (via an A
> Don't know about the rest, but gt-util seems like a bad name to me
> would make me think it's a module filled with assorted utility classes.
I do agree with Andrea: I would intuitively look for "optional"
utilities/helpers in a module named gt-util.
> I took the name from a discussion we ha
I took the name from a discussion we had some time ago; when I wanted to kick
all the utility classes out of gt-metadata. The utility classes cover all kinds
of generic Java hacking (logging system; collections, etc...) and not only the
plugin system.
--
Jody Garnett
On Saturday, 7 May 2011 a
On Sat, May 7, 2011 at 8:28 AM, Jody Garnett wrote:
> I have added the "plugin" branch here:
> - http://svn.osgeo.org/geotools/branches/plugin/
> Thus far my plan is to:
> 1) commit my andriod hack into plugin/spike/andriod
> It has taught me that:
> - ServiceProvider is avaialble in Java 6 (and
I have added the "plugin" branch here:
- http://svn.osgeo.org/geotools/branches/plugin/
Thus far my plan is to:
1) commit my andriod hack into plugin/spike/andriod
It has taught me that:
- ServiceProvider is avaialble in Java 6 (and Andriod)
- The complicated imageio ServiceRegistery we use is n
