Jody Garnett wrote:
Justin Deoliveira wrote:
Yeah, with the new feature model, the DataStore api needs an overhaul
if it is going to be capable of using the full power of the new model.
Talk more guys, I know that the locking system needs a tweak - see
geoapi for the exact workflow that we need.
The GeoAPI datastore abstract is not very good in that it misses out on
the seperation between IService and IGeoResource.
But I also need to do a sanity check ...
We are focused on just changing the FM model - no increase in scope :-)
I want to succeed here, are goal is not to fix all of geotools in one
go, just the feature model. I know that the new FM open up a lot of
doors but we must resist.
I agree, I dont want to increase scope since getting the core of the new
feature model is going to be enough work as it is. But I think it is
important to keep an open eye to things in DataStore that must change,
or else how can you really justify this new feature model?
Jody
Gabriel Roldán wrote:
Sounds very good Justin.
Aside from the jira tasks it would be great if you can start a wiki
page on the spirit of "migration guide", may be just linking to the
jira issues by now, but it can evolve as we start porting datastores.
By the other side, it would be great having a datastore api review
before starting the port of datastores, like the stuff we discussed a
couple week ago and I never made the time to write it up? :)
thanks for being committed to this even if you're sick!
Gabriel
On Friday 05 May 2006 10:22, Justin Deoliveira wrote:
Hi folks,
As we all know FM has been out on a branch for quite some time now.
Checking the subversion history it was pulled over on Mar 1st. My worry
is that we are going to miss out on a lot of bug fixes in the datastore
modules (like the work dave has done on postgis recentley, and jesse's
continued improvements to shapefile).
So, I am not sure if something like this is already in the works, but I
would like to propose the following strategy for porting modules to FM:
1. Sync up module between 2.2.x and trunk
2. Copy module from trunk to FM
3. Create JIRA task so we can catch any bug fixes that occur on 2.2.x /
trunk after this point
4. Port module to new feature model on FM
5. Merge any outstanding bug fixed to FM
If this sounds reasonable to people I can write this up go through and
create a jira task for the entire process, with sub tasks for each
module. Do we have a single place to whip up docs for FM? I see a bunch
of stuff under http://docs.codehaus.org/display/GEOTOOLS/2.3.x
-Justin
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
