Hi Rob; you did not install your JDK with international lanaguage
support; I keep fixing this error to not be fatal but it always seems to
get people.
You you fix the test case to just show a warning if the unsupported
charset exception occurs; and fail if it is anything else...
Can I ask what
after repeated svn, mvn -u clean, remove and re-checkout I get some
consistent failures building gt2.4
shapefile test fails with:
---
Test set: org.geotools.data.shapefile.ShapefileDataStoreTest
--
Hello,
Don't worry, I'm not offended that easily :)
The modules I'm talking about are the GeoTools module structure modules:
gt-xml-gpx under modules/unsupported/xml-gpx, providing packages:
org.geotools.gpx
org.geotools.gpx.bean
org.geotools.gpx.binding
and
gt-gpx under modules/unsupported/gpx
Sunburned Surveyor wrote:
> I was definitely interested in providing programmer friendly access at
> a lower level. This allows different FOSS programs to do with the GPX
> entities what they desire. I couldn't do this if I only provided a
> GeoTools SimpleFeature implementation from GPX files.
>
>
Jody wrote: "Landon did I understand your aims correctly?"
Yes.
I did'nt realize that a gt-xml-gpx package existed, or I would have
taken a closer look at it. I thought there was only the following
three (3) packages:
org.geotools.gpx
org.geotools.gpx.bean
org.geotools.gpx.binding
I was looking
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Jody Garnett ha scritto:
>> ...
>>> Two ideas:
>>> - you can capture the font handling code by providing a custom
>>> labeler (like we do from uDig) and then just doing normal unit tests
>>> on the labeler to make sure it has collected the expected
That is an approach we take often Peter; for example the gt-wps module
is going to offer a "no abstraction" access to a web processing service.
Then a high level gt-process module can offer the easier api for Java
programmers.
Landon is trying to do something slightly different (ie he has diffe
Andrea Aime wrote:
> Jody Garnett ha scritto:
> ...
>> Two ideas:
>> - you can capture the font handling code by providing a custom
>> labeler (like we do from uDig) and then just doing normal unit tests
>> on the labeler to make sure it has collected the expected information
> Yeah, that could w
Adrian Custer a écrit :
>>> Wondering if putting jaxb dependencies at the top of the pom.xml files
>>> in the xsd modules is going to buy us the desired order...
>> Adrian tried and it worked for him.
>
> Not exactly,
I was confused, sorry.
I was thinking "putting jaxb dependencies at the top of
On Fri, 2008-05-23 at 19:00 +0200, Martin Desruisseaux wrote:
> Andrea Aime a écrit :
> > Wondering if putting jaxb dependencies at the top of the pom.xml files
> > in the xsd modules is going to buy us the desired order...
>
> Adrian tried and it worked for him.
Not exactly,
the patch attached
Andrea Aime a écrit :
> Wondering if putting jaxb dependencies at the top of the pom.xml files
> in the xsd modules is going to buy us the desired order...
Adrian tried and it worked for him.
In a little bit longuer term, I wonder if we should consider make the GeoTools
project to evoluate towar
Martin Desruisseaux ha scritto:
> Justin Deoliveira a écrit :
>> I do, one is in teh dummy module, one in the actual.
>
> I'm not familiar with Eclipse IDE, but is there anyway with Eclipse to make
> sure
> that the actual JAXB appears first in the classpath?
Manual modifications of the classpa
Hello,
I think that you give a much greater importance to the low level access
of the file, than you should. I'm not a GeoTools expert, but my
understanding is that the point in the whole thing is to generalize the
way the data could be accessed. This is why I didn't care about names of
proper
Gabriel Roldán wrote:
>> 5- Test ArcSDEConnectionReference for the single connection configuration.
>> Jody I would try caching the connection once and just overriding
>> getSession() to return it over and over.
>>
>>
> Jody, just tried this and everything worked but a single test:
> testEdi
Hi Gabriel; just getting back to you so you know I am alive.
Changing over the the queue has made a *vast* difference in how well the
datastore performs in uDig; everything is much better to work with and
my customer is happy. I know we have some more issue to work through;
but I wanted you to
Hi,
In my implementation I didn't yet care about the ExtensionType, as it's
not a crucial part of the structure. In my plans it could be any type,
the important thing is that it shall be accessible somehow, and shall be
saved back to the file, when it is saved.
Peter
Sunburned Surveyor wrote:
> Hey Justin,
>
> Not sure what xsd is, I tried with WFSParsingTest and got your error.
Its what i call the grouping of xml modules, everything under extension/xsd.
Thanks for looking into it. But manually updating the classpath is not
really an acceptable fix in my mind.
I may just try to remo
On Fri, 2008-05-23 at 08:09 -0700, Justin Deoliveira wrote:
> 1. Run mvn eclipse:eclipse
> 2. Import modules into eclipse
> 3. Run xsd tests from eclipse
Hey Justin,
Not sure what xsd is, I tried with WFSParsingTest and got your error.
Then, I "fixed" it, I think, with
Run > Open run Dialog...
The GeoTools 2.4.4 release is available for download at:
http://docs.codehaus.org/display/GEOTOOLS/2.4.4
This is a bug fix release, with just a single critical bug
fix for a bug that was introduced along with 2.4.3.
If you're depending on point rendering and are using 2.4.3,
you're warmly encourag
> 5- Test ArcSDEConnectionReference for the single connection configuration.
> Jody I would try caching the connection once and just overriding
> getSession() to return it over and over.
>
Jody, just tried this and everything worked but a single test:
testEditVersionedTableTransaction
Just chec
Hi Graham,
I ran the test and got an issue, but it was something different than
what JOdy was talking about. Anyways, I made a small change and the test
now passes for me.
Try it out and let me know if you still get an error. Perhaps could you
in include the stack trace of it?
Graham Davis wr
Justin Deoliveira a écrit :
> I do, one is in teh dummy module, one in the actual.
I'm not familiar with Eclipse IDE, but is there anyway with Eclipse to make
sure
that the actual JAXB appears first in the classpath?
Martin
--
Jody Garnett wrote:
> Wait I think I have it; did we end up making a "dummy" jar for JaxB (so
> the code could compile when jaxb was not available?) Perhaps we are
> getting class cast exception between this dummy jar (needed by
> gt-metdata to compile) and the real thing (used by the parser).
Wait I think I have it; did we end up making a "dummy" jar for JaxB (so
the code could compile when jaxb was not available?) Perhaps we are
getting class cast exception between this dummy jar (needed by
gt-metdata to compile) and the real thing (used by the parser).
Justin can you do a search f
1. Run mvn eclipse:eclipse
2. Import modules into eclipse
3. Run xsd tests from eclipse
Jody Garnett wrote:
> So how is it not working with your IDE again? The only thing I can
> figure is if you did a maven eclipse:eclipse using Java 6 on the command
> line and then were working with another
Hey Justin, all,
Sorry this is getting under everyone's skin.
Justin, for Cedric and Martin to help you, they'd have to have a much
better idea what is going on. The little info we have so far doesn't
give us enough to diagnose the issue.
The only thing they can come up with is that your real
So how is it not working with your IDE again? The only thing I can
figure is if you did a maven eclipse:eclipse using Java 6 on the command
line and then were working with another project that also used Jaxb ...
ah I see - the xml parser.
So are we out of sync with respect to versions? Sorry ju
Hi,
here's the deal with arcsde after a week of hacking:
Saul, if you don't want to go through the whole content check item 4- at the
end.
- command queue strategy for connection handling successfully implemented for
vector data. I even set the connection's concurrency policy to
SE_ONE_THREAD
Ah ha...
That explains some trouble uDig developers were having; it was almost
like they had different versions of 2.5-M3
Your plan sounds fine Andrea,
Jody
Andrea Aime wrote:
> Hi,
> so, due to this bug: http://jira.codehaus.org/browse/GEOT-1829
> we'll have to remake 2.4.3 release.
>
> Unf
Hey Justin' it appears I was not clear: The Jaxb dependency for metdata
is marked provided.
If you want to use JaxB serialization for reading/writing metadata:
- you are using Java 6 (and it is included in the JRE) and provided that way
- or you are using Java 5 and you can included it in your p
Hey Justin' it appears I was not clear: The Jaxb dependency for metdata
is marked provided.
If you want to use JaxB serialization for reading/writing metadata:
- you are using Java 6 (and it is included in the JRE) and provided that way
- or you are using Java 5 and you can included it in your p
Justin Deoliveira a écrit :
>> I said "users who don't care have nothing to do".
>>
>>
>
> Ahh... ok. So i guess its ok that I cant work in my ide any more. But
> hey, at least the users who don't care having nothing to do.
>
>
No, no, of course not, it is not okay for me. And that's why i
Martin Desruisseaux ha scritto:
> Justin Deoliveira a écrit :
>> Good, can we stop using java 6 as a justification then?
>
> Not from me. This is a very strong justification in my mind.
>
>
>> Oh well... just yet another hurdle i guess for people to develop with
>> geotools... as if it was not
> I said "users who don't care have nothing to do".
>
Ahh... ok. So i guess its ok that I cant work in my ide any more. But
hey, at least the users who don't care having nothing to do.
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
--
Justin Deoliveira a écrit :
> Good, can we stop using java 6 as a justification then?
Not from me. This is a very strong justification in my mind.
> Oh well... just yet another hurdle i guess for people to develop with
> geotools... as if it was not hard enough already.
I said "users who don't
Justin Deoliveira a écrit :
> So GeoTools requires Java 6? I thought we were still on Java 5?
>
>
It is not what I said. In my previous mail, I just explain that if you
want to use JAXB, you have to build the metadata module with a JDK6.
Otherwise you won't get annotated classes in the jar gen
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>> So GeoTools requires Java 6? I thought we were still on Java 5?
>
> No. Geotools requires Java 5 only.
Good, can we stop using java 6 as a justification then?
>
> We have not added JAXB as a core dependency. GeoTools do not depends on J
Justin Deoliveira a écrit :
> So GeoTools requires Java 6? I thought we were still on Java 5?
No. Geotools requires Java 5 only.
If you want metadata to work with JAXB, you needs either Java 6 or put JAXB in
the "endorsed" directory, at your choice. But this is *optional*.
> I would like to re
So GeoTools requires Java 6? I thought we were still on Java 5?
Upgrading is going to be a bit of work for me... but appears i have no
choice. I would like to remind folks that when teh proposal to add jaxb
as a core dependency was brought up i was against it, but was *assured*
that "nothing wo
Move spherical parameters out of LambertAzimuthalEqualArea.Provider
---
Key: GEOT-1832
URL: http://jira.codehaus.org/browse/GEOT-1832
Project: GeoTools
Issue Type: Task
Hi,
so, due to this bug: http://jira.codehaus.org/browse/GEOT-1829
we'll have to remake 2.4.3 release.
Unfortunately, since it has already been deployed to maven
repos, I cannot be sure of who has already grabbed it, so
the safe way is to just take the 2.4.3 tag, copy it
as 2.4.4, apply the patch
ArcSDE uses different transaction isolation levels depending on the backend
database
Key: GEOT-1831
URL: http://jira.codehaus.org/browse/GEOT-1831
Project: GeoTools
Jody Garnett a écrit :
> Justin you should have a different set of dependencies for Java 6; since
> jaxb is starting to get folded into Java 6 you will get security / class
> cast exception when trying to mix and match the same "class" between two
> different classloaders... the JRE gets annoyed
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Well, since I have a customer that needs this, and there seems to be
>> no agreement (or lack of interest) on what to do, I'll roll a custom
>> variant of the quantile algorithm inside GeoServer that does what I
>> suggested, set apart the flat ar
Jody Garnett ha scritto:
...
> Two ideas:
> - you can capture the font handling code by providing a custom labeler
> (like we do from uDig) and then just doing normal unit tests on the
> labeler to make sure it has collected the expected information
Yeah, that could work, thought only for labels
45 matches
Mail list logo
