Sorry for the late response,
On Wednesday 07 May 2008 12:13:30 am Jody Garnett wrote:
> Jody Garnett wrote:
> > Yes I am finally working on ArcSDE again ... I have been asked to stop
> > converting ArcSDEDataStore over to using a queue and instead look at a
> > series of problems:
> > - A connecti
Hi Jody,
paging tests in trunk are in place, so feel free to go ahead with the
milestone at your convenience, and thanks for waiting.
Gabriel
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss t
Hi,
I've been looking a little more in our converters usage and
I believe I'm finding quite a few issues.
The first one is due to the following converters behaviour.
The following snippet:
System.out.println(Converters.convert("1002.5", Integer.class));
System.out.println(Converters.convert("1002.
Andrea Aime ha scritto:
> Hi,
> I've been looking a little more in our converters usage and
> I believe I'm finding quite a few issues.
>
> The first one is due to the following converters behaviour.
> The following snippet:
> System.out.println(Converters.convert("1002.5", Integer.class));
> Syst
Andrea Aime ha scritto:
> Andrea Aime ha scritto:
>> Hi,
>> I've been looking a little more in our converters usage and
>> I believe I'm finding quite a few issues.
>>
>> The first one is due to the following converters behaviour.
>> The following snippet:
>> System.out.println(Converters.convert("
Andrea Aime ha scritto:
> Andrea Aime ha scritto:
>> Andrea Aime ha scritto:
>>> Hi,
>>> I've been looking a little more in our converters usage and
>>> I believe I'm finding quite a few issues.
>>>
>>> The first one is due to the following converters behaviour.
>>> The following snippet:
>>> Syste
CommonsConverter turns "12.5" into 0, it shuld return null instead
--
Key: GEOT-1808
URL: http://jira.codehaus.org/browse/GEOT-1808
Project: GeoTools
Issue Type: Bug
C
[
http://jira.codehaus.org/browse/GEOT-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Aime reopened GEOT-1678:
---
The fix for this issue only accidentaly made it faster and introduced other
bugs, the patch should be reworked
Thanks Gabriel you rock!
Jody
Gabriel Roldán wrote:
> Hi Jody,
>
> paging tests in trunk are in place, so feel free to go ahead with the
> milestone at your convenience, and thanks for waiting.
>
> Gabriel
>
-
This SF.net
Gabriel Roldán wrote:
>> Fixed GEOT-1735 and am now down to 17 failures.
>>
> 17 without FilterTest into acount? remember FitlerTest is out of the build
> waiting to be "ported" from the legacy tables they were developed against to
> our test generated ones
>
I am running these tests from
Andrea Aime wrote:
> Hi,
>
> I've been looking a little more in our converters usage and I believe I'm
> finding quite a few issues.
>
> The first one is due to the following converters behaviour.
> The following snippet:
> System.out.println(Converters.convert("1002.5", Integer.class));
> System.
Justin Deoliveira ha scritto:
> Hi all,
>
> I have a few issues with this patch which is supposed to address
> performance with filters.
>
> 1) It causes floating point strings to be truncated to an integer. The
> following simple test case illustrates:
>
> Literal l = ff.literal("0.1");
> Obj
Hi Andrea,
Your hitting on some definite issues with the api... and ones i am
ashamed to say i have hacked around in the past :(. So here is what I
think is needed:
1. A way to do only *safe* vs *lax* conversions
2. A way to prioritize or sort factories
So i would recommend the following:
1.
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Hi,
>>
>> I've been looking a little more in our converters usage and I believe
>> I'm finding quite a few issues.
>>
>> The first one is due to the following converters behaviour.
>> The following snippet:
>> System.out.println(Converters.convert("
Justin Deoliveira ha scritto:
> Hi Andrea,
>
> Your hitting on some definite issues with the api... and ones i am
> ashamed to say i have hacked around in the past :(. So here is what I
> think is needed:
>
> 1. A way to do only *safe* vs *lax* conversions
Where safe conversion means "12.5" ca
Hi Theodor,
I think you are getting bit by the recent change in geotools artifact
names, change your dependency on kml to:
org.geotools.xsd
gt-kml
That should pick up the new changes.
-Justin
Theodor Foerster wrote:
> Hi Justin,
> Thanks for putting so much effort into this. I tried to run my
> Where safe conversion means "12.5" cannot be converted to a integer in
> any way, right? Possibly even "12.0", since new Integer("12.0") bombs
> out in java (and making a converter that handles the conversion in
> all cases, even with very numbers that go beyond the range of basic
> types, is a
Way back in the dawn of Expression 2.0 - we messed around with the
concept of providing a bit more information as part of the context.
ie Integer+strict vs Integer+lax
At the time we did not figure we knew enough about what went into
context to strictly define what is needed; and rather than go
Hi Justin,
Thanks for your hint. Somewhat the gt repository structure seems to
change. Anyway, I just tried to encode a FeatureCollection as KML.
Unfortunately I do get an error (java.lang.ClassCastException) in
org.geotools.kml.binding.FeatureTypeBinding:185. The object passed in
getProperty() is
I run into a bit of a problem getting started when tagging 2.5-M2, the
usually strategy of "mvn install" does not work as we lack the correct
version of verifier - until we build it.
> [INFO]
>
> [ERROR] BUILD ERROR
> [IN
Jody Garnett wrote:
> I run into a bit of a problem getting started when tagging 2.5-M2, the
> usually strategy of "mvn install" does not work as we lack the correct
> version of verifier - until we build it.
>
On the good news front; the dummy jars are no longer in the bin
artifacts :-) We
21 matches
Mail list logo
