[Geotools-devel] [jira] Created: (GEOT-3654) Switching to Java 6 for Version 8.0

Switching to Java 6 for Version 8.0 --- Key: GEOT-3654 URL: http://jira.codehaus.org/browse/GEOT-3654 Project: GeoTools Issue Type: Improvement Affects Versions: 8.0-M1 Reporter: Christian Muel

[Geotools-devel] Hudson build is back to normal : geotools-trunk #3708

See -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensu

[Geotools-devel] Build failed in Hudson: geotools-trunk #3707

See Changes: [jdeolive] updated wfs model to allow for content inside of NativeType (as recently chagned in the official wfs schema) -- [...truncated 4846 lines...] at org.geotools

Re: [Geotools-devel] Request for Commit access to support German translations

Hey Frank, I think this might be the wrong list... are you requesting access for geoserver or geotools? or both? That said +1, I have been impressed with the quality of patches from Frank in the past. If you are requesting commit access for geoserver then you need to apply to join the project on

Re: [Geotools-devel] Request for Commit access to support German translations

I can vouch for Frank as I have worked with him on uDig. Jesse On Wed, Jun 15, 2011 at 10:21 PM, Frank Gasdorf wrote: > Hallo List, > > I'd like to contribute German translations for the core geoserver modules > and created patch files in the past. Christian Mueller committed > the attached pat

[Geotools-devel] Request for Commit access to support German translations

Hallo List, I'd like to contribute German translations for the core geoserver modules and created patch files in the past. Christian Mueller committed the attached patches for GEOS-4294 (except the last one from today). I already created an OSGeo ID (fgdrf) and a Codehaus account (fgdrf1976). I

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

Please read below Zitat von Andrea Aime : > On Wed, Jun 15, 2011 at 8:26 PM, wrote: > >> Like geotools, I get encoding problems for gesoerver too >> >> src/restconfig/src/main/java/org/geoserver/rest/FontListResource.java >> >> The author in the comment is not UTF-8. >> >> recode iso-8859-1..utf

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

On Wed, Jun 15, 2011 at 8:26 PM, wrote: > Like geotools, I get encoding problems for gesoerver too > > src/restconfig/src/main/java/org/geoserver/rest/FontListResource.java > > The author in the comment is not UTF-8. > > recode iso-8859-1..utf-8 > src/main/java/org/geoserver/rest/FontListResource

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

Like geotools, I get encoding problems for gesoerver too src/restconfig/src/main/java/org/geoserver/rest/FontListResource.java The author in the comment is not UTF-8. recode iso-8859-1..utf-8 src/main/java/org/geoserver/rest/FontListResource.java keeps the strange character, but compiling is n

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

On Wed, Jun 15, 2011 at 7:54 PM, wrote: > Then you are more lucky than me. I did the same using SUN JDK > > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) > > and get problems with the file encodings:

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

On Wed, Jun 15, 2011 at 8:03 PM, Andrea Aime wrote: > > I've tried with GeoServer and get a lot of failures on trunk with a stack > trace looking like: > > java.lang.AbstractMethodError: > org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z > at > com.sun.org.apache.xalan.internal.xsltc.trax.

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

On Wed, Jun 15, 2011 at 7:18 PM, Ian Turton wrote: > > > On 15 June 2011 11:55, Justin Deoliveira wrote: > >> I can volunteer to update the build server... i just have to add a java 6 >> jdk and then update the trunk builds for geotools and geoserver to use that >> jdk. Should not be much work.

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

Then you are more lucky than me. I did the same using SUN JDK java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) and get problems with the file encodings: Example in /home/christian/gt-trunk/modules/libra

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

On 15 June 2011 11:55, Justin Deoliveira wrote: > I can volunteer to update the build server... i just have to add a java 6 > jdk and then update the trunk builds for geotools and geoserver to use that > jdk. Should not be much work. Once someone has done a successful java 6 > build locally and m

[Geotools-devel] Build failed in Hudson: geotools-trunk #3706

See Changes: [jive] Envelope2D implements BoundingBox, GEOT-3570 (test case pending) -- [...truncated 4836 lines...] at org.geotools.referencing.operation.projection.MapProjection.

Re: [Geotools-devel] About Java 6 on trunk

Good point about the hudson builds; is there anything else we are missing? Updated Proposal page: http://docs.codehaus.org/display/GEOTOOLS/Java+6 -- Jody Garnett On Thursday, 16 June 2011 at 1:45 AM, Jody Garnett wrote: > I second Andrea. > > I set up a proposal so we could see what was nee

Re: [Geotools-devel] [Geoserver-devel] About Java 6 on trunk

I can volunteer to update the build server... i just have to add a java 6 jdk and then update the trunk builds for geotools and geoserver to use that jdk. Should not be much work. Once someone has done a successful java 6 build locally and made any pom updates, etc... just let me know and I will up

Re: [Geotools-devel] About Java 6 on trunk

I second Andrea. I set up a proposal so we could see what was needed for the GeoTools side. Once there are a few more names next to the "tasks" section we should be able to go ahead. For reference here is the list of tasks: aa: check build in Java 6 an apply eventual patches Update pom to indic

Re: [Geotools-devel] About Java 6 on trunk

On Wed, Jun 15, 2011 at 5:07 PM, wrote: > Short question because I am unsure. > > Can I use Java 6 for development on geoserver trunk ? > Now I work with Java 5 and in the meantime I hate the class > IOExpression NOT having a constructor where I can pass an Exception as > an argument. > > What ab

[Geotools-devel] About Java 6 on trunk

Short question because I am unsure. Can I use Java 6 for development on geoserver trunk ? Now I work with Java 5 and in the meantime I hate the class IOExpression NOT having a constructor where I can pass an Exception as an argument. What about geotools ? I have so many places where I use I

[Geotools-devel] [jira] Created: (GEOT-3653) CRS transform methods assume GeneralEnvelope

CRS transform methods assume GeneralEnvelope Key: GEOT-3653 URL: http://jira.codehaus.org/browse/GEOT-3653 Project: GeoTools Issue Type: Sub-task Reporter: Jody Garnett -- This mes

Re: [Geotools-devel] [ExternalEmail] Re: joins

In app-schema JoiningJDBCFeatureSource, Niels added support for efficient SQL generation to speed up queries on app-schema feature-chained types by orders of magnitude. This is an optional app-schema feature. Docs coming soon (in internal review). Until then: https://www.seegrid.csiro.au/wiki/In

Re: [Geotools-devel] joins

Correct. app-schema encodes relationships in responses, but does not support queries on arbitrary relationships between potentially unrelated feature types. Relationships have to be configured beforehand. On 14/06/11 03:16, Justin Deoliveira wrote: > * app-schema vs simple features > With knowin

Re: [Geotools-devel] joins

On Wed, Jun 15, 2011 at 9:18 AM, Niels wrote: > Does this mean the geotools DAL will support joins in the future? > DAL: data access layer? Yeah, I believe this is the whole point of the discussion, Justin is working on adding just that. Cheers Andrea --

Re: [Geotools-devel] joins

Does this mean the geotools DAL will support joins in the future? The past few months I have been doing some serious class hacking of jdbc classes in app-schema to provide some support for faster data retrieval with feature chaining through joining. It would of course be even better if geotools