Hi,
I'm writing this mail to sum up the module cleanup
wiki page.
The mail is long, if you want to discuss a specific
module's fate, can you please reply changing the subject
to include the module name so that the thread generating
out of this mail gets a little organised?
Something like:
"Module
Hi all,
final mail for the modules that need to be moved.
The unsupported/ogc modules family is going to
be moved to extensions. Mind, the poms are missing
a maintainer declaration.
The wfs datastore module is going to be moved
to unsupported
The wms module is going to be moved to extensions?
(w
Hi,
in this mail I'm trying to summarize which unmaintained
modules are going to be reassigned (or which modules
get a one more maintainer).
demo/mappane-use -> mbedward
modules/library/coverage -> simboss, mbedward
modules/library/jdbc -> aaime
modules/library/metadata -> jgarnett
modules/library
> modules/unsupported/example
This one is still useful - it is used to "svn copy" when creating a new module.
> modules/unsupported/mif *
> modules/unsupported/tiger *
> modules/unsupported/vpf *
>
> If you don't want any of the above modules to be removed please speak up now.
I have heard of so
Notes about Module epsg/wkt
I use it because I have an app using geotools and the epsg database has
always no or incorrect boursa wolf parameters for Austria. So I have to
add/correct the TOWGS84 clause to the wkt definitions.
The file based approach is the easiest way to do this. If there is
Jody Garnett ha scritto:
>> modules/unsupported/mif *
>> modules/unsupported/tiger *
>> modules/unsupported/vpf *
>>
>> If you don't want any of the above modules to be removed please speak up now.
>
> I have heard of some of these being useful over the years; but yeah cut scope.
I agree, yet tho
Christian Müller ha scritto:
> Notes about Module epsg/wkt
> I use it because I have an app using geotools and the epsg database has
> always no or incorrect boursa wolf parameters for Austria. So I have to
> add/correct the TOWGS84 clause to the wkt definitions.
> The file based approach is the
Jody Garnett ha scritto:
>> The build/maven/javadoc plugin requires
>> some thought, it has that single taglet
>> that can be used to report in which module
>> the class appears in and a tool that can
>> be used to automate the insertion of the
>> taglet in the source code. Do we
>> want to keep it
I refactored the module on 2.5.x and 2.6.x to use the Repository inteface
and kicked off my DataStoreLookup interface.
You can see the changes also in the geotools user guide documentation.
So far, I have +1 from Andrea.
Would the "library" directory be the right place ?
Jody Garnett writ
Fine, I am with you
Andrea Aime writes:
> Christian Müller ha scritto:
>> Notes about Module epsg/wkt
>> I use it because I have an app using geotools and the epsg database has
>> always no or incorrect boursa wolf parameters for Austria. So I have to
>> add/correct the TOWGS84 clause to the
Andrea Aime ha scritto:
> Modules that need more work, checks
>
>
> The following need more checks in order
> to be removed (switch to Mojo equivalent
> plugins):
> build/maven/jjtree-javacc
I looked into jjtree-javacc usage. There are two
use cases for th
I second your suggestion aaime. In case it is needed svn is our friend.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
Jody Garnett ha scritto:
> What is confusing for me is this:
> - the uesr guide already documents this code; do you think we have had
> a regression?
> - Emily you needed to change the definition a bit; as far as I know
> the interesting part about supporting the google projection was adding
> supp
Emily Gouge ha scritto:
> I had the need the other day to use the projection 3785 in uDig. The
> current version of the epsg-hsql jar didn't support this projection code
> so I went digging.
>
> In the epsg-hsql I found Martin's instructions for updating the EPSG.sql
> file. So I followed the
hello Andrea,
when you say that modules/plugin/wfs will be moved to unsupported, when
is that likely to happen?
it's probably too early to tell, but if/when it happens will it be
before or after a stable GeoServer 2 is released?
On Sunday 17 May 2009 20:12:52 Andrea Aime wrote:
> Hi,
> in thi
Congratulations - and nice work on both your part and Andrea's part on
the rendering side. The correct place for your module (as I understand
it anyways) would be the modules/plugin directory - since this is a
normal DataStore right?
Jody
On Mon, May 18, 2009 at 5:53 AM, Christian Müller
wrote:
>> Once we have that H2 + zip file I believe there won't be any
>> more reason to work off the epsg-wkt file... or I'm still
>> missing something? (I mean, H2 + zip in classpath is not
>> really perceived as a database, doesn't it?)
That is my understanding as well; once we have H2+zip file then w
Okay that is clear. It still feels odd to drop a plugin that way; I
would feel safer moving them to unsupported for 2.5.x and dropping
them (and perhaps everything else we do not use) on 2.6.x.
Jody
On Mon, May 18, 2009 at 6:35 AM, Simone Giannecchini
wrote:
> I second your suggestion aaime. In
> In the main module it's used by an old text expression
> parser that is marked as deprecated (ExpressionBuilder).
Now that CQL works we can drop ExpressionBuilder.
> In the cql module it's used and I don't see an
> easy way to remove it. In particular, the parsing
> design fights again the jjtr
Gabriel, is this yours?
[INFO] Building ArcSDE DataStore plugin
[INFO]task-segment: [clean, install, eclipse:clean, eclipse:eclipse]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/car605/geoserver/src/geoto
ah, wait, usual dummy method missing... sorry... just a sec..
Ben Caradoc-Davies wrote:
> Gabriel, is this yours?
>
> [INFO] Building ArcSDE DataStore plugin
> [INFO]task-segment: [clean, install, eclipse:clean, eclipse:eclipse]
> [INFO]
> -
should be broken just temporarily while committing with specific message
per file instead of a single message for all of them? Can you update and
check again?
Cheers,
Gabriel
Ben Caradoc-Davies wrote:
> Gabriel, is this yours?
>
> [INFO] Building ArcSDE DataStore plugin
> [INFO]task-segmen
there you go, dummy method added, sorry for the grief
Gabriel
Gabriel Roldan wrote:
> ah, wait, usual dummy method missing... sorry... just a sec..
> Ben Caradoc-Davies wrote:
>> Gabriel, is this yours?
>>
>> [INFO] Building ArcSDE DataStore plugin
>> [INFO]task-segment: [clean, install, eclip
Gabriel Roldan wrote:
> there you go, dummy method added, sorry for the grief
No problem. Building now. I'll let you know if there are any problems.
Hmm, Hudson has been quiet. Wonder if it is asleep?
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Re
Christian,
I modified the parent artifact version from 2.5-SNAPSHOT to 2.6-SNAPSHOT
in modules/unsupported/feature-pregeneralized/pom.xml on trunk, a change
required to fix the build. Someone else had the same problem in another
module last week.
I hope you don't mind.
Kind regards,
--
Ben
Error calculating extents of a PostGIS Point Layer using PostGIS-NG
---
Key: GEOT-2488
URL: http://jira.codehaus.org/browse/GEOT-2488
Project: GeoTools
Issue Type: Bug
Thanks a lot
Ben Caradoc-Davies writes:
> Christian,
>
> I modified the parent artifact version from 2.5-SNAPSHOT to 2.6-SNAPSHOT
> in modules/unsupported/feature-pregeneralized/pom.xml on trunk, a change
> required to fix the build. Someone else had the same problem in another
> module la
Yes it is a datastore, but the difference is
1) depends on no external format, only on the SimpleFeature stuff
2) Is acting like a "multiplexer" on a set of other datastores
So, I was not sure here, because there are no dependencies to other libs
other than geotools itself.
Anyways, I am wai
Raif S. Naffah ha scritto:
> hello Andrea,
>
> when you say that modules/plugin/wfs will be moved to unsupported, when
> is that likely to happen?
>
> it's probably too early to tell, but if/when it happens will it be
> before or after a stable GeoServer 2 is released?
Before... not that this
Jody Garnett ha scritto:
> Okay that is clear. It still feels odd to drop a plugin that way; I
> would feel safer moving them to unsupported for 2.5.x and dropping
> them (and perhaps everything else we do not use) on 2.6.x.
All of them have been in unsupported for as long as I can
remember.
I jus
hello Andrea,
On Monday 18 May 2009 16:11:56 Andrea Aime wrote:
> Raif S. Naffah ha scritto:
> > hello Andrea,
> >
> > when you say that modules/plugin/wfs will be moved to unsupported,
> > when is that likely to happen?
> >
> > it's probably too early to tell, but if/when it happens will it be
>
Question: Does it have a DataStoreFactory? If so make it a plugin? I
have not reviewed the code carefully but I expect:
- a DataStoreFactory that advertises the need for a parameters
- one of the parameters will be a Repository
As long as the main interfaces being used here are DataStoreFactory
a
To make it more clear; the directory datastore is plugin; and it also
acts as a multiplexer (in a way) of individual datastores.
Jody
On Mon, May 18, 2009 at 4:44 PM, Jody Garnett wrote:
> Question: Does it have a DataStoreFactory? If so make it a plugin? I
> have not reviewed the code carefull
My personal opinion,
if there is *something* that no one officially support either inside
the core developers or outside, we should just drop it. However, I can
be flexible on the meaning of dropping it, we could create something
like a sandbox or dormant branch or subproject like apache has, but I
34 matches
Mail list logo
