Hi Andrea,

I am also working with Lim on this project.  This list has already proven to
be a very valuable resource for us.  I have a couple of follow-up questions
with regard to your reply.  One of the areas which I will be working on is
testing.  I understand that we will need to create a test class for each
class we create.  Are these in addition to the over 150 test cases which you
mentioned?  Our initial thought was that we would use an application making
use of geoserver to ensure that geotools was able to interface correctly
with ingres. (i.e. a geoserver demo of some sort which would perform
operations that rely on geotool's ability to read and write to external
databases (i.e. ingres))  Do you see this as a necessary step, or should the
JUnit tests be sufficient?  My apologies if I'm asking anything that should
be obvious.

Thanks,
Anthony

On Sun, Jan 17, 2010 at 6:55 AM, Andrea Aime <aa...@opengeo.org> wrote:

> lim goh ha scritto:
> > We expect to perform multiple check-ins for collaboration within our
> > team. I think we are going to setup a separate duplicate repository of
> > Geotools on the Ingres server and use a two-phase check-in process. In
> > other words, we will send a patch to Geotools along with relevant
> > documentations for review and commit. Right now we are still in the
> > planning stage, and we will draw up a proposal outlining our design,
> > plan, timeline estimation, etc and post onto this list, and hopefully
> > someone will be able to tell us whether we are on the right track, and
> > where we are making mistakes.
>
> That sounds good. As a possible alternative you can also work
> directly against the GeoTools trunk svn, in the community area.
> Community modules are not in the build by default, and are a good
> way to stage and work against new modules without impacting negatively
> the rest of the project.
> Of course you're given access with the agreement that you only commit
> against your own module, any commit outside of it (besides obvious
> mistakes) will result in you losing commit access.
>
> As for the Ingres support, I suggest you have a look at the various
> database classes in modules/library/jdbc and in plugin/jdbc
> where we have the support for PostGIS, Oracle, DB2, MySql, SQL Server
> and SpatiaLite.
>
> Adding support for a new database is not too hard, you have to implement
> a SQLDialect subclass that factors out the specificities of your
> database (usually how to handle geometries and how to handle spatial
> filters) and then subclass all the test setups for your specific
> database and make sure all of the over 150 tests pass against your
> database as well.
>
> If for any reason you need to change something in the core classes
> you'll have to discuss the changes with the core JDBC developers,
> that is, me, Justin Deoliveria and Christian Mueller.
> That is sometime necessary as a new database may require to do things
> differently (that happened a lot with Oracle for example) but
> we need to review the changes carefully to make sure things keep
> on working for all databases.
>
> Of course we also suggest you to read the GeoTools developer
> guide and get familiar with the code.
>
> In any case you're starting with the right footing, the first and
> most important step is communication. Well done.
>
> Cheers
> Andrea
>
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to