Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Hi all,
>>
>> All done, xml and jdbc have been ripped out of main.
>>
> Did we do "data"?
No I didn't I didn't know data was on the table. Looking at what would
need to be done, there are a few wrinkles.
1. There is a dependency from the SLDPar
Justin Deoliveira wrote:
> Hi all,
>
> All done, xml and jdbc have been ripped out of main.
>
Did we do "data"?
> One notable thing I had to do to make it work as remove all the
> dependencies from the feature model on the GMLSchema class.
>
That makes sense.
> The dependency was in setting t
Done and done.
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>> All done, xml and jdbc have been ripped out of main.
>
> Thanks Justin :).
>
> Would you like to assign http://jira.codehaus.org/browse/GEOT-983 to yourself
> and close it?
>
> Martin
>
>
Justin Deoliveira a écrit :
> All done, xml and jdbc have been ripped out of main.
Thanks Justin :).
Would you like to assign http://jira.codehaus.org/browse/GEOT-983 to yourself
and close it?
Martin
-
Using Tomcat
Hi all,
All done, xml and jdbc have been ripped out of main.
One notable thing I had to do to make it work as remove all the
dependencies from the feature model on the GMLSchema class.
The dependency was in setting the namespace of a feature type when one
is not specified. Some of the type build
Paul Ramsey a écrit :
> I was just looking through the "extras" factory here:
>
> http://svn.geotools.org/geotools/branches/2.3.x/plugin/epsg-ext-esri/
>
> and I noticed it didn't have some well-known unofficial, but non-ESRI
> numbers, like 42102, or 41001.
>
> We could have yet-another-ext f
Martin,
I was just looking through the "extras" factory here:
http://svn.geotools.org/geotools/branches/2.3.x/plugin/epsg-ext-esri/
and I noticed it didn't have some well-known unofficial, but non-ESRI
numbers, like 42102, or 41001.
We could have yet-another-ext factory, for all things not-ep
Ok starting split
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>> Can I go ahead, or are there still some commits coming from you?
>
> Ready for going away. Sorry for the delay...
>
> For other developpers, I would suggest to wait a little bit before to come
> back
> to the "tr
Adrian Custer a écrit :
> If the alternative is for you to do a review, do you have any schedule
> for such a review?
Around one year ago... This is an other topic where I have been unable to meet
the deadline I told.
I hope to start looking at it next week.
Martin
--
Justin Deoliveira a écrit :
> Can I go ahead, or are there still some commits coming from you?
Ready for going away. Sorry for the delay...
For other developpers, I would suggest to wait a little bit before to come back
to the "trunk" pool...
Martin
I have a bunch of DB2 fixes on 2.2.x that need to go into 2.3. It
shouldn't be a problem except that mvn install fails on 2.3.x due to syntax
errors in the pom.xml files and I haven't pursued this for the past week.
At 04:51 PM 10/23/2006, Adrian Custer wrote:
>hey all,
>
>I'd suggest doing a f
Chris Holmes wrote:
> Ok, then Martin's proposal should be to updated to delete ext/shape
> instead of renaming it, no?
>
> Though looking at trunk and 2.2.x I see no reference to indexing in
> the ShapefileDatastoreFactory, which is where it's needed for us to
> use it at all... Perhaps you're
Hi Martin,
Can I go ahead, or are there still some commits coming from you?
-Justin
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-
Using Tomcat but need to do more? Need to support web services, securit
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061023170819Lbuild.63
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integra
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061023165750
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated techn
On Mon, 2006-10-23 at 17:06 -0400, Martin Desruisseaux wrote:
> So the question is: do we want to release Geotools anyway and tell the users
> that the coverage part may be less frozen than some other Geotools parts?
If the alternative is for you to do a review, do you have any schedule
for such
Adrian Custer a écrit :
> As I understand it Simone is using the branch. uDig will port to it.
> That will flesh out bugs. Those bugs can be addressed in 2.3.x releases
> just as well as they could prior to 2.3.0. Are there active bug fixes
> happening on 2.3.x? Is there any reason to hold back on
hey all,
I'd suggest doing a formal release of 2.3.0.
As I understand it Simone is using the branch. uDig will port to it.
That will flesh out bugs. Those bugs can be addressed in 2.3.x releases
just as well as they could prior to 2.3.0. Are there active bug fixes
happening on 2.3.x? Is there any
Jody Garnett wrote:
Martin Desruisseaux wrote:
Chris Holmes a écrit :
But sometime I'd really like to see indexed shapefile and shapefile
united. Indexed shapefile already has the hooks to just be an option
for a shapefile, on creation you can just specify which one you want.
Seems a bit
Andrea Aime wrote:
> Hi,
> some times ago I remember a discussion with Jody and Jesse about FID
> generation in datastore transactions (inserts) and the fact that we should
> wait
> after the end of transaction to check what FID has been assigned to new
> features.
>
That is true, at a basic
Chris Holmes wrote:
> One question, on the spec itself, can we specify the behavior per
> featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4.
Please !
> If we have diverse datastores, then what do we do? Aggregate a
Martin Desruisseaux wrote:
> Chris Holmes a écrit :
>
>> But sometime I'd really like to see indexed shapefile and shapefile
>> united. Indexed shapefile already has the hooks to just be an option
>> for a shapefile, on creation you can just specify which one you want.
>> Seems a bit silly t
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-2.3.x?log=log20061023135046Lbuild.1
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrat
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061023134244Lbuild.60
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integra
I think this has been on Jesse's list of things to do for some time now.
Martin Desruisseaux wrote:
> Chris Holmes a écrit :
>> But sometime I'd really like to see indexed shapefile and shapefile
>> united. Indexed shapefile already has the hooks to just be an option
>> for a shapefile, on crea
Actually, taking a look at the xml schema for the capabilities doc, it
appears you can specify operation metadata globally and at the feature
type level.
Chris Holmes wrote:
>
>
> Justin Deoliveira wrote:
>> Chris Holmes wrote:
>>> One question, on the spec itself, can we specify the behavior pe
Chris Holmes a écrit :
> But sometime I'd really like to see indexed shapefile and shapefile
> united. Indexed shapefile already has the hooks to just be an option
> for a shapefile, on creation you can just specify which one you want.
> Seems a bit silly to have them in separate classes, and I
+1
But sometime I'd really like to see indexed shapefile and shapefile
united. Indexed shapefile already has the hooks to just be an option
for a shapefile, on creation you can just specify which one you want.
Seems a bit silly to have them in separate classes, and I know the
original author
Justin Deoliveira wrote:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?
It is specified on the "Insert" statement itself.
I was talking about the capabilities reporting of it, if we have to
re
Chris Holmes wrote:
> One question, on the spec itself, can we specify the behavior per
> featureType? Or do we only have the option to set globally?
It is specified on the "Insert" statement itself.
>
> If we have diverse datastores, then what do we do? Aggregate and only
> report what all are
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?
If we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS
Hi,
some times ago I remember a discussion with Jody and Jesse about FID
generation
in datastore transactions (inserts) and the fact that we should wait
after the end of transaction
to check what FID has been assigned to new features.
This is troublesome both during interactive editing (uDig for
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-2.3.x?log=log20061023121336
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated techn
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.
I've tried to collect all my findings here:
http://
Martin Desruisseaux ha scritto:
> If nobody object, I would like to rename the following directories:
>
> plugin/oraclespatial --> plugin/oracle-spatial
> ext/shape --> ext/index-shapefile
> ext/shaperenderer --> ext/shapefile-renderer
>
> The purpose is to
Martin Desruisseaux ha scritto:
>> Has been opened quite some time ago and voted too, still unresolved,
>> so I would not hold my breath
>> waiting for it to be fixed.
> Btw, there's an open issue about this:
> http://jira.codehaus.org/browse/MECLIPSE-119
>
> The above-cited JIRA task provides a
If nobody object, I would like to rename the following directories:
plugin/oraclespatial --> plugin/oracle-spatial
ext/shape --> ext/index-shapefile
ext/shaperenderer --> ext/shapefile-renderer
The purpose is to have directory names matching exactly the n
Adrian Custer a écrit :
> Note that, despite my lack of knowledge, the reorg makes it now fairly
> trivial to see that all pom.xml have these blocks; it's therefore also
> easy to remove them.
Thanks. I will remove them then (except in parent pom of course); it should be
fast.
Martin
--
Andrea Aime a écrit :
>> Removing the "gt2-" prefix in artifact names allow them to match the
>> directories names, which allow us to remove all , and
>> declarations in pom.xml files except the root one. The
>> correct URLs are build by Maven, the default being directory name
Hi,
I am trying to download the geoserver-1.4.0-M2-WCS-src.zip
file from
http://prdownloads.sourceforge.net/geoserver/geoserver-1.4.0-M2-WCS-src.zip?use_mirror=superb-west
However, this is giving me a corrupt file or invalid zip
file error message upon download.
Cheers,
Ad
On Mon, 2006-10-23 at 00:38 -0400, Martin Desruisseaux wrote:
> Note: I noticed that every pom.xml files now contains the following:
>
>
> Geotools
> http://www.geotools.org
>
>1996
>
>
> I wonder why those informations are repeated in every pom.xml files? They
> should
>
> Simone Giannecchini a écrit :
>
>>> Error while parsing JAI registry file
>>> "/usr/local/src/geotools/branch-2.3.x/module/coverage/target/classes/META-INF/registryFile.jai"
>>>
>>>
>>> Error in registry file at line number #31
>>> A descriptor is already registered against the name
>>> "or
Andrea Aime ha scritto:
> Oh... this is going to be a trouble. Do you have an idea how common a
> "main" module is?
> The eclipse plugin generates projects whose name matches the artifactId,
> this means I won't be
> able to have geoserver and geotools loaded at the same time in Eclipse
> because
(resending since I'm not seeing the message on the ml after an hour...)
Martin Desruisseaux ha scritto:
> The work is not yet finished.
>
> Done:
>- Fixed all 'src' subdirectories. They now contains 'src/main/java',
> 'src/main/resources', 'src/test/java', 'src/test/resources', etc.
>
Martin Desruisseaux ha scritto:
> The work is not yet finished.
>
> Done:
>- Fixed all 'src' subdirectories. They now contains 'src/main/java',
> 'src/main/resources', 'src/test/java', 'src/test/resources', etc.
> according Maven conventions.
>
Cool
>- Renamed all in all pom.x
45 matches
Mail list logo
