Hi Andrea and all, Thank you for your reply and clarification, the alternative sounds good and maybe we should just do that. A few questions though (please forgive my ignorance being on an open-source project for the first time): - What is a community area? Is it a seperate branch or folder? How does it eventually move into the public releases? If it is not clearly separated from the release build, how can we make sure alpha/beta quality check-ins do not break existing functionalities or maybe disabled until we are sure?
- How exactly are check-ins authenticated? I ask this because we will need to ask for access for 4 of our team members and I am not sure if its as easy as a registration web-interface, or providing a username and email addresses. If there is a particular person we need to talk to, who will it be? Also, we took a quick glance at the other database classes (in fact we learnt from the wiki how to setup eclipse projects and navigate the source tree that way), indeed we found the SQLDialect classes you mentioned and suspected that is where we need to start. Interestingly for each of the database we found gt-<dbname> projects as well as gt-jdbc-<dbname> projects and also tried to make sense out of them. Our initial guess is that the gt-<dbname> ones are deprecated and will/should not be used anymore. Can we get a confirmation that it is the case? In other words, we need to create one new module that extends the new jdbc module and expect the framework we work on to work. And we can also safely ignore the deprecated code and not worry about working against those interfaces scheduled to be removed in 2.7? I apologize for the long email. Thank you very much for your kind perusals. 2010/1/17 Andrea Aime <[email protected]>: > 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. > -- L I M ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
