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

[Christian Mueller (JIRA)]

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 Mueller
 Attachments: encoding.patch, pom.patch

Collection some patches for a JAVA 6 build. The encoding patch is needed for a 
build with Oracle JDK. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Hudson]

See 



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Hudson]

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.geometry.jts.LiteShape2.(LiteShape2.java:152)
at 
org.geotools.renderer.lite.StreamingRenderer$RenderableFeature.getTransformedShape(StreamingRenderer.java:3013)
at 
org.geotools.renderer.lite.StreamingRenderer$RenderableFeature.getShape(StreamingRenderer.java:2948)
at 
org.geotools.renderer.lite.StreamingRenderer.processSymbolizers(StreamingRenderer.java:2481)
at 
org.geotools.renderer.lite.StreamingRenderer.process(StreamingRenderer.java:2393)
at 
org.geotools.renderer.lite.StreamingRenderer.drawPlain(StreamingRenderer.java:2249)
at 
org.geotools.renderer.lite.StreamingRenderer.processStylers(StreamingRenderer.java:1943)
at 
org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:776)
at 
org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:584)
at 
org.geotools.renderer.lite.ReprojectionTest.testSkipProjectionErrors(ReprojectionTest.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.geotools.renderer.lite.FillTest
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 9:11:30 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.202 sec
Running org.geotools.renderer.style.SLDStyleFactoryTest
Jun 15, 2011 9:11:30 PM org.geotools.feature.simple.SimpleFeatureTypeBuilder add
WARNING: Creating geom with null CoordinateReferenceSystem - did you mean to 
setCRS?
Jun 15, 2011 9:11:30 PM org.geotools.feature.simple.SimpleFeatureTypeBuilder add
WARNING: Creating geom with null CoordinateReferenceSystem - did you mean to 
setCRS?
Jun 15, 2011 9:11:30 PM org.geotools.feature.simple.SimpleFeatureTypeBuilder add
WARNING: Creating geom with null CoordinateReferenceSystem - did you mean to 
setCRS?
Jun 15, 2011 9:11:30 PM org.geotools.feature.simple.SimpleFeatureTypeBuild

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

[Justin Deoliveira]

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 codehaus.

  http://docs.geoserver.org/stable/en/developer/policies/comitting.html

-Justin

On Wed, Jun 15, 2011 at 2:24 PM, Jesse Eichar
wrote:

> 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 <
> fg...@users.sourceforge.net> 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 patches for GEOS-4294 (except the last one from today).
>>
>> I already created an OSGeo ID (fgdrf) and a Codehaus account  (fgdrf1976).
>>
>> In the past I provided some small patches : GEOS-4231, GEOS-4216 and the
>> one mentioned above.
>>
>> Could you as the PMCs give me access to the SVN repository that I'm able
>> to change these property files?
>>
>> Whats next?
>>
>> Thanks a lot,
>> Frank Gasdorf
>>
>>
>> --
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> ___
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Jesse Eichar]

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 patches for GEOS-4294 (except the last one from today).
>
> I already created an OSGeo ID (fgdrf) and a Codehaus account  (fgdrf1976).
>
> In the past I provided some small patches : GEOS-4231, GEOS-4216 and the
> one mentioned above.
>
> Could you as the PMCs give me access to the SVN repository that I'm able to
> change these property files?
>
> Whats next?
>
> Thanks a lot,
> Frank Gasdorf
>
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Frank Gasdorf]

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).

In the past I provided some small patches : GEOS-4231, GEOS-4216 and the one
mentioned above.

Could you as the PMCs give me access to the SVN repository that I'm able to
change these property files?

Whats next?

Thanks a lot,
Frank Gasdorf
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[christian . mueller]

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-8
>> src/main/java/org/geoserver/rest/FontListResource.java
>> keeps the strange character, but compiling is now working
>>
>> Looks like I am the only one getting such errors. I am on Ubuntu 11.04, 64
>> Bit, encoding UTF-8
>>
>
> Wait, I take it back.
> I see the same issue as you in the FontListResource.java, that only needs a
> quick fix
> in the name of the author (and then the same in the test file, no need to
> recode the
> entire file).
>
> The previous geotools build I thought I was using java 6, but instead I was
> still on 5.
> The first encoding failure I see in GeoTools is this one though:
>
> INFO] Compilation failure
> /home/aaime/devel/git-gt/modules/extension/xsd/xsd-core/src/main/java/org/geotools/xml/EMFUtils.java:[398,18]
> unmappable character for encoding UTF-8
>
> That said, those issue normally evaporate by replacing the single char with
> issues
> and moving on.
> It's late and I have to go now but I believe the other files can be cured
> the same way?
>
> Cheers
> Andrea

Yep, I have exactly the same behavior. Lets continue tomorrow.

>
>
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>




This message was sent using IMP, the Internet Messaging Program.



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[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-8
> src/main/java/org/geoserver/rest/FontListResource.java
> keeps the strange character, but compiling is now working
>
> Looks like I am the only one getting such errors. I am on Ubuntu 11.04, 64
> Bit, encoding UTF-8
>

Wait, I take it back.
I see the same issue as you in the FontListResource.java, that only needs a
quick fix
in the name of the author (and then the same in the test file, no need to
recode the
entire file).

The previous geotools build I thought I was using java 6, but instead I was
still on 5.
The first encoding failure I see in GeoTools is this one though:

INFO] Compilation failure
/home/aaime/devel/git-gt/modules/extension/xsd/xsd-core/src/main/java/org/geotools/xml/EMFUtils.java:[398,18]
unmappable character for encoding UTF-8

That said, those issue normally evaporate by replacing the single char with
issues
and moving on.
It's late and I have to go now but I believe the other files can be cured
the same way?

Cheers
Andrea



-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[christian . mueller]

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 now working

Looks like I am the only one getting such errors. I am on Ubuntu  
11.04, 64 Bit, encoding UTF-8

Cheers
Christian


Zitat von Andrea Aime :

> 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.DOM2TO.setDocumentInfo(DOM2TO.java:373)
>> at
>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:127)
>>  at
>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:94)
>> at
>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:661)
>>  at
>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:707)
>> at
>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
>>  at org.geoserver.data.CatalogWriter.write(CatalogWriter.java:253)
>> at org.geoserver.data.test.MockData.setUpCatalog(MockData.java:650)
>>  at org.geoserver.data.test.MockData.setUp(MockData.java:348)
>> at
>> org.geoserver.test.GeoServerAbstractTestSupport.oneTimeSetUp(GeoServerAbstractTestSupport.java:174)
>>  at org.geoserver.test.OneTimeSetupTest.setUp(OneTimeSetupTest.java:89)
>>
>> Java version is:
>>
>> java -version
>> java version "1.6.0_24"
>> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
>>
>
> Ah, found that removing the xerces dependency solves the problem in this
> module.
> But I guess Xerces dependencies are coming from multiple sides, so getting
> rid of it might
> not be trivial
>
> Cheers
> Andrea
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>




This message was sent using IMP, the Internet Messaging Program.



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Andrea Aime]

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:
>
> Example in
>
> /home/christian/gt-trunk/modules/library/coverage/src/main/java/org/geotools/coverage/grid/
>
>
> GridCoverageFactory.java:  ASCII C program text
> GridEnvelope2D.java:   UTF-8 Unicode C program text
> GridGeometry2D.java:   ISO-8859 C program text
>
> Compilation failed for some ISO-8859 encoded files.
>
> A quick check on the java files shows
>
> 6013 files using ASCII chars
> 221  files using UTF-8
> 48   files using ISO-8859
>
> Should I try to recode this files ?
>

Maybe not? Let's try to figure out what is going on first.
I've just made a full build of GeoTools with java 6 and found
no issues either, it just worked.

So it seems the issue is specific to your system.
Are you on Suse linux? This message seems to be interesting:
http://www.velocityreviews.com/forums/t127154-wrong-default-encoding-on-linux.html
(see the last comment in the thread)

Cheers
Andrea


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Andrea Aime]

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.DOM2TO.setDocumentInfo(DOM2TO.java:373)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:127)
>  at
> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:94)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:661)
>  at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:707)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
>  at org.geoserver.data.CatalogWriter.write(CatalogWriter.java:253)
> at org.geoserver.data.test.MockData.setUpCatalog(MockData.java:650)
>  at org.geoserver.data.test.MockData.setUp(MockData.java:348)
> at
> org.geoserver.test.GeoServerAbstractTestSupport.oneTimeSetUp(GeoServerAbstractTestSupport.java:174)
>  at org.geoserver.test.OneTimeSetupTest.setUp(OneTimeSetupTest.java:89)
>
> Java version is:
>
> java -version
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
>

Ah, found that removing the xerces dependency solves the problem in this
module.
But I guess Xerces dependencies are coming from multiple sides, so getting
rid of it might
not be trivial

Cheers
Andrea

-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Andrea Aime]

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. Once someone has done a successful java 6
>> build locally and made any pom updates, etc... just let me know and I will
>> update hudson.
>>
>
> I've just built trunk using Java 6
>
> java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>
> Assuming there were no changes I needed to make other than in the top level
> pom to force it to use 1.6 all the way through,
>

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.DOM2TO.setDocumentInfo(DOM2TO.java:373)
at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:127)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:94)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:661)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:707)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
at org.geoserver.data.CatalogWriter.write(CatalogWriter.java:253)
at org.geoserver.data.test.MockData.setUpCatalog(MockData.java:650)
at org.geoserver.data.test.MockData.setUp(MockData.java:348)
at
org.geoserver.test.GeoServerAbstractTestSupport.oneTimeSetUp(GeoServerAbstractTestSupport.java:174)
at org.geoserver.test.OneTimeSetupTest.setUp(OneTimeSetupTest.java:89)

Java version is:

java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)

Cheers
Andrea

-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[christian . mueller]

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/library/coverage/src/main/java/org/geotools/coverage/grid/


GridCoverageFactory.java:  ASCII C program text
GridEnvelope2D.java:   UTF-8 Unicode C program text
GridGeometry2D.java:   ISO-8859 C program text

Compilation failed for some ISO-8859 encoded files.

A quick check on the java files shows

6013 files using ASCII chars
221  files using UTF-8
48   files using ISO-8859

Should I try to recode this files ?





Zitat von Ian Turton :

> 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 made any pom updates, etc... just let me know and I will
>> update hudson.
>>
>
> I've just built trunk using Java 6
>
> java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>
> Assuming there were no changes I needed to make other than in the top level
> pom to force it to use 1.6 all the way through,
>
> Ian
>
> --
> Ian Turton
>




This message was sent using IMP, the Internet Messaging Program.



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Ian Turton]

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 made any pom updates, etc... just let me know and I will
> update hudson.
>

I've just built trunk using Java 6

java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

Assuming there were no changes I needed to make other than in the top level
pom to force it to use 1.6 all the way through,

Ian

-- 
Ian Turton
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Hudson]

See 

Changes:

[jive] Envelope2D implements BoundingBox, GEOT-3570 (test case pending)

--
[...truncated 4836 lines...]
at 
org.geotools.referencing.operation.projection.MapProjection.transform(MapProjection.java:905)
at 
org.geotools.referencing.operation.transform.ConcatenatedTransformDirect.transform(ConcatenatedTransformDirect.java:80)
at 
org.geotools.geometry.jts.Decimator.decimateTransformGeneralize(Decimator.java:391)
at 
org.geotools.geometry.jts.Decimator.decimateTransformGeneralize(Decimator.java:229)
at org.geotools.geometry.jts.LiteShape2.(LiteShape2.java:152)
at 
org.geotools.renderer.lite.StreamingRenderer$RenderableFeature.getTransformedShape(StreamingRenderer.java:3013)
at 
org.geotools.renderer.lite.StreamingRenderer$RenderableFeature.getShape(StreamingRenderer.java:2948)
at 
org.geotools.renderer.lite.StreamingRenderer.processSymbolizers(StreamingRenderer.java:2481)
at 
org.geotools.renderer.lite.StreamingRenderer.process(StreamingRenderer.java:2393)
at 
org.geotools.renderer.lite.StreamingRenderer.drawPlain(StreamingRenderer.java:2249)
at 
org.geotools.renderer.lite.StreamingRenderer.processStylers(StreamingRenderer.java:1943)
at 
org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:776)
at 
org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:584)
at 
org.geotools.renderer.lite.ReprojectionTest.testSkipProjectionErrors(ReprojectionTest.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.geotools.renderer.lite.FillTest
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Jun 15, 2011 4:12:20 PM org.geotools.map.MapContent finalize
SEVERE: Call MapContent dispose() to prevent memory leaks
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.2 sec
Running org.geotools.renderer.style.SLDStyleFactoryTest
Jun 15, 2011 4:12:20 PM org.geotools.feature.simple.SimpleFeatureTypeBuilder add
WARNING: Creating geom with null CoordinateReferenceSystem - did you mean to 
setCRS?
Jun 15, 2011 4:12:20 PM org.geotools.feature.simple.SimpleFeatureTypeBuilder add
WARNING: Creating geom with null CoordinateReferenceSystem - did yo

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

[Jody Garnett]

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 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 indicate 1.6 as a compiler setting
> 
> 
> Update developers guide build instructions
> http://docs.geotools.org/latest/developer/guide/building/java.html
> http://docs.geotools.org/latest/developer/guide/building/install/install.html
> http://docs.geotools.org/latest/developer/guide/building/install/jdk.html
> jg: check the instructions (setting up a fresh machine)
> 
> 
> Update user guide
> Quickstart tutorial already advises use of latest JDK
> 
> 
> 
> 
> Christian this kind of "build and docs" work is often part of what is meant 
> by the PMC "doing the dirty work required to keep the project going" :-) Do 
> you have time to do any of the above?
> 
> For reference here is the list of tasks:
> 
> 
> -- 
> Jody Garnett
> 
> 
> On Thursday, 16 June 2011 at 1:21 AM, Andrea Aime wrote:
> 
> > On Wed, Jun 15, 2011 at 5:07 PM,  > (mailto:christian.muel...@nvoe.at)> 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 about geotools ? I have so many places where I use
> > >  IOExpression(String msg). Very often, the message is not enough to
> > >  solve problems efficiently.
> > > 
> > >  I saw the polls, but I think I must wait for the hudson build server
> > >  working with java 6.
> > 
> > The thing got stopped on lack of people volounteering to do the work.
> > As said in the old thread, I'm up to check stuff builds on Sun Java 6 
> >  in both projects, and provide eventual patches.
> > But we need people for doc changes, updating Hudson and so on
> > 
> > My hope is that once someone provide the patches to make things
> > work on java 6 (even if it's just pom changes) the rest will fall into
> > line "naturally"
> > 
> > Cheers
> > Andrea
> > 
> > 
> > 
> > -- 
> > ---
> > Ing. Andrea Aime
> > GeoSolutions S.A.S.
> > Tech lead
> > 
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> > 
> > phone: +39 0584 962313
> > fax: +39 0584 962313
> > 
> > http://www.geo-solutions.it
> > http://geo-solutions.blogspot.com/
> > http://www.youtube.com/user/GeoSolutionsIT
> > http://www.linkedin.com/in/andreaaime
> > http://twitter.com/geowolf
> > 
> > ---
> > --
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > ___
> > Geotools-devel mailing list
> > Geotools-devel@lists.sourceforge.net 
> > (mailto:Geotools-devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Justin Deoliveira]

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
update hudson.

On Wed, Jun 15, 2011 at 9:45 AM, Jody Garnett wrote:

>  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:
>
>1. aa: check build in Java 6 an apply eventual patches
>   - Update pom to indicate 1.6 as a compiler setting
>2. Update developers guide build instructions
>   - http://docs.geotools.org/latest/developer/guide/building/java.html
>   -
>   
> http://docs.geotools.org/latest/developer/guide/building/install/install.html
>   -
>   
> http://docs.geotools.org/latest/developer/guide/building/install/jdk.html
>   - jg: check the instructions (setting up a fresh machine)
>3. Update user guide
>   -  Quickstart tutorial already advises use of latest JDK
>
> Christian this kind of "build and docs" work is often part of what is meant
> by the PMC "doing the dirty work required to keep the project going" :-) Do
> you have time to do any of the above?
>
> For reference here is the list of tasks:
>
>
> --
> Jody Garnett
>
> On Thursday, 16 June 2011 at 1:21 AM, Andrea Aime wrote:
>
> 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 about geotools ? I have so many places where I use
> IOExpression(String msg). Very often, the message is not enough to
> solve  problems efficiently.
>
> I saw the polls, but I think I must wait for the hudson build server
> working with java 6.
>
>
> The thing got stopped on lack of people volounteering to do the work.
> As said in the old thread, I'm up to check stuff builds on Sun Java 6
> in both projects, and provide eventual patches.
> But we need people for doc changes, updating Hudson and so on
>
> My hope is that once someone provide the patches to make things
> work on java 6 (even if it's just pom changes) the rest will fall into
> line "naturally"
>
> Cheers
> Andrea
>
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Jody Garnett]

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 indicate 1.6 as a compiler setting


Update developers guide build instructions
http://docs.geotools.org/latest/developer/guide/building/java.html
http://docs.geotools.org/latest/developer/guide/building/install/install.html
http://docs.geotools.org/latest/developer/guide/building/install/jdk.html
jg: check the instructions (setting up a fresh machine)


Update user guide
Quickstart tutorial already advises use of latest JDK




Christian this kind of "build and docs" work is often part of what is meant by 
the PMC "doing the dirty work required to keep the project going" :-) Do you 
have time to do any of the above?

For reference here is the list of tasks:


-- 
Jody Garnett


On Thursday, 16 June 2011 at 1:21 AM, Andrea Aime wrote:

> On Wed, Jun 15, 2011 at 5:07 PM,  (mailto:christian.muel...@nvoe.at)> 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 about geotools ? I have so many places where I use
> >  IOExpression(String msg). Very often, the message is not enough to
> >  solve problems efficiently.
> > 
> >  I saw the polls, but I think I must wait for the hudson build server
> >  working with java 6.
> 
> The thing got stopped on lack of people volounteering to do the work.
> As said in the old thread, I'm up to check stuff builds on Sun Java 6 
>  in both projects, and provide eventual patches.
> But we need people for doc changes, updating Hudson and so on
> 
> My hope is that once someone provide the patches to make things
> work on java 6 (even if it's just pom changes) the rest will fall into
> line "naturally"
> 
> Cheers
> Andrea
> 
> 
> 
> -- 
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
> 
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> 
> phone: +39 0584 962313
> fax: +39 0584 962313
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
> 
> ---
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net 
> (mailto:Geotools-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Andrea Aime]

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 about geotools ? I have so many places where I use
> IOExpression(String msg). Very often, the message is not enough to
> solve  problems efficiently.
>
> I saw the polls, but I think I must wait for the hudson build server
> working with java 6.
>

The thing got stopped on lack of people volounteering to do the work.
As said in the old thread, I'm up to check stuff builds on Sun Java 6
in both projects, and provide eventual patches.
But we need people for doc changes, updating Hudson and so on

My hope is that once someone provide the patches to make things
work on java 6 (even if it's just pom changes) the rest will fall into
line "naturally"

Cheers
Andrea


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] About Java 6 on trunk

[christian . mueller]

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  
IOExpression(String msg). Very often, the message is not enough to  
solve  problems efficiently.

I saw the polls, but I think I must wait for the hudson build server  
working with java 6.

Cheers
Christian


This message was sent using IMP, the Internet Messaging Program.



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Jody Garnett (JIRA)]

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 message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Ben Caradoc-Davies]

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/Infosrvices/GeoserverAppSchemaJoining

On 15/06/11 15:18, Niels wrote:
> 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 actually supported joining.
>
> Regards
> Niels
>
> On 14/06/11 03:16, Justin Deoliveira wrote:
> Hi all,
>
> The last major bit of the wfs 2 work is joins. I wanted to start some 
> discussion here and post some questions with regard to the work.
>
> So with the wfs protocol you can do queries now that look like this:
>
> 
>   
>
>  
>a/Identifier
>12345
>  
>  
>a/spouse
>b/Identifier
>  
>
>   
> 
>
> The result is a feature collection that does not contain only feature 
> members, but tuples of feature members. Something like:
>
> 
>   
> 
> ...
> 
> 
>...
> 
>
> 
>
> With that providing a bit of context I would like to bring up some points of 
> discussion.
>
> * app-schema vs simple features
>
> With knowing zero about app-schema currently I believe there is the ability 
> to do joins via feature chaining. However my impression is that these 
> relationships are configured before hand and not really created on the fly? 
> Correct me if I am wrong.
>
> So perhaps we could just say that we support joins with app-schema and call 
> it a day. However that said I do think there is a case for supporting joins 
> with simple features as well. And to be honest working with app-schema, 
> because of the learning curve, would be out of scope for this project.
>
> * cross datastore joins
>
> When talking about doing joins there are varying levels of complexity. For 
> instance talking about supporting joins of feature types within a jdbc 
> datastore is one thing. Supporting joining say a shapefile feature type to a 
> jdbc feature type is a total different ball of wax. Doing cross datastore 
> joins is something i think would be neat... but far from trivial to do it in 
> a way that scales. A much simpler problem would be joining two feature types 
> within the same datastore. However still unless the datastore is one that can 
> do joins natively (jdbc is really the only one here) it is still a hard 
> problem. For instance consider attempting to join two Shapefile feature types 
> from the same datastore... doable but again difficult to do in a non naive 
> way.
>
> * query interface
>
> Given that only some datastores can do joins efficiently makes it a good 
> candidate for QueryCapabilities with the addition of a method 
> "isJoiningSupported". That interface change is relatively straight forward. 
> However one that is not is how to modify Query (if that is the way to go) to 
> support joins. I can think of a few different strategies:
>
> 1. Not modify it at all and come up with a new interface called 
> "JoinSupportingDataStore" or something that adds some new methods for joins.
>
> 2. Subclass Query and add some new join methods. Looking around I actually 
> notice that there is some code in app-schema that does just this called 
> JoiningQuery
>
> 3. Modify Query directly to add support for joins
>
> Thoughts? When I thought about the alternatives I thought (3) made the most 
> sense. Especially given how we support other concepts that are not supported 
> in all datastores like sorting.
>
> So I decided to go further with (3), and added a class called "Join", that 
> looks something like the following:
>
> class Join {
>
>/** the feature type being joined to */
>
>String getTypeName();
>
>/** the attributes from the joined feature type to select */
>
>List  getProperties()
>
>/** the join filter */
>
>Filter getJoinFilter();
>
>/** additional filter to apply to the feature type being joined to */
>
>Filter getFilter();
>
> }
>
> And then it was a matter of modifying Query adding a new property.
>
> class Query {
>
>List  getJoins();
>
> }
>
> So with this api the above query would look something like this:
>
> Query q = new Query("Persons");
> q.setFilter(PropertyIsEqualTo(PropertyName("Identifer"), Literal(12345)));
>
> Join j = new Join("Persons");
> j.setJoinFilter(PropertyIsEqualTo(PropertyName("spouse"), 
> PropertyName("Identifer")));
> q.getJoins().add(j);
>
> That is obviously simplified quite a bit... there still a few things to iron 
> out like handling name clashes, etc... but that would be the general idea. 
> Thoughts?
>
> * joined features
>
> Another major question is what should the result of a j

Re: [Geotools-devel] joins

[Ben Caradoc-Davies]

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 knowing zero about app-schema currently I believe there is the ability 
> to do joins via feature chaining. However my impression is that these 
> relationships are configured before hand and not really created on the fly? 
> Correct me if I am wrong.

-- 
Ben Caradoc-Davies 
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] joins

[Andrea Aime]

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


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] joins

[Niels]

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 actually supported joining.

Regards
Niels

On 14/06/11 03:16, Justin Deoliveira wrote:

Hi all,

The last major bit of the wfs 2 work is joins. I wanted to start some 
discussion here and post some questions with regard to the work.


So with the wfs protocol you can do queries now that look like this:





a/Identifier
12345


a/spouse
b/Identifier





The result is a feature collection that does not contain only feature 
members, but tuples of feature members. Something like:





...


...




With that providing a bit of context I would like to bring up some 
points of discussion.


* app-schema vs simple features

With knowing zero about app-schema currently I believe there is the 
ability to do joins via feature chaining. However my impression is 
that these relationships are configured before hand and not really 
created on the fly? Correct me if I am wrong.


So perhaps we could just say that we support joins with app-schema and 
call it a day. However that said I do think there is a case for 
supporting joins with simple features as well. And to be honest 
working with app-schema, because of the learning curve, would be out 
of scope for this project.


* cross datastore joins

When talking about doing joins there are varying levels of complexity. 
For instance talking about supporting joins of feature types within a 
jdbc datastore is one thing. Supporting joining say a shapefile 
feature type to a jdbc feature type is a total different ball of wax. 
Doing cross datastore joins is something i think would be neat... but 
far from trivial to do it in a way that scales. A much simpler problem 
would be joining two feature types within the same datastore. However 
still unless the datastore is one that can do joins natively (jdbc is 
really the only one here) it is still a hard problem. For instance 
consider attempting to join two Shapefile feature types from the same 
datastore... doable but again difficult to do in a non naive way.


* query interface

Given that only some datastores can do joins efficiently makes it a 
good candidate for QueryCapabilities with the addition of a method 
"isJoiningSupported". That interface change is relatively straight 
forward. However one that is not is how to modify Query (if that is 
the way to go) to support joins. I can think of a few different 
strategies:


1. Not modify it at all and come up with a new interface called 
"JoinSupportingDataStore" or something that adds some new methods for 
joins.


2. Subclass Query and add some new join methods. Looking around 
I actually notice that there is some code in app-schema that does just 
this called JoiningQuery


3. Modify Query directly to add support for joins

Thoughts? When I thought about the alternatives I thought (3) made the 
most sense. Especially given how we support other concepts that are 
not supported in all datastores like sorting.


So I decided to go further with (3), and added a class called "Join", 
that looks something like the following:


class Join {

  /** the feature type being joined to */

  String getTypeName();

  /** the attributes from the joined feature type to select */

  List getProperties()

  /** the join filter */

  Filter getJoinFilter();

  /** additional filter to apply to the feature type being joined to */

  Filter getFilter();

}

And then it was a matter of modifying Query adding a new property.

class Query {

  List getJoins();

}

So with this api the above query would look something like this:

Query q = new Query("Persons");
q.setFilter(PropertyIsEqualTo(PropertyName("Identifer"), Literal(12345)));

Join j = new Join("Persons");
j.setJoinFilter(PropertyIsEqualTo(PropertyName("spouse"), 
PropertyName("Identifer")));

q.getJoins().add(j);

That is obviously simplified quite a bit... there still a few things 
to iron out like handling name clashes, etc... but that would be the 
general idea. Thoughts?


* joined features

Another major question is what should the result of a join look like? 
Given that the current return from a query is features I thought it 
best to stick with that not come up with some new class or something 
to represent a tuple (although maybe that is something worth 
considering). I thought of a few different alternatives. To illustrate 
consider two feature types:


f1 (name, geometry)
f2 (name, foo, geom)

1. Return a single feature with attributes from joined feature types 
"rolled into it". So the resulting joined feature would look like:


  f'(name, geometry, name, foo, geom)

2. Return a single feature that contains attributes for joined features:

  f'(name, geometry, f2)

3. Return a single feature that contains attributes for all fea