Re: [Geotools-devel] [ExternalEmail] Re: compile failure?
Jody and Mauro, I have pushed a fix to master. Please try again. Kind regards, Ben. On 28/05/13 15:53, Ben Caradoc-Davies wrote: And fails repeatably in Maven when run by itself using -Dtest=GMLParserTest. The reason appears to be it relying on the side effects of SchemaParserTest or SchemaParser2Test, which copy the missing resource to test-classes. If GMLParserTest runs first, it fails. On 28/05/13 15:43, Ben Caradoc-Davies wrote: It fails repeatedly in Eclipse when my workspace is clean. After a successful Maven run of the tests, it passes every time in Eclipse. On 28/05/13 15:38, Ben Caradoc-Davies wrote: Oh, you are quite right: it is intermittent, even in Eclipse. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Community patch submission and the contributor agreement
On 28/05/13 14:18, Jody Garnett wrote: I am wondering if we can instead have a contributor-agreement-lite, I think this page was meant to have checkboxes and an accept button: http://www.eclipse.org/legal/CLA.php (It says at the top that it is a reference copy, to actually fill it in you login to the eclipse website and they have a checkbox or form thing you can fill in). Thanks, Jody. I think I have been conditioned to ignore bold text. :-P -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Community patch submission and the contributor agreement
We could make everyone agree, and make it really easy, like a web form. I could not find an form version of the Eclipse CLA. On 28/05/13 14:18, Jody Garnett wrote: How about we write the thing up clearly in the developers guide, and we add a description into JIRA when they report the bug (we already have our own custom descriptions). We may be able to link to the correct page of the developers guide. I am wondering if we can instead have a contributor-agreement-lite, which does not require access to a printer and scanner. I think this page was meant to have checkboxes and an accept button: http://www.eclipse.org/legal/CLA.php (It says at the top that it is a reference copy, to actually fill it in you login to the eclipse website and they have a checkbox or form thing you can fill in). Anyone have experience with other open source projects that have addressed this issue? Here is an example from webkit http://www.webkit.org/coding/contributing.html The phrase they use is: /If you make substantive changes to a file, you may wish to add a copyright line for yourself or for the company on whose behalf you work. / / / This kind of brings us full circle - what is a substantive change? In a sense it does not really matter as long as we are clear… Story could go something like: * Fill in code contribution agreement … when introducing a new method? Downside is we actually like new methods introduced for clarity, and do not want to encourage super long methods. * Fill in agreement when new public or protected method? That is a bit safer, as changing API = code contribution agreement. Downside is we like to encourage creation of tests with each patch. * Fill in code contribution agreement when creating a new file. (original recommendation) It makes sense as have a new item to track copyright on, and the header needs to be filled in anyways (so it is not out of our way to think about copyright). Jody -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
Thanks, Mauro. That looks great! I had two small stylistic observations: (1) I do not think you need your static synchObject; you could achieve the same effect synchronising on the class object with synchronized(SchemaClass.class). (2) If you make any minor changes, please remove the trailing whitespace that appears on several lines. (I use Show whitespace characters in Eclipse.) Please go ahead and merge with or without these minor changes. Kind regards, Ben. On 28/05/13 00:50, Mauro Bartolomeoli wrote: Hi all, I tried to fix some remaining issues with GEOT-4467, in particular the File.deleteOnExit() usage. You find the alternative solution here: https://github.com/mbarto/geotools/commit/c1733941f9cfaf3642e7ce33cf8844b4ae21b104 It's based on synchronization in the topic moments of resolving from cache, that are: - checking for cached schema existance on disk before downloading it - storing the downloaded file to disk Synchronization is used to avoid returning a partially written file. A check is introduced to not write a schema to disk after download, if it already exists (downloaded from another thread). Synchronization time should be short (the time to write a schema file on disk). Let me know if this approach seems better or worse than the previous one. Mauro 2013/5/24 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au [back on list] On 24/05/13 15:06, Mauro Bartolomeoli wrote: 2013/5/24 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:Ben.Caradoc-Davies@__csiro.au mailto:ben.caradoc-dav...@csiro.au Mauro, I do not like the exception swallowing in SchemaCache.download(). You changed to original: throw new RuntimeException(e); to return null; You are right, please have a look at my new commit: https://github.com/mbarto/__geotools/commit/__d81f9f2dbaf549c6a0b47fda96bfef__4bfccf2695 https://github.com/mbarto/geotools/commit/d81f9f2dbaf549c6a0b47fda96bfef4bfccf2695 I introduced a checked exception (IOException) so that I'm able to catch it and call endDownload also in case of failure (this was the reason I removed the throw in my first commit). I don't understand. You changed this to a checked exception, but the only place you catch the exception you just chain and throw as a RuntimeException. Why do you need a checked exception? Unless I missed something, the cleanup is performed in the finally block, which is called for all exceptions, including unchecked, regardless of the contents of the catch. Please correct me if I am wrong or have misunderstood. Furthermore, if you want to use checked exceptions (which is a matter of taste and you are quite welcome to do so if you prefer), you can be even more consistent and catch IOException not Exception in download(); SocketTimoutException is a sub-sub-class of IOException. Either way should result in the same logic on timeout or other network failure. I also notice that you make extensive use of File.deleteOnExit(). I wonder if this is a best-practice as the list of files to be deleted may grow for a long-running application. Some reports suggest it lives in native memory. Others report deletion is unreliable. Ask Andrea, who is our expert on performance and memory leaks. http://puneeth.wordpress.com/__2006/01/23/filedeleteonexit-__is-evil/ http://puneeth.wordpress.com/2006/01/23/filedeleteonexit-is-evil/ http://www.pongasoft.com/blog/__yan/java/2011/05/17/file-dot-__deleteOnExit-is-evil/ http://www.pongasoft.com/blog/yan/java/2011/05/17/file-dot-deleteOnExit-is-evil/ Oh my, I am feeling like a grumpy old man today. :-) I also updated the downloadTimeout to 60 seconds (for paranoids :-) ). Looks good! Feel free to merge into master as it is or with minor revisions. Do not give me a chance for more nitpicking. ;-) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre
Re: [Geotools-devel] Proposal: efficient support for multicoverage grid readers
+0. Andrea, this is a thoroughly documented proposal. The level of detail inspires confidence; only my lack of knowledge of coverages in GeoServer limits my vote to +0. On 08/05/13 23:34, Andrea Aime wrote: Hi all, here is our overhauled proposal for multicoverage grid readers: http://docs.codehaus.org/display/GEOTOOLS/Efficient+support+for+multiple+coverages+in+GridCoverageReader This proposal allows to break the 1-1 relationship between reader and coverage, and allows proper support for multicoverage sources, such as spatial databases, ArcSDE, NetCDF (often they contain more than one coverage per file). Feedback, questions, and votes welcomed :-) Cheers Andrea -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: structured coverage grid readers, aka generic means of finding what's inside a mosaic
+0. (Same reason as before.) I do have a couple of questions: My recollection is that the NetCDF CF (previously COARDS) Conventions were limited to one-grid-per file. Are your multiple coverages all on the same grid? Do you support CF Conventions? Kind regards, Ben. On 09/05/13 00:00, Andrea Aime wrote: Hi, a second proposal we'd like to push forward is the ability to look under the hood of a grid reader that does mosaicking of information (either spatial, temporal or along other dimensions) and get to know the pieces making it up: http://docs.codehaus.org/display/GEOTOOLS/Structured+grid+coverage+readers The first obvious candidate for this is image mosaic. ImageMosaicJDBC could be another one, if there is interest in extending it. A side benefit of this proposal is that it would allow applications to be more flexible in terms of what dimensions they offer, instead of having to accept a time dimension that the reader is proposing, they could inspect the date attributes in the granules schema and pick one of their choosing (and then send down a Filter when doing the readCoverage request to select the bits they want), and also, it would allow us to work against large domains more efficiently, since we would not need to convert them to strings and back anymore (a limitation that comes with the reader metadata map being string oriented). Also, with this proposal, along with the previous one, we'd be able to commit also the NetCDF reader as a community module. The NetCDF reader we have been developing supports multiple coverages per NetCDF file (e.g., Polyphemus files have 3 coverages inside), supports multiple dimensions, and has multi-level indexing to allow fast access to a certain coverage/time/elevation combiantion (we basically move directly to the offset in the netcdf file containing the information we want). The NetCDF reader is also the first example of the Grid coverage api to come, one that mimics 1-1 the datastores api: it's basically built on it, and then adapted to the existing GridCoverageReader one. The reason for this is that we don't know exactly when we'll be able to push the new api so that all readers can adopt it, that is significant work that we are not likely to accomplish in the next 6 months, so these two proposals are stepping stones towards it (regardless, even when we do the switch we'll need wrappers towards the old api to allow a transition period and an API deprecation cycle). But at least, it would mean the new coverage api gets from spike, where it has been sitting for a few years now, to unsupported land. If you haven't followed the discussion a few years ago, the coverage-api that we're talking about is here: https://github.com/geosolutions-it/geotools/tree/multidim/modules/unsupported/coverage-experiment/coverage-api and the NetCDF provider is here: https://github.com/geosolutions-it/geotools/tree/multidim/modules/unsupported/coverage-experiment/netcdf Cheers Andrea -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Community patch submission and the contributor agreement
With the recent adoption of the new GeoTools contributor agreement, the PMC considered the status of patches submitted by community members who have not signed the agreement. For example, we sometimes receive patches attached to Jira issues or emailed to the mailing lists. As mentioned in recent committee meeting notes, we had hoped to emulate Eclipse and allow small patches (with no new files) received from the community to be incorporated into the code base. It has not turned out to be as easy as we had hoped. Jody, I looked at the Eclipse committer documentation: http://www.eclipse.org/legal/committerguidelines.php This states that Eclipse rely on their website terms of use to obtain assertions of ownership and irrevocable grants of license: http://www.eclipse.org/legal/termsofuse.php We have no such terms of use, as our Jira is provided by Codehaus and our mailing lists are provided by SourceForge. I am wondering if we can instead have a contributor-agreement-lite, which does not require access to a printer and scanner. I think this page was meant to have checkboxes and an accept button: http://www.eclipse.org/legal/CLA.php Anyone have experience with other open source projects that have addressed this issue? Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
[back on list] On 24/05/13 15:06, Mauro Bartolomeoli wrote: 2013/5/24 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au Mauro, I do not like the exception swallowing in SchemaCache.download(). You changed to original: throw new RuntimeException(e); to return null; You are right, please have a look at my new commit: https://github.com/mbarto/geotools/commit/d81f9f2dbaf549c6a0b47fda96bfef4bfccf2695 I introduced a checked exception (IOException) so that I'm able to catch it and call endDownload also in case of failure (this was the reason I removed the throw in my first commit). I don't understand. You changed this to a checked exception, but the only place you catch the exception you just chain and throw as a RuntimeException. Why do you need a checked exception? Unless I missed something, the cleanup is performed in the finally block, which is called for all exceptions, including unchecked, regardless of the contents of the catch. Please correct me if I am wrong or have misunderstood. Furthermore, if you want to use checked exceptions (which is a matter of taste and you are quite welcome to do so if you prefer), you can be even more consistent and catch IOException not Exception in download(); SocketTimoutException is a sub-sub-class of IOException. Either way should result in the same logic on timeout or other network failure. I also notice that you make extensive use of File.deleteOnExit(). I wonder if this is a best-practice as the list of files to be deleted may grow for a long-running application. Some reports suggest it lives in native memory. Others report deletion is unreliable. Ask Andrea, who is our expert on performance and memory leaks. http://puneeth.wordpress.com/2006/01/23/filedeleteonexit-is-evil/ http://www.pongasoft.com/blog/yan/java/2011/05/17/file-dot-deleteOnExit-is-evil/ Oh my, I am feeling like a grumpy old man today. :-) I also updated the downloadTimeout to 60 seconds (for paranoids :-) ). Looks good! Feel free to merge into master as it is or with minor revisions. Do not give me a chance for more nitpicking. ;-) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
On 23/05/13 14:26, Andrea Aime wrote: On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: http://www.w3.org/2001/xml.xsd Ah, this one is a nightmare, it's always super-slow to download (I guess because anything XML ends up linking it). Imho, we should have a copy of it baked directly into code to avoid downloading it over and over. Placing this file as /org/w3/www/2001/xml.xsd on the classpath (in any jar) will cause SchemaResolver to pick it up before hitting SchemaCache. The gt-xml jar is a good place. This is currently being imported via the new xlink.xsd and smil20.xsd (since the great XLink change of 2012). (1) Why do you set a timeout at all? Just a best practice to avoid an application hang? (Good idea!) If so, the obvious workaround is to increase the timeout (60 seconds?) to accommodate slow servers. Would this be a satisfactory solution? I'd say, make it configurable. 10 seconds to start responding in 2013 is not slow, it's a geologic era... Good idea. But what default? Java 6 defaults to waiting indefinitely, which will never fail[*]. :-D [*] Depending on your definition of failure, of course. The original AppSchemaCache had no timeout and did not write to a file until it had all the bytes of the remote resource, so 9.x is not affected by these issues. Right right, good idea to complete the write on disk only when the download is complete to avoid half downloaded files. But keeping everything in memory could be dangerous, maybe write a temp file and rename it to the final destination once done The resources are only kilobytes. Using a temp file is Mauro's solution to parallel thread support; the temp copy is discarded after use (the first thread uses a non-temp location). A subtle change to this behaviour could be a solution. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
On 23/05/13 15:20, Mauro Bartolomeoli wrote: 2013/5/23 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:Ben.Caradoc-Davies@__csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: http://www.w3.org/2001/xml.xsd Placing this file as /org/w3/www/2001/xml.xsd on the classpath (in any jar) will cause SchemaResolver to pick it up before hitting SchemaCache. The gt-xml jar is a good place. Sure, and it's used also by inspire schemas. Where do you thing could be a good place to put it, the gt-xml module itself? That sounds like the perfect place. If you download http://www.w3.org/2001/xml.xsd and then save it as: modules/library/xml/src/main/resources/org/w3/www/2001/xml.xsd and commit it on master, then Maven will bundle it into the gt-xml jar, SchemaResolver will find it on the classpath, and it will never be downloaded ever again. Because we are now shipping it with GeoTools we need to acknowledge the W3C license. Please note where you got it in the module review file: modules/library/xml/src/site/apt/review.apt Please also add the W3 license to the top-level in the project license folder: http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 We already have a copy of xml.xsd in gt-xsd-core, but it is in the wrong place for SchemaResolver; also some files have been modified to work with code (unacceptable for app-schema users). I do not know if the copyright of this file was acknowledged. Please check the review file. PMC, do we need to include the W3C short notice anywhere? Do we have a page that lists all the licenses? (Jody knows all.) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
Mauro, 30 seconds sounds like a generous default. Maybe even 60 seconds for the paranoid? I think your decision to have a timeout is excellent, as a thread could otherwise block indefinitely, which would be very, very bad for a service such as GeoServer. Kind regards, Ben. On 23/05/13 16:34, Mauro Bartolomeoli wrote: Hi Ben, (2) Please look at the logic in SchemaCache.startDownload(). Why is it necessary to create an empty file? How should SchemaCache recover when a download fails? Please have a look and recommend a solution. I know you gave this some thought and I do not want to introduce a deadlock or thread blocking that might impact your performance. I had a look at the code, and the empty file creation seems not useful in that point. I don't remember why I introduced it. Maybe it was there for some file existance check, but that check is not there anymore. So I'm going to remove the empty file creation completely. The connect timeout instead was there to prevent a deadlock. I'm going to make it configurable through an env variable (-Dschema.cache.download.timeout is ok for you?). For the default, maybe we can set it to 30seconds. What do you think? Mauro -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SchemaCache timeout error
Mauro, I do not like the exception swallowing in SchemaCache.download(). You changed to original: throw new RuntimeException(e); to return null; in the catch block. While this will result in a failed download and an exception higher up that includes a URL report, precise network or DNS error reports will be swallowed. I am wondering if these are useful enough for deployment debugging that they should be retained by keeping the throw? What do you think? My original throw was also inadequate because is prevents the reporting of the problematic URL, causing me problems analysing this behaviour. If you think this throw should be left, perhaps we could improve it to report the problematic URL: throw new RuntimeException(Error downloading + location.toString(), e); Your other code changes look great and your handling of the W3C licence is just right. Thanks! Kind regards, Ben. On 23/05/13 20:07, Mauro Bartolomeoli wrote: Please, have a look at my fix proposal at https://github.com/mbarto/geotools/commit/ea85a28ff360e5be2b5c5843eb2cbf30ee68ba9f If you think it's ok I'll merge it on master. Thanks. Mauro 2013/5/23 Mauro Bartolomeoli mauro.bartolome...@geo-solutions.it mailto:mauro.bartolome...@geo-solutions.it Hi Ben, (2) Please look at the logic in SchemaCache.startDownload(). Why is it necessary to create an empty file? How should SchemaCache recover when a download fails? Please have a look and recommend a solution. I know you gave this some thought and I do not want to introduce a deadlock or thread blocking that might impact your performance. I had a look at the code, and the empty file creation seems not useful in that point. I don't remember why I introduced it. Maybe it was there for some file existance check, but that check is not there anymore. So I'm going to remove the empty file creation completely. The connect timeout instead was there to prevent a deadlock. I'm going to make it configurable through an env variable (-Dschema.cache.download.timeout is ok for you?). For the default, maybe we can set it to 30seconds. What do you think? Mauro -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 tel:%2B39%200584%20962313 fax: +39 0584 1660272 tel:%2B39%200584%201660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SchemaCache timeout error
Mauro, your improvements to SchemaCache have also introduced an unanticipated problem triggered by download failure: https://jira.codehaus.org/browse/GEOT-4467 You set a 10 second timeout on connections and reads. It turns out that some application schemas, including that used in the GeoServer app-schema tutorial, import this W3 schema, which often takes more than 10 seconds to connect: http://www.w3.org/2001/xml.xsd Furthermore, when a download fails, an empty file is created in the cache, preventing further download attempts. The cache is poisoned and the file must be manually removed. For example, restarting GeoServer does not permit another download attempt. I would like to fix these problems, but I need your advice because I am not familiar with your use of SchemaCache and I do not want to, in fixing one bug, introduce another and break client code. (1) Why do you set a timeout at all? Just a best practice to avoid an application hang? (Good idea!) If so, the obvious workaround is to increase the timeout (60 seconds?) to accommodate slow servers. Would this be a satisfactory solution? (2) Please look at the logic in SchemaCache.startDownload(). Why is it necessary to create an empty file? How should SchemaCache recover when a download fails? Please have a look and recommend a solution. I know you gave this some thought and I do not want to introduce a deadlock or thread blocking that might impact your performance. The original AppSchemaCache had no timeout and did not write to a file until it had all the bytes of the remote resource, so 9.x is not affected by these issues. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Got to bottom of bug with arcsde plugin but less certain on fixing it.
[Moved from the user list]
This is where the arcsde module suffers from not being one of the jdbc
modules, where this problem is solved be keeping two feature types: the
one used for handling the query and the one to be returned. Have a look
in gt-jdbc JDBCFeatureSource.buildQueryAndReturnFeatureTypes, where
these types are constructed. Also, for SQL sources, queries are split
into the pre and post filters, pre being converted to SQL, and post the
parts that cannot be and are to be filtered in Java. Because filtering
might need more properties than are required to be returned, a feature
type is created to include these extra properties. I do not know if
arcsde does filter splitting.
Kind regards,
Ben.
On 21/05/13 12:03, Phil Scadden wrote:
If you extract from arcSDE with a spatial filter, (BBOX,POLYGON) then it
is filtered twice. The query to arcSDE has the spatial constraint so the
correct no. of records is returned. However, in
FilteringFeatureReader.hasNext() we have: while
(featureReader.hasNext()) { peek = featureReader.next(); if
(filter.evaluate(peek)) { next = peek; return true; } } The filter is
evaluated by filter.evaluate. In most cases, the all will pass. However,
consider requesting only non-spatial attributes from the query. Ie SHAPE
is not part of feature. The sde query still returns the correct no. of
records, but filter.evaluate fails because it cant find the SHAPE
property in the feature. So how to fix? Ideally, when arcSDE can do the
spatial operation, then filter shouldnt be needed. However, the same
problem would then arise when the spatial operator is one that JTS can
handle but arcSDE cant. If SHAPE is forced into the property list for
filtering, can it be removed in the returned features. (The use case is
with WFS when wanting a single attribute about overlapped polygons, but
definitely not wanting the very complex polygon geometry coming down the
wire).
Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GeoTools 9.2 Released
http://geotoolsnews.blogspot.com.au/2013/05/geotools-92-released.html The GeoTools community is pleased to announce the availability of GeoTools 9.2 for download from SourceForge: http://sourceforge.net/projects/geotools/files/GeoTools%209%20Releases/9.2/geotools-9.2-bin.zip/download http://sourceforge.net/projects/geotools/files/GeoTools%209%20Releases/9.2/geotools-9.2-doc.zip/download http://sourceforge.net/projects/geotools/files/GeoTools%209%20Releases/9.2/geotools-9.2-userguide.zip/download http://sourceforge.net/projects/geotools/files/GeoTools%209%20Releases/9.2/geotools-9.2-project.zip/download This release has also been deployed to the OSGeo Maven Repository. Please see the Release Notes for details. This release is made in conjunction with GeoServer 2.3.2. In addition to bug fixes: - The application schema support (app-schema) module now enables joining support by default for data sources that support it; this improvement and many bug fixes by Rini Angreani. - XML parser support for unsigned numeric bindings has been added by Justin Deoliveira. -Fixed transformation problems with projections based on Hotine Oblique Mercator (variant B) (for example Swiss CH1903 / LV03) We would like to thank all contributors for making this release possible. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Draft 9.2 release blog announcement
Bloggers please review the draft 9.2 release announcement: http://geotoolsnews.blogspot.com/ -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Draft 9.2 release blog announcement
On 17/05/13 14:11, Jody Garnett wrote: A couple small feedbacks… - needed to add a title (corrected it - if not it makes something up based on the first sentence). Thanks, Jody, I was wondering what happened there. I also tagged it with the release label. - can you cut and paste the about the GeoTools 9 series from the last post? Good thinking: this might be the first GeoTools page for a new user and it is good publicity. - for the functionality/fixes do we know individuals or organisations we can thank? Done. But I need some help as I do not know all the context. And do thank CSIRO for making this release available (I know that is only a small thing, but we are thankful for your time). OK, will do. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Smoke testing GeoTools 9.2 release artifacts
All testers welcome: http://gridlock.opengeo.org/geotools/release/9.2/ -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] release feedback
This is still true for 9.2. On 21/04/13 11:44, Jody Garnett wrote: 1) the README.html included in the release refers to the latest documentation (rather than stable). -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GeoTools 9.2 release this week
I have a good set of GT/GS revisions with working CITE tests, so feel free to go back to breaking things in 9.x. :-) On 14/05/13 09:22, Ben Caradoc-Davies wrote: I will be releasing GeoTools 9.2 this week. Please refrain from committing to the 9.x branch until the release is complete. Announcement will be on Monday 20 May. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Hudson geotools-release lists wildly inaccurate Changes
So, in releasing 9.2, I saw the change list, and thought that writing the release notes was going to be straightforward: http://hudson.opengeo.org/hudson/view/All/job/geotools-release/60/ And then I noticed bleeding-edge changes that I was certain should not be on stable: http://hudson.opengeo.org/hudson/view/All/job/geotools-release/60/changes#detail8 Commit bd684ec5e0fdb1d7b41c10d8e4cd10e1cf9fd58d by Niels Charlier GEOS-5779 Implementation of SortBy in App-Schema Manual inspection of git log on 9.x confirms that this change is *not* on 9.x. Manual inspection of the source code confirms that this change is not in the 9.2 source bundle. So, is this a known problem? Is this just Hudson scraping the console log and getting the wrong idea? Perhaps we need a big notice in the release guide warning release engineers to ignore Hudson when writing release notes. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Hudson geotools-release lists wildly inaccurate Changes
On 15/05/13 16:50, Andrea Aime wrote: On Wed, May 15, 2013 at 10:47 AM, Andrea Aime andrea.a...@geo-solutions.it mailto:andrea.a...@geo-solutions.it wrote: We always used jira to write the release notes (in other words, if a commit does not have an associated ticket, closed in time, it's as if it never occurred). Never had a look at Hudson's output honestly, and it seems it is not setup to provide a changelog anyways. +1 to warn the release manager not to look at it Btw, once the release is published one way to get the real list of changes should be: git fetch -t geotools (or whatever your remote for the official repo is called) git log 9.1..9.2 Right now you cannot run it because 9.2 does not exist yet on the official git repo (the publish script creates it). Thanks. It took me a little while to realise that I needed fetch -t to get tags not reachable from branch heads. I should note this and your git-log advice in the guide as well. Local clean build went fine. All artifacts look good. Publish is currently stuck in the Hudson traffic jam, but shouldn't be long now. Release notes not needed until Monday. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Hudson geotools-release lists wildly inaccurate Changes
Ah, thanks, Justin. That explains everything. On 15/05/13 22:56, Justin Deoliveira wrote: Yeah, the hudson job isn't really set up for this. The first thing hudson does us update master to grab the latest scripts, which is where you are seeing that change log from. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GeoTools 9.2 release this week
I will be releasing GeoTools 9.2 this week. Please refrain from committing to the 9.x branch until the release is complete. Announcement will be on Monday 20 May. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4457) DecoratingSimpleFeatureCollection does not delegate accepts method
Ben Caradoc-Davies reopened GEOT-4457 DecoratingSimpleFeatureCollection does not delegate accepts method Broke the build on both 9.x and master. Change By: Ben Caradoc-Davies (01/May/13 9:12 PM) Status: Resolved Reopened Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PSC/PMC biweekly meeting reminder
Yes, that time is correct. On 28/04/13 23:24, Andrea Aime wrote: Hi folks, just a reminder that tomorrow it's meeting day, please try to attend. If you cannot and you wish people to discuss a certain topic, toss it over in this thread :-p If memory serves me right, this is the time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools%2FGeoServer+meetingiso=20130429T13 http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools%2FGeoServer+meetingiso=20130429T13 Cheers Andrea -- == GeoServer training in Milan, 6th 7th June 2013! Visit http://geoserver.geo-solutions.it http://geoserver.geo-solutions.it/ for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: upgrading the shapefile module to shapefile NG
+1. Looks good to me. This change should be fine on master. Kind regards, Ben. On 07/04/13 22:22, Andrea Aime wrote: Hi all, here is a proposal to upgrade the shapefile-ng module to supported status, and make shapefile become (temporarily) an unsupported module named shapefile-old: http://docs.codehaus.org/display/GEOTOOLS/Migrate+shapefile+to+shapefile-ng and here is the pull request: https://github.com/geotools/geotools/pull/176 The API changes are minimal, most well written client code won't notice, the code builds fine, GeoServer only needed a couple one liners to build and work against the new shapefile: https://github.com/geoserver/geoserver/pull/204 I have no word from uDig, as far as I know they are stuck on an old version of GeoTools since they still haven't upgraded to the changes of the feature collection cleanup. I believe this is a good time to perform the swap as we have months ahead before the release, if there are lingering issues we should be able to spot them and sort them out before the release Please vote/discuss Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Monday meeting and Italian national holidays
On 02/04/13 16:07, Andrea Aime wrote: I like 13:00 UTC: http://www.timeanddate.com/__worldclock/meetingdetails.__html?year=2013month=4day=15__hour=13min=0sec=0p1=55p2=__215p3=196p4=240 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013month=4day=15hour=13min=0sec=0p1=55p2=215p3=196p4=240 Yes, I like that time too. Btw, wasn't there any meeting yesterday? I saw no meeting minutes on the mailing list I think everyone else had a holiday as well. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Monday meeting and Italian national holidays
Now that the North has entered Daylight Saving time, should we reconsider the time of Monday meetings? They were originally at 13:00 UTC, but we moved to 13:30 UTC when DST started in the North. Goal: include both Jody (UTC+10) and Justin (UTC-6). DST ending in Sydney and starting in the North moves Justin and Jody two hours closer. :-) Next meeting is 15 April: http://www.timeanddate.com/worldclock/meetingtime.html?iso=20130415; p1=55p2=215p3=196p4=240 I like 13:00 UTC: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013month=4day=15hour=13min=0sec=0p1=55p2=215p3=196p4=240 Kind regards, Ben. On 29/03/13 16:50, Andrea Aime wrote: Hi, Monday we are supposed to have the bi-weekly meeting, however it's national holiday in Italy, so probably italians won't show up. Me, don't know, if I'm at home I might pop up, otherwise not Cheers Andrea -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] geotools-9.x build hung
Someone please kick opengeo hudson as there is a hung build (geotools-9.x): http://hudson.opengeo.org/hudson/job/geotools-9.x/25/ preventing Andrea from discovering that he has broken geoserver-master. :-) https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geoserver-master/1197/ -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] geotools-9.x build hung
Thanks. And geoserver-master just failed, as predicted. :-) On 20/03/13 09:27, Justin Deoliveira wrote: Kicked. On Tue, Mar 19, 2013 at 3:40 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Someone please kick opengeo hudson as there is a hung build (geotools-9.x): http://hudson.opengeo.org/hudson/job/geotools-9.x/25/ preventing Andrea from discovering that he has broken geoserver-master. :-) https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geoserver-master/1197/ -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto: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. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backporting of the SchemaResolver patch to 8.x
The one question mark I have is that, because this patch adds a new dependency, xml-commons-resolver, is it backwards compatible? This might break builds of users who have manually collected dependencies and are not using Maven. Do we support these users? Does a new non-test dependency count as an incompatible change? I am inclined to say no, and vote +1 for the backport, but I would like confirmation from core developers. Kind regards, Ben. On 28/02/13 16:21, Mauro Bartolomeoli wrote: Hi everybody, as 8.7 release is finally out, could this be a good moment to merge SchemaResolver patch to 8.x branch? Just to remember a few things: * this is the branch to merge: https://github.com/mbarto/geotools/tree/8.x_geot_4386 * the patch should be quite safe as it mantains code compatibility for app-schema modules and for GeoServer Any blocker? Could you please vote for this? Thanks, Mauro Bartolomeoli -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GEOT-4386 pull requests ready to go
Mauro, I see you have issued the GeoTools pull request for GEOT-4386: https://github.com/geotools/geotools/pull/135 I have issued the corresponding one for GeoServer (required to not break the build): https://github.com/geoserver/geoserver/pull/152 I would merge both now but I am just about to leave the office and prefer not to merge and run. :-) Justin, Andrea, or anyone else willing to clean up if things go wrong, please feel free to merge these two. Otherwise, I will merge them tomorrow morning (UTC+8). Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PMC: Proposal Replace Contribution Agreement
On 20/02/13 08:26, Frank Warmerdam wrote: Fax is typical for sending legal paperwork, it has a signature and a timestamp of the old school variety. Jody, Blech. I don't see any reason a scanned copy of the document that would have been faxed should not be sufficient to our needs. +1. My organisation relies on scans for legal documentation. We only have one fax left in the building. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Nominate Mauro Bartolomeoli for GeoTools commit access
Mauro Bartolomeoli has been writing some rather useful and thorough GeoTools code, such as the recent AppSchemaResolver promotion and corresponding work on the WMS client. Mauro already has commit access for GeoServer, but it has come to my attention that he is not yet a GeoTools committer. I nominate Mauro Bartolomeoli for GeoTools commit access (and hope that he will accept). Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backporting of the SchemaResolver patch to 8.x and 9.x branches
+1. That is a good idea. Because the added classes have new names and a new package, this change is a pure API extension and localised to GeoTools. This change should wait until after the next beta, and will need support (and perhaps a vote?). Note that 8.x is almost obsolete as 9.0 is in beta and will soon be stable. Would you be happy to put it into 9.x only? Kind regards, Ben. On 19/02/13 18:28, Mauro Bartolomeoli wrote: Hi, I would like to ask opinions for the backporting of the GEOT-4386 patch to 8.x and 9.x branches that has just landed on master. My thought for the backport would be to mantain compatibility with existing code, simply avoiding to remove classes in app-schema-resolver, but letting them extend the corresponding new classes in gt-xml (AppSchemaResolver - SchemaResolver, and so on). Following this approach the impact of the backport should not be dramatic, and also GeoServer should not need to be touched. Do you think this could be done? Thanks Mauro Bartolomeoli -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problems with WMS client contacting an Inspire enabled GeoServer
Mauro, that looks great. Both GeoTools and GeoServer (patched branch) build cleanly. The docs build and look fine. The only question I have is: why is it necessary to synchronise the block where resolvedLocationToOriginalLocationMap.put is called, when this is already a ConcurrentHashMap? (I can see why the containsKey is a good idea.) I am not saying this is wrong, just that I do not yet understand. If you are confident that the concurrency issues are addressed, please go ahead an issue a pull request for master. (And please make sure the GeoServer changes get merged at the same time.) Thanks again! Kind regards, Ben. On 18/02/13 23:43, Mauro Bartolomeoli wrote: Hi all, I tried to solve the remaining issues. Please update the javadocs in gt-app-schema-resolver and the user manual, which still mention the old class names. You should probably move the resolver section in the manual to xml, or wherever you think it makes most sense. for your convenience, I have attached a listing of all mentions of the old class names. I added a new section (resolving) in gt-xml docs, extracting info specific to the 3 classes moved from app-schema-resolver to core (and I removed the same docs from gt-app-schema-resolver). I think you have copied too much of the test resources to gt-xml (and thus too much in review.apt). I think the top-level xml files and the catalog stuff is only used by the tests that are still left in gt-app-schema-resolver. Please remove the duplication; you might then need no review.apt changes at all. Ok, I removed the extra unneeded files. I am not sure about your synchronisation. SchemaResolver maintains resolvedLocationToOriginalLoca__tionMap and I see no reason why you cannot have multiple file resolved locations (e.g. the temporary file created when concurrent downloads occur) for a single HTTP URI; the resolver will fix your relative imports for you (that is its job). I still see no synchronisation on resolvedLocationToOriginalLoca__tionMap; what happens if two threads try to update this map concurrently? (Bad Things Happen.) Can this ever happen? Is a SchemaResolver ever shared between threads? But if not, then how will SchemaCache download synchronisation occur (monitors are on instances)? I wonder if all synchronisation should be handled at a higher level. As this is going into gt-xml, I would like to defer to Justin's considerable expertise in this area. I transformed resolvedLocationToOriginalLoca__tionMap to a ConcurrentHashMap and synchronized updating accesses to it (the download stuff was already synchronized in SchemaCache). The branch is the usual one: https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver Thanks Mauro -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problems with WMS client contacting an Inspire enabled GeoServer
Nice work, Mauro. You are getting closer.
There are still some issues to be addressed.
The good news is that all tests pass (including SchemaCacheOnlineTest,
which requires ~/.geotools/schema-resolver.properties to enable it).
Furthermore, I have made the changes required in GeoServer in a branch;
with these changes all GeoServer tests pass as well:
https://github.com/bencaradocdavies/geoserver/tree/geot-4386
This branch also removes xml-commons-resolver from the app-schema
plugin, as it will now be shipped with the core GeoServer bundle (an
extra 84 kB [don't tell Andrea]).
Please update the javadocs in gt-app-schema-resolver and the user
manual, which still mention the old class names. You should probably
move the resolver section in the manual to xml, or wherever you think it
makes most sense. for your convenience, I have attached a listing of all
mentions of the old class names.
I think you have copied too much of the test resources to gt-xml (and
thus too much in review.apt). I think the top-level xml files and the
catalog stuff is only used by the tests that are still left in
gt-app-schema-resolver. Please remove the duplication; you might then
need no review.apt changes at all.
I am not sure about your synchronisation. SchemaResolver maintains
resolvedLocationToOriginalLocationMap and I see no reason why you cannot
have multiple file resolved locations (e.g. the temporary file created
when concurrent downloads occur) for a single HTTP URI; the resolver
will fix your relative imports for you (that is its job). I still see no
synchronisation on resolvedLocationToOriginalLocationMap; what happens
if two threads try to update this map concurrently? (Bad Things Happen.)
Can this ever happen? Is a SchemaResolver ever shared between threads?
But if not, then how will SchemaCache download synchronisation occur
(monitors are on instances)? I wonder if all synchronisation should be
handled at a higher level. As this is going into gt-xml, I would like to
defer to Justin's considerable expertise in this area.
Justin: there are two things that might require synchronisation:
(1) downloads of files into the cache
(2) updates of SchemaResolver.resolvedLocationToOriginalLocationMap
Can you please advise?
Mauro, if this is only going to be used by a single-threaded client, it
might be simpler to document the SchemaResolver as non-thread-safe until
all resolutions have been performed at least once. A multithreaded
application could maintain a single SchemaResolver and synchronise
access to it (this is what I mean by higher-level synchronisation).
Thanks again.
Kind regards,
Ben.
On 14/02/13 01:08, Mauro Bartolomeoli wrote:
Hi guys, I tried to integrate all your suggestions with a new commit on
this branch:
https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver.
Basically what I did is:
* removed classes migrated to gt-xml (SchemaResolver, SchemaCache and
SchemaCatalog) from app-schema-resolver, introducing a dependency to
gt-xml in the app-schema and gt-complex extension modules
* copied text from app-schema review.apt to gt-xml (maybe I copied too
much, please Ben have a look at the file and tell me if I need to
correct that)
* introduced synchronization in SchemaCache (to avoid usage of
partially downloaded files in cache)
Please, have a look at the new commit and tell me if this is enough for
a pull request.
Thanks
Mauro Bartolomeoli
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
geotools(geot_4386_no_app_schema_resolver)$ find . -regextype posix-egrep
-regex .*\\.(java|rst) -exec grep -H -n -E
AppSchema(Cache|Catalog|Resolver) {} \;
./docs/user/extension/app-schema.rst:164:This module will resolve any resource
type, but it is designed to aid relative imports between XML Schemas; to do
this it keeps a reverse-lookup table to convert resolved locations back to
their original locations, facilitating correct determination of relative
imports and includes. To ensure that this works, use a single instance of
``AppSchemaResolver`` to resolve a schema and all its dependencies.
./docs/user/extension/app-schema.rst:166:Optional ``AppSchemaResolver``
constructors arguments allow configuration of permitted resolution methods.
./docs/user/extension/app-schema.rst:176:AppSchemaResolver resolver = new
AppSchemaResolver(AppSchemaCatalog.build(DataUtilities.fileToURL(new
File(/path/to/catalog.xml;
./docs/user/extension/app-schema.rst:184
[Geotools-devel] [jira] (GEOT-4390) Missing expression in Oracle with app-schema joining
Ben Caradoc-Davies
created GEOT-4390
Missing _expression_ in Oracle with app-schema joining
Issue Type:
Bug
Affects Versions:
8.6
Assignee:
Rini Angreani
Components:
app-schema plugin
Created:
11/Feb/13 8:45 PM
Description:
Report referred to "GeoServer 2.2" so I am guessing a recent 8.x. Not tested against master. Original thread here:
http://osgeo-org.1560.n6.nabble.com/WFS-Performance-Issues-in-GeoTools-with-App-schema-Module-td5032333.html
This report comes further on:
Original Message
Subject: Re: [Geotools-gt2-users] WFS Performance Issues in GeoTools with App-schema Module
Date: Fri, 8 Feb 2013 10:22:30 +0800
From: Mike Beaumont
To: geotools-gt2-us...@lists.sourceforge.net
I don't expect anyone to answer the following in this thread but for the
record, I set
app-schema.joining = true
and the following SQL was generated which led to an Oracle Exception
*ORA-00936: missing _expression_*
due to some of the inner join clauses having empty brackets where the
specified join columns should go.
I'll have to dig deeper into the code and/or config. But it is interesting
that the requests work fine without joining (it's just that it's slow) but
not at all with joining=true.
Here's the SQL:
SELECT
SG_GSML_LITHOLOGY.ID,
SG_GSML_LITHOLOGY.COMPOSITIONPART_ID,
SG_GSML_LITHOLOGY.LITHOLOGY,
SG_GSML_LITHOLOGY.LITHOLOGY_URI,
SG_GSML_LITHOLOGY.LITHOLOGY_URN,
SG_GSML_COMPOSITIONPART.ID FOREIGN_ID_0_0,
SG_GSML_GEOLOGICUNIT.GML_ID FOREIGN_ID_1_0,
SG_GSML_MAPPEDFEATURE_250K.GML_ID FOREIGN_ID_2_0
FROM SG_GSML_LITHOLOGY
INNER JOIN SG_GSML_COMPOSITIONPART ON ( SG_GSML_COMPOSITIONPART.ID =
SG_GSML_LITHOLOGY.COMPOSITIONPART_ID)
INNER JOIN SG_GSML_COMPOSITIONPART SG_GSML_COMPOSITIONP_1 ON ( )
INNER JOIN SG_GSML_GEOLOGICUNIT ON ( SG_GSML_GEOLOGICUNIT.ID =
SG_GSML_COMPOSITIONP_1.GEOGRAPHICFEATURE_ID)
INNER JOIN SG_GSML_GEOLOGICUNIT SG_GSML_GEOLOGICUNIT_1 ON ( )
INNER JOIN SG_GSML_MAPPEDFEATURE_250K ON (
SG_GSML_MAPPEDFEATURE_250K.GEOGRAPHICFEATURE_ID = SG_GSML_GEOLOGICUNIT_1.ID)
INNER JOIN (
SELECT DISTINCT GML_ID FROM SG_GSML_MAPPEDFEATURE_250K
WHERE GML_ID = gsml.mappedfeature.geologicunit.250k-1005 )
temp_alias_used_for_filter
ON ( SG_GSML_MAPPEDFEATURE_250K.GML_ID = TEMP_ALIAS_USED_FOR_FILTER.GML_ID )
ORDER BY
SG_GSML_MAPPEDFEATURE_250K.GML_ID ASC,
SG_GSML_GEOLOGICUNIT.GML_ID ASC,
CASE WHEN SG_GSML_MAPPEDFEATURE_250K.GEOGRAPHICFEATURE_ID =
SG_GSML_GEOLOGICUNIT.ID THEN 0 ELSE 1 END ASC,
SG_GSML_COMPOSITIONPART.ID ASC,
CASE WHEN SG_GSML_GEOLOGICUNIT.ID =
SG_GSML_COMPOSITIONPART.GEOGRAPHICFEATURE_ID THEN 0 ELSE 1 END ASC
Project:
GeoTools
Priority:
Major
Reporter:
Ben Caradoc-Davies
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problems with WMS client contacting an Inspire enabled GeoServer
Mauro, I think your changes are just what we need. Please also update your branch to remove the duplication in gt-app-schema-resolver, so that it contains only those things that depend on gt-xsd-core and so cannot be folded into gt-xml. One other issue is synchronisation: gt-app-schema-resolver has until now only been used in circumstances (GeoServer startup) in which concurrent access is not an issue. What happens if two concurrent threads try to use the resolver? One thread might read a copy on disk while another is still downloading it. Simple synchronisation might result in nasty starvation if a download hangs. Core code must consider these issues and either address them or state that the code is not thread safe. Please also ensure that the relevant attributions are copied to gt-xml: modules/extension/app-schema/app-schema-resolver/src/site/apt/review.apt I also note a new copy of XMLSchema.xsd which will require attribution. As Justin is the maintainer of gt-xml, all changes there will require his approval. There is also an ugly, ugly hack in AppSchemaResolver: if a cache directory is not set, it can be configured to automatically find one if it recognises a *GeoServer* data directory. Ugly, but very useful, and I have not thought of a better way of doing it (a data store parameter, perhaps?). The standard for core is higher than extension; Justin may want this either fixed or factored out into a subclass in gt-app-schema-resolver so that he does not have to maintain any (more) ugly hacks. :-) Justin? Kind regards, Ben. On 11/02/13 21:31, Mauro Bartolomeoli wrote: Hi guys, I created a new branch ( https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver ) that removes app-schema-resolver dependencies, basically porting 3 classes (AppSchemaResolver, AppSchemaCache and AppSchemaCatalog) directly into the gt-xml module. The next step would be to let app-schema-resolver depend on these to remove the duplication. Let me know if we can proceed this way. Thanks. Mauro Bartolomeoli 2013/2/7 Mauro Bartolomeoli mauro.bartolome...@geo-solutions.it mailto:mauro.bartolome...@geo-solutions.it 2013/2/7 Justin Deoliveira jdeol...@opengeo.org mailto:jdeol...@opengeo.org @Mauro: I am not sure it makes sense to have a library module depend on an extension module. Maybe we can shuffle a few things around to make this cleaner. @Ben: What about moving the classes from app-schema-resolver that don't depend on xsd-core, like the core entity resolver classes, to library/xml? I agree with both sentences. I think the app-schema-resolver stuff could be easily become a generic schema-resolver, useful for xml schema resolving and caching in general. Thanks. Mauro Bartolomeoli -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Dott. Mauro Bartolomeoli @mauro_bart Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GeoTools/GeoServer meeting minutes, Feb 4th 2013
On 11/02/13 23:27, christian.muel...@nvoe.at wrote: I think its more important to have Jody/Justin participating (if possible). Soon the eastern states of Australia will leave daylight saving, while North America will enter daylight saving, bringing Justin and Jody two hours closer together. :-) The original meeting was at 13:00 UTC, which would also be easier on Jody, who is now back in Sydney. (Queensland does not have DST.) Should we move the meeting back to 13:00 UTC, which will let Jody go to bed at midnight (before he turns into a pumpkin)? Friday night meetings are no good for me. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problems with WMS client contacting an Inspire enabled GeoServer
Wow, that sounds great, Mauro. Making gt-app-schema-resolver a dependency of gt-xml will require promoting gt-app-schema-resolver to core; this is a large change and will require Justin's approval (as resident xml guru), discussion on the lists, and a change proposal. Are you sure you cannot make the dependency on gt-xsd-core, which is already in extension? Either way, we should be able find a solution that works for you. When you have a github branch that I can try, I would like to build and test GeoServer using it. Kind regards, Ben. On 06/02/13 18:55, Mauro Bartolomeoli wrote: 2013/2/6 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au app-schema uses the app-schema-resolver implementation to obtain schemas from the classpath (jar files), oasis calogs, or cached downloads. It is designed to drive the XML encoder, and solve the problem of cross-module relative imports (import of ../../../whatever) from different sources. It does not use the URIResolver interface. It implements the GeoTools SchemaLocationResolver interface. See: http://docs.geotools.org/__latest/userguide/extension/__app-schema.html#application-__schema-resolver http://docs.geotools.org/latest/userguide/extension/app-schema.html#application-schema-resolver I would have to think more about what youse are trying to do, but app-schema-resolver has no dependencies on app-schema and could be the basis of a solution. Ok, I did some tests, and good news, app-schema-resolver seems the way to go. My idea now is to: - add a dependency in gt-xml to gt-app-schema-resolver (a little bit weird since gt-xml is core, and app-schema-resolver an extension, maybe AppSchemaResolver should find a better home in a core module in the near future) - update org.geotools.xml.schema.SchemaFactory to use AppSchemaResolver with classpath resolving and AppSchemaCache fallback with automatic download - configure AppSchemaCache to use a folder found in schema.factory.cache (this allows to create xsd caches on geoserver data_dir for example) system property, if defined, or a temporary folder if not - as a side effect xsd already available in geotools jars (such as gt-xsd-core) will be immediately available to SchemaFactory locally (included the one that was slowing down WMS cascading with inspire) I did some test on master and everything seems to work like a charm. Can I proceed with the pull request? Thanks. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problems with WMS client contacting an Inspire enabled GeoServer
app-schema uses the app-schema-resolver implementation to obtain schemas from the classpath (jar files), oasis calogs, or cached downloads. It is designed to drive the XML encoder, and solve the problem of cross-module relative imports (import of ../../../whatever) from different sources. It does not use the URIResolver interface. It implements the GeoTools SchemaLocationResolver interface. See: http://docs.geotools.org/latest/userguide/extension/app-schema.html#application-schema-resolver I would have to think more about what youse are trying to do, but app-schema-resolver has no dependencies on app-schema and could be the basis of a solution. Kind regards, Ben. On 05/02/13 23:20, Justin Deoliveira wrote: I wonder if a third alternative would be to utilize the URIResolver apis already present in the jdk. If I am not mistaken the app-schema folks use this to solive this same problem. Maybe Ben or Rini can comment on that. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal Replace Contribution Agreement
What is the impact on existing contributors? Will we need to submit new agreements? This new agreement also appears to introduce a maintenance overhead in that corporate entities seem to have to designate authorised employees who are able to contribute. In my organisation, the exercise of this authority will have to occur at the same level as the initial agreement and may introduce a delay between a developer starting and being authorised to make contributions. Furthermore, not all contributions from a corporation are by employees. My team includes developers employed by other entities under contracts that assign all intellectual property to my organisation, which then in turn assigns rights to OSGeo. I am not sure how this situation is accommodated by this agreement. Kind regards, Ben. On 03/02/13 08:53, Jody Garnett wrote: Proposal is up: http://docs.codehaus.org/display/GEOTOOLS/Replace+Contribution+Agreement I had a couple questions in the tasks section which may be worth discussion. -- Jody Garnett -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal Replace Contribution Agreement
I added these in a new discussion section. On 04/02/13 19:03, Jody Garnett wrote: Can you make a note of these two questions on the proposal page. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal Replace Contribution Agreement
That is interesting, Jody. I am not opposed to formalising the role of representatives, just observing that we have not done so thus far. It might well be a good idea. Perhaps we can broaden the language to representative (but this has legal connotations), or even just person, together with capturing their relationship with the rights owner? Kind regards, Ben. On 05/02/13 11:13, Jody Garnett wrote: Thanks Ben, for reference I have been going through the eclipse stuff and … a) It also demands employers sign for each representative they have in the mix b) It is very clear (when you sign up) that you can reference an employer, or the organisations you are doing the work for as a contractor -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] removing xerces dependency
Thanks, Justin. My patch was not expected to fix the SecondaryNamespaceExceptionTest failure. I recall that SecondaryNamespaceExceptionTest tests that an exception is thrown if secondary namespaces are not defined (null). Once the external xerces 2.7 is removed (in favour of the internal xerces 2.6), the null namespace prefixes are simply passed through, resulting in an invalid response. The test failure alerts us to the change. I think this test was originally written by Victor. Rini is the app-schema component lead and should be able to determine whether this new behaviour is aceptable. Kind regards, Ben. On 30/01/13 12:02, Justin Deoliveira wrote: Hey Ben, So I rebased the xmlnodeps branch against the latest on master and i am still having the same failure with the SecondaryNamespaceExceptionTest. I pushed up newly rebased branches to my repos. https://github.com/jdeolive/geoserver/tree/noxmldeps2 https://github.com/jdeolive/geotools/tree/noxmldeps2 -Justin On Tue, Jan 22, 2013 at 7:12 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Thanks, Justin. The gt-app-schema-resolver Xerces dependency you found is resolved in the pull request linked below. This patch is against your noxmldeps branch; everything works when it is applied, except that xmlcodegen does not build (I commented it out while testing), and one unit test failure in GeoServer app-schema-test, which you should be able to reproduce when you build GeoServer against your noxmldeps branch. See: https://github.com/jdeolive/__geotools/pull/1 https://github.com/jdeolive/geotools/pull/1 I removed the GeoServer app-schema Xalan dependency late last year: https://jira.codehaus.org/__browse/GEOS-5352 https://jira.codehaus.org/browse/GEOS-5352 https://github.com/geoserver/__geoserver/pull/54 https://github.com/geoserver/geoserver/pull/54 Kind regards, Ben. On 22/01/13 22:57, Justin Deoliveira wrote: Hey Ben, Wasn't waiting explicitly, this sort of just fell off in light of other things to do. I will try this week to resurrect this. As I understand it the app-schema issues have been resolved now? -Justin On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:Ben.Caradoc-Davies@__csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Justin, at Monday's meeting we were wondering if you have had time to progress the removal of (external) Xerces dependencies. My understanding is that you were pretty close. Or are you waiting until after this release cycle? Kind regards, Ben. On 02/11/12 15:43, Ben Caradoc-Davies wrote: Justin, I ported AppSchemaValidator to use EntityResolver2, required for relative schema locations: https://github.com/jdeolive/geotools/pull/1 https://github.com/jdeolive/__geotools/pull/1 https://github.com/jdeolive/__geotools/pull/1 https://github.com/jdeolive/geotools/pull/1 Note that xmlcodegen still fails to build (I commented it out for testing). With noxmldeps GeoTools, there is a unit test failure in GeoServer (app-schema-test SecondaryNamespaceExceptionTest). Looks like a side effect of your dexercesification is that undefined namespace prefixes (null:) are now passed through the GML32OutputFormat XSLT rather that causing an ows:ExceptionReport. Not sure why. I also needed to remove the xerces dependencies in the release module. Nice work! You are pretty close. Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)? https://jira.codehaus.org/browse/GEOS-5352 https://jira.codehaus.org/__browse/GEOS-5352 https://jira.codehaus.org/__browse/GEOS-5352 https://jira.codehaus.org/browse/GEOS-5352 Kind regards, Ben. On 23/10/12 08:29, Justin Deoliveira wrote: Hi all, So I recently I took a crack at removing the xerces dependency as we discussed in our last skype meeting. For the most part this was relatively straight forward. Unfortunately one thing i wasn't
Re: [Geotools-devel] removing xerces dependency
Thanks, Justin. The gt-app-schema-resolver Xerces dependency you found is resolved in the pull request linked below. This patch is against your noxmldeps branch; everything works when it is applied, except that xmlcodegen does not build (I commented it out while testing), and one unit test failure in GeoServer app-schema-test, which you should be able to reproduce when you build GeoServer against your noxmldeps branch. See: https://github.com/jdeolive/geotools/pull/1 I removed the GeoServer app-schema Xalan dependency late last year: https://jira.codehaus.org/browse/GEOS-5352 https://github.com/geoserver/geoserver/pull/54 Kind regards, Ben. On 22/01/13 22:57, Justin Deoliveira wrote: Hey Ben, Wasn't waiting explicitly, this sort of just fell off in light of other things to do. I will try this week to resurrect this. As I understand it the app-schema issues have been resolved now? -Justin On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Justin, at Monday's meeting we were wondering if you have had time to progress the removal of (external) Xerces dependencies. My understanding is that you were pretty close. Or are you waiting until after this release cycle? Kind regards, Ben. On 02/11/12 15:43, Ben Caradoc-Davies wrote: Justin, I ported AppSchemaValidator to use EntityResolver2, required for relative schema locations: https://github.com/jdeolive/__geotools/pull/1 https://github.com/jdeolive/geotools/pull/1 Note that xmlcodegen still fails to build (I commented it out for testing). With noxmldeps GeoTools, there is a unit test failure in GeoServer (app-schema-test SecondaryNamespaceExceptionTes__t). Looks like a side effect of your dexercesification is that undefined namespace prefixes (null:) are now passed through the GML32OutputFormat XSLT rather that causing an ows:ExceptionReport. Not sure why. I also needed to remove the xerces dependencies in the release module. Nice work! You are pretty close. Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)? https://jira.codehaus.org/__browse/GEOS-5352 https://jira.codehaus.org/browse/GEOS-5352 Kind regards, Ben. On 23/10/12 08:29, Justin Deoliveira wrote: Hi all, So I recently I took a crack at removing the xerces dependency as we discussed in our last skype meeting. For the most part this was relatively straight forward. Unfortunately one thing i wasn't quite able to figure out was some stuff in app-schema-resolver module. The AppSchemaValidator class uses an implementation of what was XMLEntityResolver directly in xerces. I tried porting this to the jaxp EntityResolver interface which is included in the JDK, but couldn't make it work. So I think i will need some help there. Or we can simply keep xerces as a dependency of just app-schema. Here is the branch I am currently working on. https://github.com/jdeolive/__geotools/tree/noxmldeps https://github.com/jdeolive/geotools/tree/noxmldeps And the corresponding geoserver branch: https://github.com/jdeolive/__geoserver/tree/noxmldeps https://github.com/jdeolive/geoserver/tree/noxmldeps WIth these changes all unit tests pass in both code bases, and so do the GeoServer cite tests. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ GeoTools-Devel mailing list GeoTools-Devel
Re: [Geotools-devel] removing xerces dependency
Justin, at Monday's meeting we were wondering if you have had time to progress the removal of (external) Xerces dependencies. My understanding is that you were pretty close. Or are you waiting until after this release cycle? Kind regards, Ben. On 02/11/12 15:43, Ben Caradoc-Davies wrote: Justin, I ported AppSchemaValidator to use EntityResolver2, required for relative schema locations: https://github.com/jdeolive/geotools/pull/1 Note that xmlcodegen still fails to build (I commented it out for testing). With noxmldeps GeoTools, there is a unit test failure in GeoServer (app-schema-test SecondaryNamespaceExceptionTest). Looks like a side effect of your dexercesification is that undefined namespace prefixes (null:) are now passed through the GML32OutputFormat XSLT rather that causing an ows:ExceptionReport. Not sure why. I also needed to remove the xerces dependencies in the release module. Nice work! You are pretty close. Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)? https://jira.codehaus.org/browse/GEOS-5352 Kind regards, Ben. On 23/10/12 08:29, Justin Deoliveira wrote: Hi all, So I recently I took a crack at removing the xerces dependency as we discussed in our last skype meeting. For the most part this was relatively straight forward. Unfortunately one thing i wasn't quite able to figure out was some stuff in app-schema-resolver module. The AppSchemaValidator class uses an implementation of what was XMLEntityResolver directly in xerces. I tried porting this to the jaxp EntityResolver interface which is included in the JDK, but couldn't make it work. So I think i will need some help there. Or we can simply keep xerces as a dependency of just app-schema. Here is the branch I am currently working on. https://github.com/jdeolive/geotools/tree/noxmldeps And the corresponding geoserver branch: https://github.com/jdeolive/geoserver/tree/noxmldeps WIth these changes all unit tests pass in both code bases, and so do the GeoServer cite tests. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 07/01/13 22:31, Niels Charlier wrote: I think the reason might be that because of the existence of the app-schema-test package in geoserver there has been traditionally less test coverage in the gt-app-schema package itself, but now it becomes clear that some basic complex feature classes do need to be tested on their own behaviour. +1. gt-app-schema also lacks encoding test coverage, which is largely (and very heavily) provided by GeoServer app-schema-test. The latter has grown (*cough*) sophisticated test fixtures. (Giant integration tests rather than unit tests.) The original reason why all the encoding tests were in GeoServer-land was an XML Configuration dependency problem. If I recall correctly (and it was a long time ago), there was at least one essential Configuration (WFS?) needed for encoding full responses that was present or had a dependency only present in GeoServer. I remember noticing years later that this situation no longer exists. Refactoring would be welcome. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] How to compile a Java program containing geotools
David, this is a general Java development question, not specific to GeoTools. There are many ways to create something runnable. The basic problem is that you need to package your .class files into a runnable .jar file, and also ensure that all dependencies are available at runtime on the classpath. You also need a JRE (your JDK comes with one, other users will need one). In Eclipse you should be able to File/Export/Java/Runnable JAR file and bundle all your dependencies into the JAR. http://www.google.com/search?q=eclipse+runnable+jar+file+tutorial This is crude and unsuitable for real applications because it makes it hard to manage dependencies (and comply with the LGPL), but might be suitable for experimentation. For real applications, there are open source installers that bundle your runnable JAR, its dependencies, scripts, and even a JRE. I have used izPack (but that was years ago). There are others: http://stackoverflow.com/questions/184060/java-application-installers http://www.google.com/search?q=java+application+installer JEE servlets have their own deployment technology: WAR files; These can be generated by Maven and Eclipse. Other platforms like Eclipse RCP have their own patterns. Kind regards, Ben. On 19/12/12 20:28, David Shi wrote: Hi, Ben, Thank you very much for your suggestions. It is a new program with a mixture of external Jars, including Geotools. It runs in Eclipse. But, it fails when an executable is to be compiled. I need to find Step by Step guides on how to create an executable or Jar. The information on the Internet is very confusing. Which application should I use to create my first executable easily? Regards. David *From:* Ben Caradoc-Davies ben.caradoc-dav...@csiro.au *To:* David Shi davidg...@yahoo.co.uk *Cc:* geotools-devel@lists.sourceforge.net geotools-devel@lists.sourceforge.net *Sent:* Wednesday, 19 December 2012, 2:15 *Subject:* Re: [Geotools-devel] How to compile a Java program containing geotools Is this someone else's program or are you writing a new one? There are many build systems, including make, ant, maven, and sbt, all of which can be used to build programs containing GeoTools. If you are writing a new program from scratch, tools like maven that can use maven repositories will help you automatically get the GeoTools dependencies that you need. Kind regards, Ben. On 18/12/12 20:05, David Shi wrote: Hi, Can anyone give me the step by step guide to compile a Java program containing geotools? Regards. David -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] How to compile a Java program containing geotools
Is this someone else's program or are you writing a new one? There are many build systems, including make, ant, maven, and sbt, all of which can be used to build programs containing GeoTools. If you are writing a new program from scratch, tools like maven that can use maven repositories will help you automatically get the GeoTools dependencies that you need. Kind regards, Ben. On 18/12/12 20:05, David Shi wrote: Hi, Can anyone give me the step by step guide to compile a Java program containing geotools? Regards. David -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4354) Improving BandSelect selection of ColorModel
Ben Caradoc-Davies reopened GEOT-4354 Improving BandSelect selection of ColorModel Reverted in 7dfd0fd833a81d419676eae19a31be7c18dc2842 on master to fix the build. Change By: Ben Caradoc-Davies (18/Dec/12 8:57 PM) Status: Resolved Reopened Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Hudson] Build failed in Hudson: geotools-master #4665
On 19/12/12 07:24, Hudson wrote: [Simone Giannecchini] fix for GEOT-4354 Simone, I have reverted this in 7dfd0fd833a81d419676eae19a31be7c18dc2842 on master to fix the build. DefaultProcessor is still used in gt-process. Although this is an unsupported module, it is included in -Dall builds such as geotools-master on OpenGeo Hudson. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Pushing GeoGit module out of the build?
Andrea, tl;dr: please go ahead I do not understand why geogit-versioned is still in your build (unless you are building with -Pgeogit-versioned). I build with -Dall and geogit-versioned is not built for me (on master). According to the git logs, Mark kicked geogit-versioned out of the -Dall build on 12 September, in commit 5807cf7a7ba78cf828b8f7c63b7b90d7307e66d4. Are you on a branch? At the very least, this discussion from November approves the removal of geogit-versioned (Gabriel asked, Jody approved): http://osgeo-org.1560.n6.nabble.com/remove-unsupported-geogit-versioned-module-td5018216.html If you remove the module, please also remove the geogit-core dependency from the top-level pom. As an aside, this exemplifies a principle: unsupported modules cannot block necessary changes to supported modules and are kicked out of the build if nobody cares enough to keep them building. Kind regards, Ben. On 17/12/12 16:49, Andrea Aime wrote: Hi, the geogit module tests are currently blocking the improvement contained in https://jira.codehaus.org/browse/GEOT-4351 Given that an intention to remove the module from GeoTools has already been expressed, and that we cannot get a feedback from the people involved in GeoGit, I'd say we just kick the module out of the -Dall build for now? I guess if they moved the store in the GeoGit this will just result in breaking their build... but if it's the only way to get their attention, well, so be it? My 2 cents. Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: Pushing GeoGit module out of the build?
Oh, I see, the original problem applying the patch was back in January, before geogit-versioned was removed from the -Dall profile. http://jira.codehaus.org/browse/GEOT-3986 On 17/12/12 17:32, Ben Caradoc-Davies wrote: I do not understand why geogit-versioned is still in your build (unless you are building with -Pgeogit-versioned). I build with -Dall and geogit-versioned is not built for me (on master). According to the git logs, Mark kicked geogit-versioned out of the -Dall build on 12 September, in commit 5807cf7a7ba78cf828b8f7c63b7b90d7307e66d4. Are you on a branch? -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Pushing GeoGit module out of the build?
On 17/12/12 17:50, Andrea Aime wrote: Regardless, the store seems to be in their repo so this change would likely end up breaking their build. Ah! They are downstream and consuming GeoTools master artifacts whose behaviour you are about to change? This is master, where behaviour and APIs change. You are quite considerate notifying them of your intentions, but I do not think this change should be delayed of possible problems (which will be detected by their CI). If this were stable, you would have a problem, but for most users this is a significant improvement and the type of change expected on master. Now I see that a bunch of stuff added by Niels is modified by these patches. You are not going to break app-schema in GeoTools or GeoServer, are you? :-) -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 17/12/12 18:58, Niels Charlier wrote: Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? That depends what you mean by proceed: +1 is for the overarching API change proposal (which classes are in which modules). In my view, you should also seek approval from module maintainers for the final version before it is committed; this is likely to be quick as the main points of contention have been discussed. You can submit patches or github pull requests, which are also becoming popular. Thanks for progressing this work, Niels. It is a much-needed improvement. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Pushing GeoGit module out of the build?
Thanks, Gabriel. I see you have removed geogit-versioned (and the dependency in the top-level pom). I do not think it was a problem since Mark disabled it in September, but it is clearer to have one copy. Kind regards, Ben. On 17/12/12 22:50, Gabriel Roldan wrote: I'm currently waiting for the build to finish on my machine before pushing the removal of the module altogether. Just for the sake of clarity, I ( as part of the geogit team) did never support that module on the geotools codebase. It was Lisasoft's call to get it in and I made it very clear at the time that I did not have the time to support it on the geotools codebase. Then I suggested it was_moved_ to the geogit codebase so it doesn't bother on the geotools codebase. It was copied over but never removed, hence my latest proposal to remove it was just me volunteering in the best interest of geotools once I was told Lisasoft called itself out of the game, as I have nor had no mandate to do anything with that module. So please go ahead with whatever improvement needs to be done on geotools and be sure the geogit team will keep on adapting to them on its own codebase and contributing back whenever necessary. Cheers, Gabriel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Niels, that is a very good point. Andrea, there is a bunch of XSD stuff like substitution groups that are not represented in GeoAPI. It makes it quite tricky to break this dependency. Niels knows because he implemented a lot of it. As future work, we could look at refactoring the way XSD information is handled in complex types. Perhaps we would be better off moving towards that goal one step at a time? Andrea, would it be OK to accept the dependencies listed by Niels? They will not prevent non-XML uses. Future refactoring could make this optional, and client code could (for example) inject an XML provider. I do not know if Niels is in a position to implement such a large refactoring at this time. Kind regards, Ben. On 13/12/12 18:32, Niels Charlier wrote: The XPath processor takes XSD information out of the user data in order to evaluate xml @attributes. That is why it is dependant on it. On 12/13/2012 08:09 AM, Andrea Aime wrote: On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: Well apart from the feature type parser, there is another important part in the module that relies on xsd stuff, i.e. the xpath property accessor. This I think is a very important part of complex features; without this you can't have filters on complex features. An xpath processor is built into the jdk, there is no need to depend on gt-xsd and friends to have it, e.g.: http://xml.apache.org/xalan-j/xpath_apis.html Even if that requires some external library, it's hard to believe it requires an entire xml parsing/encoding subsystem. Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
It would be good if users could build and manipulate complex types and features without ever touching XML or needing an XML dependency. For example, they could build types and features programatically. Other output formats include JSON; complex relationships can be represented in JSON-LD. On 12/12/12 17:30, Andrea Aime wrote: Scratch scratch, could you clarify what dependencies would one end up having in the classpath in order to use gt-complex? -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
+1. This change is long overdue and much needed. I have asked Rini and Adam to review the proposal. gt-app-schema changes should go for review to Rini as component lead. Kind regards, Ben. On 11/12/12 19:15, Niels Charlier wrote: The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Kind Regards Niels Charlier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
We could even say software as well. Should we drop Java? There might be Python, Javascript, and Scala bits, and more in the future. The Java bit is descriptive, but not definitive. We could go crazy and rewrite it in another language, like a future version of Java (I think you know who I am talking about). :-P GeoTools open source geospatial software toolkit, perhaps? Framework is a bit too generic in my opinion. I think we need to include the word software to make it clear that we are not talking about a physical thing, which I think, from my reading of Frank's email, is Google's concern. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
On 12/12/12 10:59, Michael Bedward wrote: I read their concern as being that the current wording was so open it was asking them to sign up to an undefined and possibly moving target. Probably any of software or toolkit or framework or library and utilities etc. would be an improvement. I wouldn't drop Java from the description. I like the JTS model: a reference implementation in Java with ports to other languages managed as separate projects. Seems more agile :) If we kept the Java part, would patent grants extend to other languages? -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
On 10/12/12 15:57, Andrea Aime wrote: On Mon, Dec 10, 2012 at 8:07 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: the build is fixed. But... is it for good? Some of the tests that were failing are simply marked @Ignore now? Oh, I see, I didn't notice that Jody changed @Test to @Ignore for GeographicTransformPointTest.testToGeographicGeometry. I just reverted that commit locally and the gt-render build still passes for filesystem, alphabetical, and reversealphabetical runOrder. I have pushed to master. I did not see any other disabled tests. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
On 10/12/12 16:19, Andrea Aime wrote: Was not the only one in that class, just reverted another back to @Test and pushed. Builds fine locally, let's see the build servers. Builds fine for me, with all three runOrders. Well spotted. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] help: build works locally / fails on hudson
Jody, the build is passing for me locally and in Jenkins. Might be test order (platform) dependent. What happens if you run just that test with this in the root of gt-render? mvn -o -Dtest=GeographicTransformPointTest test Kind regards, Ben. On 10/12/12 11:59, Jody Garnett wrote: Okay I am having a bad go at this - after working hard on a patch, asking Andrea for review, getting the clear instructions not to break the build and committing over the weekend .. the build is now broken. Trouble is it works locally, and I am stuck committing, hitting go on hudson, and trying to hunt down test failures remotely. This is the second time this has happened (the last was with WMS tests) - in both cases the issues revolve around testing ReferenceEnvelope with different Axis Orders. So is this a problem with: a) my development environment? I am following the set up instructions … b) the build boxes? Unlikely, but perhaps they are going multi-threaded on me, or have more horse power and thus can show some problems I cannot see locally. c) The referencing module vs JUnit vs Maven 3 vs Maven 2? Andrea I apologise for breaking the build, I feel I wrecked your evening (and now this has wrecked my day as well). I would like to sort out what is making these tests unstable as it is driving me nuts. Q: Can anyone reproduce a build failure locally? Are you on linux / windows / mac ? Q: Can anyone see something different in the following setup? Hudson shows: - Maven 3.0.4 - java-6-sun-i586 - mvn -U clean install -Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall -Djava.io.tmpdir=/usr/share/jetty/tmp Locally: Apache Maven 3.0.4 (r1232337; 2012-01-17 18:44:56+1000) Maven home: /usr/local/Cellar/maven/3.0.4/libexec Java version: 1.6.0_33, vendor: Apple Inc. Java home: /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.8.2, arch: x86_64, family: mac So that looks broadly the same, I build with: mvn clean install -Dall before each commit -- Jody Garnett -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody, I can make this test fail by adding runOrderreversealphabetical/runOrder to the top-level pom surefire config. I then get: Failed tests: testBounds(org.geotools.renderer.lite.GeographicTransformPointTest): expected:0.665264316713612 but was:NaN Looks like test state is leaking. Axis order settings? Some naughty code caches CRSes. Kind regards, Ben. On 10/12/12 12:34, Ben Caradoc-Davies wrote: Jody, the build is passing for me locally and in Jenkins. Might be test order (platform) dependent. What happens if you run just that test with this in the root of gt-render? mvn -o -Dtest=GeographicTransformPointTest test Kind regards, Ben. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody, with runOrderreversealphabetical/runOrder in the top-level pom, I brute forced all preceding tests paired with with GeographicTransformPointTest. Either of SpatialFilterTest or RenderingTransformationTest causes the failure. That is, with runOrderreversealphabetical/runOrder, both of these fail in GeographicTransformPointTest: mvn -o -Dtest=SpatialFilterTest,GeographicTransformPointTest test mvn -o -Dtest=RenderingTransformationTest,GeographicTransformPointTest test Both tests mess with axis order hints. Kind regards, Ben. On 10/12/12 12:45, Ben Caradoc-Davies wrote: Jody, I can make this test fail by adding runOrderreversealphabetical/runOrder to the top-level pom surefire config. I then get: Failed tests: testBounds(org.geotools.renderer.lite.GeographicTransformPointTest): expected:0.665264316713612 but was:NaN Looks like test state is leaking. Axis order settings? Some naughty code caches CRSes. Kind regards, Ben. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] help: build works locally / fails on hudson
Jody, I think the working directory is a red herring. The problem is the axis order hints in the test fixtures. It is likely something is caching a CRS built with the wrong hints. On 10/12/12 13:22, Jody wrote: Thanks guys - I am going to look at defining using WKT for definition rather than EPSG code so at least these tests can pass. We may need to say straight up what axis order CRS has been configured with as part of our testing guidelines. -- Jody Sent with Sparrow http://www.sparrowmailapp.com/?sig On Monday, 10 December 2012 at 2:43 PM, Benjamin Trigona-Harany wrote: On December 10, 2012 13:59:43 Jody Garnett wrote: b) the build boxes? Unlikely, but perhaps they are going multi-threaded on me, or have more horse power and thus can show some problems I cannot see locally. I've just cleared out Hudson's working directory for geotools-master in the event that there was something stale there causing the build to fail. -- Benjamin Trigona-Harany OpenGeo - http://opengeo.org Enterprise support for open source geospatial -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody,
the attached fix plugs two hint leaks and makes the build pass with
alphabetical, reversealphabetical, and (my) filesystem order.
I am ready to commit now. I will contact you first to ensure you do not
have an alternative fix.
Kind regards,
Ben.
On 10/12/12 13:26, Ben Caradoc-Davies wrote:
Jody, I think the working directory is a red herring. The problem is the
axis order hints in the test fixtures. It is likely something is caching
a CRS built with the wrong hints.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
diff --git a/modules/library/render/src/test/java/org/geotools/renderer/lite/RenderingTransformationTest.java b/modules/library/render/src/test/java/org/geotools/renderer/lite/RenderingTransformationTest.java
index 8c3415c..7da39b4 100644
--- a/modules/library/render/src/test/java/org/geotools/renderer/lite/RenderingTransformationTest.java
+++ b/modules/library/render/src/test/java/org/geotools/renderer/lite/RenderingTransformationTest.java
@@ -1,6 +1,6 @@
package org.geotools.renderer.lite;
-import static org.junit.Assert.*;
+import static org.junit.Assert.assertEquals;
import java.awt.Color;
import java.awt.image.BufferedImage;
@@ -16,6 +16,7 @@ import org.geotools.data.FeatureSource;
import org.geotools.data.Query;
import org.geotools.data.property.PropertyDataStore;
import org.geotools.factory.GeoTools;
+import org.geotools.factory.Hints;
import org.geotools.filter.text.cql2.CQL;
import org.geotools.filter.text.cql2.CQLException;
import org.geotools.gce.geotiff.GeoTiffReader;
@@ -27,6 +28,7 @@ import org.geotools.map.MapContent;
import org.geotools.referencing.CRS;
import org.geotools.renderer.RenderListener;
import org.geotools.styling.Style;
+import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.opengis.feature.simple.SimpleFeature;
@@ -44,6 +46,11 @@ public class RenderingTransformationTest {
CRS.reset(all);
}
+@After
+public void tearDown() {
+Hints.removeSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER);
+}
+
@Test
public void testTransformReprojectedGridReader() throws Exception {
Style style = RendererBaseTest.loadStyle(this, coverageCenter.sld);
diff --git a/modules/library/render/src/test/java/org/geotools/renderer/lite/SpatialFilterTest.java b/modules/library/render/src/test/java/org/geotools/renderer/lite/SpatialFilterTest.java
index c82b997..a435dbd 100644
--- a/modules/library/render/src/test/java/org/geotools/renderer/lite/SpatialFilterTest.java
+++ b/modules/library/render/src/test/java/org/geotools/renderer/lite/SpatialFilterTest.java
@@ -104,7 +104,7 @@ public class SpatialFilterTest {
@After
public void tearDown() {
-Hints.putSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.FALSE);
+Hints.removeSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER);
}
@Test
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody, I was not able to contact you. I have committed 2089d98fb823f8f9ebc5a52d7bb55b72e7d9a1a5 on master. Kind regards, Ben. On 10/12/12 14:21, Ben Caradoc-Davies wrote: Jody, the attached fix plugs two hint leaks and makes the build pass with alphabetical, reversealphabetical, and (my) filesystem order. I am ready to commit now. I will contact you first to ensure you do not have an alternative fix. Kind regards, Ben. On 10/12/12 13:26, Ben Caradoc-Davies wrote: Jody, I think the working directory is a red herring. The problem is the axis order hints in the test fixtures. It is likely something is caching a CRS built with the wrong hints. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody, the gt-render build is fixed on Hudson. (The rest is still running.) Kind regards, Ben. On 10/12/12 14:31, Ben Caradoc-Davies wrote: Jody, I was not able to contact you. I have committed 2089d98fb823f8f9ebc5a52d7bb55b72e7d9a1a5 on master. Kind regards, Ben. On 10/12/12 14:21, Ben Caradoc-Davies wrote: Jody, the attached fix plugs two hint leaks and makes the build pass with alphabetical, reversealphabetical, and (my) filesystem order. I am ready to commit now. I will contact you first to ensure you do not have an alternative fix. Kind regards, Ben. On 10/12/12 13:26, Ben Caradoc-Davies wrote: Jody, I think the working directory is a red herring. The problem is the axis order hints in the test fixtures. It is likely something is caching a CRS built with the wrong hints. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] Re: help: build works locally / fails on hudson
Jody, the build is fixed. The solution was similar to one I applied to gt-epsg-hsql in June: https://jira.codehaus.org/browse/GEOT-4174 Kind regards, Ben. On 10/12/12 14:39, Ben Caradoc-Davies wrote: Jody, the gt-render build is fixed on Hudson. (The rest is still running.) Kind regards, Ben. On 10/12/12 14:31, Ben Caradoc-Davies wrote: Jody, I was not able to contact you. I have committed 2089d98fb823f8f9ebc5a52d7bb55b72e7d9a1a5 on master. Kind regards, Ben. On 10/12/12 14:21, Ben Caradoc-Davies wrote: Jody, the attached fix plugs two hint leaks and makes the build pass with alphabetical, reversealphabetical, and (my) filesystem order. I am ready to commit now. I will contact you first to ensure you do not have an alternative fix. Kind regards, Ben. On 10/12/12 13:26, Ben Caradoc-Davies wrote: Jody, I think the working directory is a red herring. The problem is the axis order hints in the test fixtures. It is likely something is caching a CRS built with the wrong hints. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] making proposal app-schema / complex feature split
Niels, I favour option 3 (new module gt-complex) because it does different things to gt-app-schema-resolver, which builds no features or types, has no dependency on gt-app-schema, and concerns itself with finding and caching XSD documents and making them available to the gt-xsd-core Configuration API. Kind regards, Ben. On 07/12/12 22:24, Niels Charlier wrote: I am working on this proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema The idea is to split app-schema stuff (as discussed earlier) in to general complex feature stuff and specific app-schema stuff But I need to decide on a final decision for what to do with the complex feature stuff. There are four possible destinations suggestions: * become part of gt-main * become part of gt-data * become new module gt-complex * merge with gt-app-schema-resolver in to gt-complex Note that the two options have as a side effect that gt-main/gt-data becomes dependent on gt-app-schema-resolver and everything it depends on, which might be undesired! My preference goes to option 4. Kind Regards Niels -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GML and XLink changes causing grief in WCS 2.0 validation
On 04/12/12 23:41, Andrea Aime wrote: However, all the schemas in the main gml 3.2 are also different in some way, thought I've not verified to what extent) When Justin created the original GML 3.2.1 bindings, he modified or removed several types in xsd files to break cyclic type definitions that were then not handled by xmlcodegen. When I changed xmlcodegen to support cyclic definitions, I reverted most of the workarounds Justin implemented. The only changes that are still necessary are the paths in import and include statements because the directory layout used by Justin does not match that used by OGC (for sensible java packaging reasons). This should be transparent to users of the Configuration. The information model should be almost identical. I also added a copy of the old xlinks schema to satisfy dependencies: geotools/modules/extension/xsd/xsd-gml3/src/main/resources/org/geotools/gml3/v3_2/xlinks.xsd app-schema has been widely tested in production with the GML 3.2.1 bindings (WaterML, SWE, OM2, ...). There are a couple of types where the Java bindings are incomplete, but in general support is pretty good. What makes you think your pain is caused by the XLink changes? I agree that this is a plausible cause, but I wonder, what are the symptoms? Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposing Davide Savazzi for commit rights
+1. Welcome, Davide. On 28/11/12 21:20, Andrea Aime wrote: Hi, Davide (cc'ed) has been making a number of pull requests lately with good quality and tests (contentFeatureCollection.isEmpty optimization, dpi rescale visitors, wfs store, filter splitters bugs, referencing build fix, and he's now working on a SDONN function wrapper for Oracle) Davide did a google summer of code with uDig working on neo4j, already got commit rights on GeoServer, and I'm now proposing him for commit rights on Geotools. Opinions? Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] feature collection cleanup is a go
Thanks a lot, Jody, this has been a huge effort. boratGreat success!/borat http://www.youtube.com/watch?v=J88-RdWnNT0 I just fixed a test compile failure in gt-webservice (unsupported; we build it on our Jenkins), replacing a size method with DataUtilities.count . Yes, *another* size method, who would have thought? :-) This cleanup was made much easier by your excellent documentation. I am so pleased with it that I am linking to it here for all to see: http://geotoolsnews.blogspot.com.au/2012/11/featurecollection-cleanup.html http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+cleanup You made some mention in confluence and git commit logs of the unsafe use of use utility classes in app-schema (simple feature assumptions?). I see your in-code comments. Please direct us to remaining areas of concern and we will at the least get them into Jira. Thanks also for your improvements to dodgy size implementations in app-schema tests. Some of these classes go back to 2007 or earlier and need some attention. Kind regards. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] OpenJDK 7 build server up and running
On 18/11/12 22:20, Andrea Aime wrote: The OpenJDK7 will be useful instead for catching misuse of Treeset and for tests that have execution order dependencies (that is, the work if you run methodA, methodB, methodC, but fail if you run methodB, methodC, methodA) Great work, Andrea, much appreciated. For extra credit, surefire:test also has the runOrder flag for running tests in alternating forward and reverse order or random order, and forkMode+threadCount for multithreaded testing to break weak code. Because these flags make builds even more unstable, they are not always a appropriate, but might be interesting for *-extra-builds. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On 14/11/12 21:35, Niels Charlier wrote: App-schema-resolver is a bit of a misnomer because it also contains stuff that can be used independently of app-schema. Well, app-schema-resolver is a resolver for application schemas. If anything is a misnomer, it is app-schema, which should be complex-features-mapped-from-simple-features-dataaccess, but I hate to type. ;-) It would actually make a lot of sense to me to put the complex stuff in the same package as the resolver. I am not so sure. app-schema-resolver is fairly small and knows nothing about geoapi. I like your original suggestion of a new module. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On 13/11/12 16:07, Andrea Aime wrote: On Tue, Nov 13, 2012 at 6:06 AM, adam.br...@csiro.au mailto:adam.br...@csiro.au wrote: The work that I did in ComplexFeature Parsing and building support is located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It includes a generic feature builder, a complex feature builder and an attribute builder which I put in gt-main. I also added XSDMapping and FeatureWrapper to gt-main - the idea of these is to help people define strongly-typed classes that they use with the complex feature parser. Does that mean that main ends up depending on gt-xsd-*? That is something I would not be very happy to see, not everybody needs to deal with EMF/XSD when working on GIS applications. I believe avoiding this was a pretty strong design goal. Note also that gt-xsd-gml3 depends on gt-main, so Maven will helpfully choke on any attempt to make gt-main depend on gt-xsd-gml3 as it does not support circular dependencies. :-) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Niels, that sounds great! What is the overlap with Adam Brown's complex builders in his ComplexFeature Parsing and Building Support proposal: http://docs.codehaus.org/display/GEOTOOLS/ComplexFeature+Parsing+and+Building+Support I think this is still resting in a branch in Adam's github repo. See yesterday's committee meeting notes: Reference point: Andrea had to make layers of builders in order to use this kind of setup for CSW (ebRIM record, CSW record). Used Adam's Builder, and then builders on top of that domains specific. Adam? The long-term goal should be to break-out all the complex builders into gt-main (or gt-complex if not possible) and then refactor everything (including gt-app-schema) to use them. And have great API user documentation and example. Kind regards, Ben. On 12/11/12 19:35, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] removing xerces dependency
Justin, I ported AppSchemaValidator to use EntityResolver2, required for relative schema locations: https://github.com/jdeolive/geotools/pull/1 Note that xmlcodegen still fails to build (I commented it out for testing). With noxmldeps GeoTools, there is a unit test failure in GeoServer (app-schema-test SecondaryNamespaceExceptionTest). Looks like a side effect of your dexercesification is that undefined namespace prefixes (null:) are now passed through the GML32OutputFormat XSLT rather that causing an ows:ExceptionReport. Not sure why. I also needed to remove the xerces dependencies in the release module. Nice work! You are pretty close. Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)? https://jira.codehaus.org/browse/GEOS-5352 Kind regards, Ben. On 23/10/12 08:29, Justin Deoliveira wrote: Hi all, So I recently I took a crack at removing the xerces dependency as we discussed in our last skype meeting. For the most part this was relatively straight forward. Unfortunately one thing i wasn't quite able to figure out was some stuff in app-schema-resolver module. The AppSchemaValidator class uses an implementation of what was XMLEntityResolver directly in xerces. I tried porting this to the jaxp EntityResolver interface which is included in the JDK, but couldn't make it work. So I think i will need some help there. Or we can simply keep xerces as a dependency of just app-schema. Here is the branch I am currently working on. https://github.com/jdeolive/geotools/tree/noxmldeps And the corresponding geoserver branch: https://github.com/jdeolive/geoserver/tree/noxmldeps WIth these changes all unit tests pass in both code bases, and so do the GeoServer cite tests. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Xalan in app-schema
More followup from Monday's meeting: The JDK Xalan looks to be 2.6.0. It will not compile the GMLOutputFormat stylesheet used for app-schema WFS output: https://jira.codehaus.org/browse/GEOS-5352 xalan-2.7.0 is shipped with the app-schema plugin. On 29/10/12 22:15, ben.caradoc-dav...@csiro.au wrote: Dropping xerces (and friends) --- Justin: cleaning up the explicit deps on Xerces using the one in the JDK Last issue: app-schema resolver. Ben? app-schema-resolver: move validation support to test and port to new non-xerces api - BCD/RA (and Justin to send draft patch to Ben) Other? JDOM, streaming parsers, Xalan -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Xerces, app-schema-resolver, and gt-xsd-core
Thanks, Justin, I missed it in your original mail. I'll take a look at app-schema-resolver. On 31/10/12 22:27, Justin Deoliveira wrote: Hey Bep, On Tue, Oct 30, 2012 at 11:37 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Justin, you mentioned at Monday's meeting that you investigated removing GeoTools' dependency on external (non-JDK) Xerces, but ran into problems in app-schema-resolver, which gets it as a transitive dependency via gt-xsd-core and uses it for schema-validation. Do you have a patch/branch for the dexercesification of gt-xsd-core? Yup, i linked to it in my original email. Here are the GeoTools and Geoserver branches. https://github.com/jdeolive/geotools/tree/noxmldeps https://github.com/jdeolive/geoserver/tree/noxmldeps JTS also has a dependency on xercesImpl. Yup, on this branch I added an exclusion to the JTS dependency. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Xerces, app-schema-resolver, and gt-xsd-core
Justin, you mentioned at Monday's meeting that you investigated removing GeoTools' dependency on external (non-JDK) Xerces, but ran into problems in app-schema-resolver, which gets it as a transitive dependency via gt-xsd-core and uses it for schema-validation. Do you have a patch/branch for the dexercesification of gt-xsd-core? JTS also has a dependency on xercesImpl. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backport to 8.x (for inclusion in 8.3): GEOT-4160: Support parsing srsName in OGC HTTP URI format
On 16/10/12 14:39, Andrea Aime wrote: Ben, I have two worries about the backport: - the patch is core and non trivial (and only managed to have a cursory look at it) - release is next week Can we land it one day after the release so that it gets some exposure for at least one month on the stable series before a release? I was kind of hoping to get this one into 8.3. However, if I didn't have a lingering concern (and referencing always triggers my fear response), I would not have emailed the list. For getting it in 8.3: - It is a minor improvement. - It cherry-picked cleanly; waiting risks introducing conflicts. - Justin had no objection (on IRC). - It has OCD-level test coverage, in both GeoTools and GeoServer WFS. The referencing test coverage is identical to that for the URN format. I added xsd-gml3 XML parsing coverage of all supported formats. The GeoServer tests cover 4 and 5 parameter BBOX GET requests for all formats. - All tests passed on 8.x/2.2.x, locally and on Hudson (yes, it has been pushed). - It has been on master for over two months. - Nightly users will have a whole week to test it. - As I will be next able to work on this in the week of 29 October, waiting will only increase the number of testing weeks from one to three on stable. Against getting it 8.3: - Even though it is a minor improvement, it modifies referencing, which is not just core, but a snake-pit of interacting classes, adapters, factories, and Hints. - It refactors an implementation class hierarchy (but not a public API). - It changes some public constants including Citations (but these are not intended for direct use). I pushed this change to 8.x (and the unit test to GeoServer 2.2.x) earlier today. If you are sure you would be more comfortable holding this change until the week of 29 October (my next opportunity to work on it) and 8.4, please confirm and I will revert it immediately. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backport to 8.x (for inclusion in 8.3): GEOT-4160: Support parsing srsName in OGC HTTP URI format
On 16/10/12 16:06, Andrea Aime wrote: Btw, this is imho also in violation of http://geoserver.org/display/GEOS/GSIP+77+-+Time+boxed+release+model In my view this is a grey area. The policy explicitly allows new minor core functionality (e.g. new output format. This change seemed to me quite similar. I did not see it as being the major change that requires a vote before backporting. However, I am happy to put it to a vote if you require it. What you appear to be proposing is a hardening period before each stable release. This is not in the policy, as far as I can tell. It does sound like an interesting idea and I am happy to discuss it. Perhaps stable should only be open for backports for the first two weeks? What about the other issues raised at the meeting on Monday? Will they be held as well? I am not sure I like all the implications. This change was already accepted by you on master. We picked through all the details. I made all the improvements suggested by you. I went through it in agonising detail. I was not aware that you only managed to have a cursory look at it. I apologise if I have stepped on your toes as referencing maintainer. Again, I am quite happy to revert this change if you have a problem with it. I am also quite happy for you to do the reverting, if you prefer. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backport to 8.x (for inclusion in 8.3): GEOT-4160: Support parsing srsName in OGC HTTP URI format
On 16/10/12 15:45, Andrea Aime wrote: Bah, keep it there, but I'm wondering what's the point of asking if you can't even wait a few hours for the mailing list to respond before committing... Transparency. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Backport to 8.x (for inclusion in 8.3): GEOT-4160: Support parsing srsName in OGC HTTP URI format
On 16/10/12 16:58, Andrea Aime wrote: A new output format is fully pluggable, needs no changes in core modules, it's a mere extra. Your change refactors existing classes instead. Thanks for the clarification. Just to be clear, I'm not opposed to the backport, I'm just worried about its timing. Sure, I agree that I should have done it earlier in the cycle. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Backport to 8.x (for inclusion in 8.3): GEOT-4160: Support parsing srsName in OGC HTTP URI format
I would like to backport GEOT-4160: Support parsing srsName in OGC HTTP URI format to 8.x (for inclusion in 8.3). It has been on master for two months. I was able to cherry-pick it cleanly, and it is building now. I am asking because it affects referencing which is core and ... unforgiving. GEOT-4160: Support parsing srsName in OGC HTTP URI format https://jira.codehaus.org/browse/GEOT-4160 Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Postgis 2.0 raster and postgres jdbc driver version
Justin,
see also this Jira issue from February. If you upgrade the driver and
fix this failure, please resolve the issue:
Support PostgreSQL 9 hex bytea output format to avoid massive data
corruption
https://jira.codehaus.org/browse/GEOT-4040
Kind regards,
Ben.
On 12/10/12 21:08, Justin Deoliveira wrote:
I would use a property to make this configurable. Indeed I ran into this
same problem when trying to run postgis tests against a postgresql 9.1
database. The protocol for blobs has changed which caused those tests to
fail. Since we want to support both major versions of postgresql it
makes sense that this version is configurable.
Anyways, what you can do is this.
1. Define a property in the root pom, with the default being the current
postgresql jdbc driver version.
properties
postgresql.jdbc.version8.4-701.jdbc3/postgresql.jdbc.version
/properties
2. Update the dependency management entry.
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
version${postgresql.jdbc.version}/version
/dependency
3. In imagemosaic-jdbc/pom.xml simply override the property.
properties
postgresql.jdbc.version9.1-901-1.jdbc4/postgresql.jdbc.version
/properties
-Justin
On Fri, Oct 12, 2012 at 2:57 AM, christian.muel...@nvoe.at
mailto:christian.muel...@nvoe.at wrote:
Long story for short. The postgis raster online test was broken and
the fix is to update the postgres driver version. The module will not
work with 8.x postgres drivers.
The global pom contains
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
version8.4-701.jdbc3/version
/dependency
The imagemosaic-jdbc pom has to specify its own version.
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
!-- Overriding version number from parent POM. --
version9.1-901-1.jdbc4/version
scopetest/scope
/dependency
Perhaps we should update the version in the global POM ?.
Btw, our postgis jdbc driver is also not up to date.
Cheers
Christian
This message was sent using IMP, the Internet Messaging Program.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
mailto: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.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Postgis 2.0 raster and postgres jdbc driver version
That is also in the Jira issue!
https://jira.codehaus.org/browse/GEOT-4040
If we upgrade the driver, do we fix it for everyone?
On 12/10/12 21:30, christian.muel...@nvoe.at wrote:
Hi Justin
I found another solution:
If you use a postgres driver lower than version 9 you can prepare your
database
with
ALTER DATABASE dbname SET bytea_output TO 'escape';
I will kick out myversion tag, prepare my test database and add
this info to the user guide. I think this is the cleanest solution.
Zitat von Justin Deoliveirajdeol...@opengeo.org:
I would use a property to make this configurable. Indeed I ran into this
same problem when trying to run postgis tests against a postgresql 9.1
database. The protocol for blobs has changed which caused those tests to
fail. Since we want to support both major versions of postgresql it makes
sense that this version is configurable.
Anyways, what you can do is this.
1. Define a property in the root pom, with the default being the current
postgresql jdbc driver version.
properties
postgresql.jdbc.version8.4-701.jdbc3/postgresql.jdbc.version
/properties
2. Update the dependency management entry.
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
version${postgresql.jdbc.version}/version
/dependency
3. In imagemosaic-jdbc/pom.xml simply override the property.
properties
postgresql.jdbc.version9.1-901-1.jdbc4/postgresql.jdbc.version
/properties
-Justin
On Fri, Oct 12, 2012 at 2:57 AM,christian.muel...@nvoe.at wrote:
Long story for short. The postgis raster online test was broken and
the fix is to update the postgres driver version. The module will not
work with 8.x postgres drivers.
The global pom contains
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
version8.4-701.jdbc3/version
/dependency
The imagemosaic-jdbc pom has to specify its own version.
dependency
groupIdpostgresql/groupId
artifactIdpostgresql/artifactId
!-- Overriding version number from parent POM. --
version9.1-901-1.jdbc4/version
scopetest/scope
/dependency
Perhaps we should update the version in the global POM ?.
Btw, our postgis jdbc driver is also not up to date.
Cheers
Christian
This message was sent using IMP, the Internet Messaging Program.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-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.
This message was sent using IMP, the Internet Messaging Program.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBC build and other extra builds
On 09/10/12 14:06, Andrea Aime wrote: The same could be said for builds against OpenJDK, JDK 7, Windows and so on. Not quite. In my view, JDBC is core functionality, on a core platform. I agree with you that supplementary builds like OpenJDK, JDK, Windows, and builds in paths with spaces can be banished to other lists until we agree that these are supported platforms. Continuous build failures that get ignored because there is no bandwidth to address them just make the whole point of having a build server moot. How many people did notice that that main build was failing due to a temporal test since October 1st? Why the usual fool had to fix it on a Sunday? Conscript more fools. ;-) I just spent several hours fixing the JDBCJoinTest failure (or introducing a complementary bug that makes the build pass; I am not quite sure). Griping about it was taking too much time. (the fact that the main module was failing is an aggravation, since it's everyone's responsibility no one really feels responsible about it, at the same time fixing the test was a one liner). The primary build should be of interest of everyone, it's the one that should never fail, if we get 10 failure messages a day people will just ignore them, including the ones regarding the primary build. I agree with you. The JDBCJoinTest failure should never have been left as long as it was. What we have just seen is exactly what happens when build failures are ignored: developers stop paying attention and continuous integration is lost. It is not good enough that other developers are relying on you to clean up after them. Unless the situation improves, we are going to have to start getting tough and reverting commits that break the build. That should get some attention. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBC build and other extra builds
On 08/10/12 23:41, Justin Deoliveira wrote: @Ben: What db's do you run the jdbc tests for? Both kinds: PostGIS *and* Oracle: http://www.youtube.com/watch?v=cSZfUnCK5qk -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBC build and other extra builds
On 08/10/12 03:03, Andrea Aime wrote: the JDBC build keeps on failing and keeps on polluting the devel mailing list. It is not polluting the list. It is warning the list that this test is broken. That is what it is for. The solution should be to fix the test or the underlying code that causes the failure. Since it's clear we get no short term fix can we move that build mails off the devel list? We can silence this build but only as a temporary measure. Creating a new list makes it seem like a longer-term arrangement. Hey, there is an idea for a new Jenkins/Hudson plugin: press a button to silence a build failure for 24 hours. Snooze mode. :-) -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBC build and other extra builds
On 08/10/12 03:03, Andrea Aime wrote: the JDBC build keeps on failing and keeps on polluting the devel mailing list. Since it's clear we get no short term fix I think I might have a long term fix. Would that do? https://github.com/geotools/geotools/pull/36 https://jira.codehaus.org/browse/GEOT-4204 -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBC build and other extra builds
On 08/10/12 04:09, Jody Garnett wrote: Do we have any idea what is killing the JDBC Build. [GEOT-4204] Intermittent JDBCJoinTest failures https://jira.codehaus.org/browse/GEOT-4204 -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] MemoryDataStore axis order flip intended?
On 26/09/12 16:58, Andrea Aime wrote: On Wed, Sep 26, 2012 at 5:49 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: tb.setCRS(CRS.decode(EPSG:__4326, true)) I will push it if it resolves the issue. I agree this should be the way to decode the SRS Thanks, Andrea, I have pushed the fix to master. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] H2 connection string for path with spaces?
On 20/09/12 10:44, Ben Caradoc-Davies wrote: On 19/09/12 17:16, Andrea Aime wrote: Ben, the fix seems indeed quite easy, why don't you give it a shot? :-p I tried the easy fix on Tuesday (see patch attached to the issue) but it broke the test. :-( I will have another look if I have time. Done! I found the second spot in imagemosaic where special handling occurs for H2 connection URLs. My updated patch ensures that jdbc URLs are now fed to H2 in the form it expects: without percent encoding. I am now shopping for a reviewer: [GEOT-4262] imagemosaic incorrect handling of H2 database paths with spaces https://jira.codehaus.org/browse/GEOT-4262 Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
