[Geotools-devel] [jira] Created: (GEOT-2345) WFS 1.1 GetFeature with maxFeature
WFS 1.1 GetFeature with maxFeature -- Key: GEOT-2345 URL: http://jira.codehaus.org/browse/GEOT-2345 Project: GeoTools Issue Type: Bug Affects Versions: 2.5.3 Environment: Maven version: 2.0.10 Java version: 1.6.0_12 OS name: "linux" version: "2.6.26.8-57.fc8" arch: "i386" Family: "unix" Reporter: raif Attachments: TestIncludeFilter.java i'm seeing different behavior in the response to a WFS GetFeature request when i specify a query limit v/s when i don't but only with WFS 1.1.0; i.e. 1.0.0 returns the same (correct) result in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [Fwd: [jira] Updated: (GEOT-2338) SimpleFeatureTypeImpl has inconsistent iteration order, broken equals/hashCode]
Jody, this defect has the potential to cause some nasty, nasty problems. The patch attached to the issue fixes these (in my opinion) and includes test cases. These problems have always existed in SimpleFeatureTypeImpl, and are only being exposed through the DAFFT API. I shudder every time I port DSSFSFT code to DAFFT (a la GSIP 31) and iterate over properties. I know that something will break if the patch is not applied. It would be great if you could take a look at this. Help me sleep at night. :-) Kind regards, Ben. Original Message Subject: [jira] Updated: (GEOT-2338) SimpleFeatureTypeImpl has inconsistent iteration order, broken equals/hashCode Date: Thu, 19 Feb 2009 11:36:19 +0900 From: Ben Caradoc-Davies (JIRA) To: Caradoc-Davies, Ben (E&M, Kensington) [ http://jira.codehaus.org/browse/GEOT-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Caradoc-Davies updated GEOT-2338: - Priority: Critical (was: Major) This will cause severe problems when people start using GeoServer with GSIP 31 support. Unless you want your simple feature properties randomly reordered, that is. > SimpleFeatureTypeImpl has inconsistent iteration order, broken equals/hashCode > -- > > Key: GEOT-2338 > URL: http://jira.codehaus.org/browse/GEOT-2338 > Project: GeoTools > Issue Type: Bug > Components: core main >Affects Versions: 2.6-M2 >Reporter: Ben Caradoc-Davies >Assignee: Jody Garnett >Priority: Critical > Attachments: SimpleFeatureTypeImpl.updated.patch > > > SimpleFeatureTypeImpl returns its internal property descriptor list via > getAttributeDescriptors(), but when accessed via the FeatureType API > getDescriptors(), will return its property descriptors in a different order. > ComplexTypeImpl (grandparent of SimpleFeatureTypeImpl) uses a HashMap to > store descriptors, so getDescriptors(), which iterates over this Map, will > return descriptors in a random order. This is *A Bad Thing*, because > descriptor order is *very* significant for simple feature types. Furthermore, > ComplexTypeImpl uses Map semantics for equals/hashCode, which is guaranteed > to be order independent. This means that two SimpleFeatureTypeImpl instances > with the same properties in a different order must be equal. This is also *A > Very Bad Thing*. > Changing ComplexTypeImpl to use LinkedHashMap to fix the the iteration order > will not fix the equals/hashCode problem. It is more straightforward and > likely faster to override getDescriptors() to return the descriptors list. > Likewise, equals and hashCode are easily fixed. > The attached patch: > (1) Fixes iteration order by ensuring getAttributeDescriptors() and > getAttributeDescriptors() return the same immutable object. > (2) Makes these methods final to preserve the contract. > (3) Ensures the descriptors member is immutable by making it an unmodifiable > copy. > (4) Adds unit tests for iteration order and equality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] spike
Ah, OK. Thanks for the info ! I'll look into the swing-widgets-pending code before doing anything else. cheers Michael -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ 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-2.5.x #286
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/286/changes -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ 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 #1389
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1389/changes -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-2344) Using sun specific classes kicks out all other java virtual machines
Using sun specific classes kicks out all other java virtual machines Key: GEOT-2344 URL: http://jira.codehaus.org/browse/GEOT-2344 Project: GeoTools Issue Type: Bug Components: data arcsde Affects Versions: 2.5.4, 2.6-M2 Reporter: Christian Mueller Assignee: Gabriel Roldán class ArcSDEGridCoverage2DReaderJAI uses the following SUN specific classes import com.sun.media.imageio.stream.RawImageInputStream; import com.sun.media.imageioimpl.plugins.raw.RawImageReaderSpi; Build and deployment is broken for all developers not using a SUN SDK -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Maven repositories: where to deploy?
IMHO we should make use of the OSGEO maven repo as our primary repo to make the transition definitive. It does not make much sense to me to have svn on OSGE hw but then depend on refractions for our dependencies. Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini --- On Wed, Feb 18, 2009 at 3:18 PM, Martin Desruisseaux wrote: > Its look like that we have 3 Maven repositories around: > > http://download.osgeo.org/webdav/geotools/ > http://lists.refractions.net/m2/ > http://maven.geotools.fr/repository/ > > The one on geotools.fr is a mirror of the refraction's one, synchronized every > night. But what is the relationship between the OSGEO repository and the > Refraction's one? Is one of them the mirror of the other? Or do I have do > deploy > on both? > > I created a GeoAPI 2.2-M2 tag as a safety before the "split module" work and > was > planing to deploy it. > >Martin > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Maven repositories: where to deploy?
Its look like that we have 3 Maven repositories around: http://download.osgeo.org/webdav/geotools/ http://lists.refractions.net/m2/ http://maven.geotools.fr/repository/ The one on geotools.fr is a mirror of the refraction's one, synchronized every night. But what is the relationship between the OSGEO repository and the Refraction's one? Is one of them the mirror of the other? Or do I have do deploy on both? I created a GeoAPI 2.2-M2 tag as a safety before the "split module" work and was planing to deploy it. Martin -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Reminder: going to split GeoAPI in two modules
Hello Rob Rob Atkinson a écrit : > it would be great for the current round of development to be able to > propose changes if needed to the realtively-new-and-untested ISO > Feature interfaces in a more flexible environment than the stable > components. I hope that leaving those interfaces in the "pending" module while give us this flexibility. Historical note: actually we are going back to what GeoAPI had in early day. At the begining, it had a "pending" directory at the request of Polexis, which was the main OGC member pushing the project at that time. Later one the pending directory vanished on the argument that the conventional way to work is with "trunk" and "branches" instead. Now I'm proposing to bring it back because we are not really using branches for experimental work, and we want the pending interfaces to be part of Maven build process. Martin -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ 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 #1388
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1388/changes Changes: [simonegiannecchini] fixing pom to remove gdal dependency -- started Updating http://svn.osgeo.org/geotools/trunk U modules/unsupported/pom.xml At revision 32513 [gt_trunk] $ /opt/actual/maven-2.0.9/bin/mvn -U clean install -Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown POM Location: http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/pom.xml Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...!-- so you may/should consider them risky -->\n http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...!-- so you may/should consider them risky -->\n http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...!-- so you may/should consider them risky -->\n http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1592) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1553) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:504) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) ... 11 more Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...!-- so you may/should consider them risky -->\n http://p.sf.net/sfu/XcvMzF8H ___ 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 #1387
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1387/changes Changes: [simonegiannecchini] -adding imageio-ext-gdal to the build -- started Updating http://svn.osgeo.org/geotools/trunk U modules/plugin/pom.xml At revision 32511 [gt_trunk] $ /opt/actual/maven-2.0.9/bin/mvn -U clean install -Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file 'http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/imageio-ext-gdal/pom.xml'. for project unknown [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/imageio-ext-gdal/pom.xml'. for project unknown at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file 'http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/imageio-ext-gdal/pom.xml'. for project unknown at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1557) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:504) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) ... 11 more Caused by: java.io.FileNotFoundException: http://hudson.opengeo.org/hudson/job/geotools-trunk/ws/gt_trunk/modules/unsupported/imageio-ext-gdal/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at hidden.org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:123) at hidden.org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:67) at hidden.org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:113) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1552) ... 19 more [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Wed Feb 18 08:06:41 EST 2009 [INFO] Final Memory: 13M/23M [INFO] -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Reminder: going to split GeoAPI in two modules
Hello Ben Ben Caradoc-Davies a écrit : > Martin, we would very much like to change GeoAPI so that it can support > XSD complexType with simpleContent. At the moment, we are stuck with an > Ugly Hack: smuggling the simple content in a fake property. I am yet to > write the encoder to unpack this mess. I'm all in favor of changing the interfaces for meeting the need that we face in practice. I do not master Filter so I can not be involved personnaly in this area, but the space is all open for experts like you or other developers who would like to be involved. The GeoAPI Standard Working Group will focus its initial work on metadata and referencing. Work can continue in the pending directory (which will contains Filter) during that time without the need to interact with the SWG group for now. The most important thing that I ask is to annotate every methods like that: • If the method come from a standard, use @UML annotation for saying from which standard it come from and which identifier it has in the standard. • If the method is our own extension not specified in any standard, use the @Extension annotation so we can spot them. Martin -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Build failed in Hudson: geotools-2.5.x #285
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/285/changes Changes: [simonegiannecchini] -adding imageio-ext based plugin to the build [simonegiannecchini] -adding imageio-ext based plugin to the build -- started Updating http://svn.osgeo.org/geotools/branches/2.5.x U modules/unsupported/coveragetools/pom.xml U modules/plugin/pom.xml At revision 32511 [gt_2.5.x] $ /opt/maven2/bin/mvn -U -Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall clean install [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown POM Location: http://hudson.opengeo.org/hudson/job/geotools-2.5.x/ws/gt_2.5.x/modules/unsupported/coveragetools/pom.xml Reason: Parse error reading POM. Reason: end tag name must match start tag name from line 10 (position: TEXT seen ...\n ... @121:14) for project unknown at http://hudson.opengeo.org/hudson/job/geotools-2.5.x/ws/gt_2.5.x/modules/unsupported/coveragetools/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: end tag name must match start tag name from line 10 (position: TEXT seen ...\n ... @121:14) for project unknown at http://hudson.opengeo.org/hudson/job/geotools-2.5.x/ws/gt_2.5.x/modules/unsupported/coveragetools/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: end tag name must match start tag name from line 10 (position: TEXT seen ...\n ... @121:14) for project unknown at http://hudson.opengeo.org/hudson/job/geotools-2.5.x/ws/gt_2.5.x/modules/unsupported/coveragetools/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1416) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:524) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362) ... 11 more Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name must match start tag name from line 10 (position: TEXT seen ...\n ... @121:14) at org.codehaus.plexus.util.xml.pull.MXParser.parseEndTag(MXParser.java:1689) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1131) at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2394) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1412) ... 20 more [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Wed Feb 18 08:22:07 EST 2009 [INFO] Final Memory: 11M/21M [INFO] Failed to send e-mail to simonegiannecchini because no e-mail address is known, and no default e-mail domain is configured
Re: [Geotools-devel] spike
Michael Bedward a écrit : > Hi Johann, > Yes - I chatted with you about your code some time ago :-) > The idea of clearing up JMapPane a bit came from a discussion on the > users' list, followed by a chat between Jody and myself about how to > address the frequent questions that JMapPane generates on the list. > Jody also pointed out your swing-widget-pending work. But I thought > I'd read that you were now working on Java 6 based rendering code That's true I work only on 1.6 now, and it's the same for the swing widgets module I'm working on. > and that this might be included in the back-porting that's been proposed > for Geotidy. Apologies if I've got all that muddled ! In short, I > was reluctant to pick up your previous swing widgets module if it was > just going to be replaced by something else in the near future. The backport to Java 1.5 is only for the modules martin works on. (Referencing and metadata if I'm correct) There is no backport planned for the swing module, since it's my personal work I have no time (and no needs) to do this much work for free. > So > just doing a bit of house keeping on JMapPane seemed like a safer > option. > I suggest you at least try the swing componant, it's stable and perhaps already have what you are looking for. > Mmmm... as I write this I'm thinking that laziness was also part of my > thinking ! With the swing widgets code being sparsely documented, and > without having used it very much myself yet, I was worried that I > didn't know how much work would be involved in taking it on. > You dont have to maintain every widget, only the mapwidget. > Michael > > 2009/2/18 johann sorel : > >> Hi, >> >> Perhaps you are not aware of it but there is a >> swing-widget-pending module in geotools. >> >> It's I think a more appropriate place for swing work. >> -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ 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 #1386
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1386/changes Changes: [simonegiannecchini] adding imageio-ext-gdal to the build -- started Updating http://svn.osgeo.org/geotools/trunk D modules/unsupported/imageio-ext-gdal A modules/plugin/imageio-ext-gdal A modules/plugin/imageio-ext-gdal/src A modules/plugin/imageio-ext-gdal/src/test A modules/plugin/imageio-ext-gdal/src/test/java A modules/plugin/imageio-ext-gdal/src/test/java/org A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/dted AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/dted/AbstractDTEDTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/dted/DTEDTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/dted/ServiceTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/nitf AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/nitf/AbstractNITFTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/nitf/NITFTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/nitf/ServiceTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2kak AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2kak/ServiceTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2kak/AbstractJP2KTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2kak/JP2KTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/AbstractGDALBasedTestCase.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2mrsid AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2mrsid/ServiceTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2mrsid/AbstractJP2MrSIDTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/jp2mrsid/JP2MrSIDTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/erdasimg AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/erdasimg/ServiceTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/erdasimg/AbstractErdasImgTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/erdasimg/ErdasImgTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/ecw AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/ecw/ServiceTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/ecw/AbstractECWTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/ecw/ECWTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/mrsid AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/mrsid/ServiceTest.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/mrsid/AbstractMrSIDTestCase.java AU modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/gdal/mrsid/MrSIDTest.java A modules/plugin/imageio-ext-gdal/src/test/java/org/geotools/coverageio/BaseGridFormatFactorySpiTest.java A modules/plugin/imageio-ext-gdal/src/test/resources A modules/plugin/imageio-ext-gdal/src/test/resources/org A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/dted A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/dted/test-data A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/dted/test-data/n43.dt0 A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/nitf A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/nitf/test-data A modules/plugin/imageio-ext-gdal/src/test/resources/org/geotools/coverageio/gdal/jp2kak
[Geotools-devel] [jira] Created: (GEOT-2343) Allow user to specify which fields to use for FID mapping
Allow user to specify which fields to use for FID mapping - Key: GEOT-2343 URL: http://jira.codehaus.org/browse/GEOT-2343 Project: GeoTools Issue Type: Bug Components: data jdbc-ng Reporter: Andrea Aime Assignee: Andrea Aime Views can still have a unique column, it's just not stated as a primary key in the metdata. Allow user to specify which column(s) to use for fid mapping on a feature type per feature type basis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] spike
Hi Johann, Yes - I chatted with you about your code some time ago :-) The idea of clearing up JMapPane a bit came from a discussion on the users' list, followed by a chat between Jody and myself about how to address the frequent questions that JMapPane generates on the list. Jody also pointed out your swing-widget-pending work. But I thought I'd read that you were now working on Java 6 based rendering code and that this might be included in the back-porting that's been proposed for Geotidy. Apologies if I've got all that muddled ! In short, I was reluctant to pick up your previous swing widgets module if it was just going to be replaced by something else in the near future. So just doing a bit of house keeping on JMapPane seemed like a safer option. Mmmm... as I write this I'm thinking that laziness was also part of my thinking ! With the swing widgets code being sparsely documented, and without having used it very much myself yet, I was worried that I didn't know how much work would be involved in taking it on. Michael 2009/2/18 johann sorel : > Hi, > > Perhaps you are not aware of it but there is a > swing-widget-pending module in geotools. > > It's I think a more appropriate place for swing work. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Licenses WIKI Page comments and supporting ImageIO-Ext in next geotools release
Hi all, just to clarify. Our goal, is to include gdal support via the imageio-ext plugin in the build for next release as part of our plugins, and this means dragging some imageio-ext dependencies into the build. Since there were questions about licenses we tried to map, with great help from aaime, licensing info from all (most??) geotools dependencies to clarify the situation. I am going to add the module to build today to see if there are any problems. For next release I will create a file (licenses.txt, third-party.txt, whatever.txt?) that we can include in the files we give away so that we sum the result of the license investigation and we cope with the advertisement clause. Notice that we have deployed the dependencies for the imageio-ext plugin in various maven repo (release 1.0.1) and we have been careful (or at least tried to be :-9 ) about excluding tests and the SPI registration if the native dependencies are not around. Anyway, if you have any problems, please report them and we'll fix them. Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini --- On Wed, Feb 18, 2009 at 9:40 AM, Daniele Romagnoli wrote: > Hi List, > did you taken a look on the Licenses Investigation WIKI page? > http://docs.codehaus.org/display/GEOTOOLS/Licenses+Investigation > We would like to add ImageIO-Ext geotools module to the next geotools > release. > Therefore, we have added Licensing information about the 2 imageio-ext > submodules [imageio-ext-tiff and imageio-ext-imagereadmt] released as Custom > BSD (Being SUN's JAI-ImageIO derivative work to fix the TIFF issues and > adding ImageRead Multithreading capabilities). > > Which is next step? > > Regards, > Daniele > > > -- > --- > Eng. Daniele Romagnoli > Software Engineer > > GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 328 0559267 > > > http://www.geo-solutions.it > > --- > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] spike
Hi, Perhaps you are not aware of it but there is a swing-widget-pending module in geotools. It's I think a more appropriate place for swing work. Beside there is already a better implementation of JMapPane in it : org/geotools/gui/swing/map/map2d/stream/JStreamNavMap.java There is also a wiki page, but it's not up to date. http://docs.codehaus.org/display/GEOTOOLS/widgets-swing-pending I was the maintainer for this module, but I no lo longer work on it (Swing Puzzle-GIS now) If you want to continue this work, I would be glad to see this module revival. johann Michael Bedward a écrit : > Hi folks, > > Is the spike dir open access ? I'm looking for a place to put > in-progress code while tweaking JMapPane. > > cheers > Michael > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Licenses WIKI Page comments and supporting ImageIO-Ext in next geotools release
Hi List, did you taken a look on the Licenses Investigation WIKI page? http://docs.codehaus.org/display/GEOTOOLS/Licenses+Investigation We would like to add ImageIO-Ext geotools module to the next geotools release. Therefore, we have added Licensing information about the 2 imageio-ext submodules [imageio-ext-tiff and imageio-ext-imagereadmt] released as Custom BSD (Being SUN's JAI-ImageIO derivative work to fix the TIFF issues and adding ImageRead Multithreading capabilities). Which is next step? Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
