Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.
Justin pointed us in the direction of 1.7.x/2.5.x - did you have any plans/schedule to port this work to trunk? Also if you had any feedback on this technique for integration now would be an excellent chance (before another team has a go at the problem).
Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.
It looks like this class (CatalogRepository) should be thrown into main,
since this Repsitory adapter will need to be reused among geotools
datastores which need to access the geoserver catalog in this way.
Any objections to moving copying this on feature-pregeneralized on 1.7.x
into main on trunk?
On Thu, 25 Jun 2009 11:38:46 +0800, Jody Garnett <jody.garnett@anonymised.com>
wrote:
Hi Christian:
Justin pointed us in the direction of 1.7.x/2.5.x - did you have any
plans/schedule to port this work to trunk? Also if you had any
feedback on this technique for integration now would be an excellent
chance (before another team has a go at the problem).
Jody
On 25/06/2009, at 10:59 AM, <Rini.Angreani@anonymised.com>
<Rini.Angreani@anonymised.com
> wrote:
Hi Christian,
Jody and I are about to look at your work on geoserver datastore
registry used for your pregeneralization info provider. I am looking
to probably use your existing code for my app-schema feature
chaining work. Just giving you a heads up, in case we need your help.
1) the gt-feature-pregeneralized module is already in geotools trunk
2) the feature-pregeneralized geoserver module is waiting for migration, see GEOS-2887,
I tried to migrate some times ago without success, so I will leave this to Justin.
Justin, you can put the geoserver parts into main as you like. If you want to alter the package names, give me a ping, I have to update the tutorial in sphinx.
Jody, 2 weeks ago I created GEOT-2546, I waiting for an ok, this is the LAST issue for IBM SDK builds (geotools and geoserver). grrrrr
Justin Deoliveira writes:
It looks like this class (CatalogRepository) should be thrown into main,
since this Repsitory adapter will need to be reused among geotools
datastores which need to access the geoserver catalog in this way.
Any objections to moving copying this on feature-pregeneralized on 1.7.x
into main on trunk?
On Thu, 25 Jun 2009 11:38:46 +0800, Jody Garnett <jody.garnett@anonymised.com>
wrote:
Hi Christian:
Justin pointed us in the direction of 1.7.x/2.5.x - did you have any plans/schedule to port this work to trunk? Also if you had any feedback on this technique for integration now would be an excellent chance (before another team has a go at the problem).
Jody
On 25/06/2009, at 10:59 AM, <Rini.Angreani@anonymised.com>
<Rini.Angreani@anonymised.com > wrote:
Hi Christian,
Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.
1) the gt-feature-pregeneralized module is already in geotools trunk
2) the feature-pregeneralized geoserver module is waiting for migration, see GEOS-2887,
I tried to migrate some times ago without success, so I will leave this to Justin.
Sure, I will throw it on the list. Do you know if there are any api changes that will affect the module? If so I will need your help.
Justin, you can put the geoserver parts into main as you like. If you want to alter the package names, give me a ping, I have to update the tutorial in sphinx.
Sure, I was thinking the logical place would just be in org.geoserver.catalog. I can post a patch before I commit just to give you warning.
Jody, 2 weeks ago I created GEOT-2546, I waiting for an ok, this is the LAST issue for IBM SDK builds (geotools and geoserver). grrrrr
Looked it over, patch looks fine to me. It is also just a test class, so i don't think anyone will raise much of a fuss.
Justin Deoliveira writes:
It looks like this class (CatalogRepository) should be thrown into main,
since this Repsitory adapter will need to be reused among geotools
datastores which need to access the geoserver catalog in this way.
Any objections to moving copying this on feature-pregeneralized on 1.7.x
into main on trunk?
On Thu, 25 Jun 2009 11:38:46 +0800, Jody Garnett <jody.garnett@anonymised.com>
wrote:
Hi Christian:
Justin pointed us in the direction of 1.7.x/2.5.x - did you have any plans/schedule to port this work to trunk? Also if you had any feedback on this technique for integration now would be an excellent chance (before another team has a go at the problem).
Jody
On 25/06/2009, at 10:59 AM, <Rini.Angreani@anonymised.com>
<Rini.Angreani@anonymised.com > wrote:
Hi Christian,
Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.
Cheers
Rini
The CatalogRepository class is never referenced directly. The class name is used as a datastore string parameter and an object is created with
Class.forName(...) and so on.
The only dependency is the text in the tutorial
Justin Deoliveira writes:
Hi Christian,
Christian Müller wrote:
1) the gt-feature-pregeneralized module is already in geotools trunk
2) the feature-pregeneralized geoserver module is waiting for migration, see GEOS-2887,
I tried to migrate some times ago without success, so I will leave this to Justin.
Sure, I will throw it on the list. Do you know if there are any api changes that will affect the module? If so I will need your help.
Justin, you can put the geoserver parts into main as you like. If you want to alter the package names, give me a ping, I have to update the tutorial in sphinx.
Sure, I was thinking the logical place would just be in org.geoserver.catalog. I can post a patch before I commit just to give you warning.
Jody, 2 weeks ago I created GEOT-2546, I waiting for an ok, this is the LAST issue for IBM SDK builds (geotools and geoserver). grrrrr
Looked it over, patch looks fine to me. It is also just a test class, so i don't think anyone will raise much of a fuss.
Justin Deoliveira writes:
It looks like this class (CatalogRepository) should be thrown into main,
since this Repsitory adapter will need to be reused among geotools
datastores which need to access the geoserver catalog in this way.
Any objections to moving copying this on feature-pregeneralized on 1.7.x
into main on trunk?
On Thu, 25 Jun 2009 11:38:46 +0800, Jody Garnett <jody.garnett@anonymised.com>
wrote:
Hi Christian:
Justin pointed us in the direction of 1.7.x/2.5.x - did you have any plans/schedule to port this work to trunk? Also if you had any feedback on this technique for integration now would be an excellent chance (before another team has a go at the problem).
Jody
On 25/06/2009, at 10:59 AM, <Rini.Angreani@anonymised.com>
<Rini.Angreani@anonymised.com > wrote:
Hi Christian,
Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.
Cheers
Rini
Christian: I actually did not move any classes in the extension, just deprecated it and extended the version I copied to main.
-Justin
Rini.Angreani@anonymised.com wrote:
Hi Christian,
Jody and I are about to look at your work on geoserver datastore registry used for your pregeneralization info provider. I am looking to probably use your existing code for my app-schema feature chaining work. Just giving you a heads up, in case we need your help.