Re: [udig-devel] Problem with Spaces in Filenames

[Wayne Beaton]

Git does a good job of keeping track of the commits made after the initial contribution. Once we have the approval and the initial contribution has been checked into LocationTech Git, you can start working through the commits that have been created in the meantime. Everything is subject to the IP Policy. The short version is that any project committer's contributions can be just pulled into the new repository. Anything that comes from an outside contributor may require more effort. As a minimum, the contributor will have to assert (generally on a bug report) that they authored 100% the code, are authorized to contribute it, and do so under the project licenses. If the contribution is more than 250 lines of code, you will have to get the IP team to review it via contribution questionnaire. We are working on a new CLA-based solution that will make the assertions a lot simpler. We're planning to roll this out over the summer. HTH, Wayne On 04/04/2013 08:46 AM, Jody Garnett wrote: Sounds good,  I am comfortable accepting commits from everyone who is in the pipeline for commit access. For anyone else I think we should talk to our mentor get some direction (don't want to make more work then we have to). Frank are you happy to review Emily's patch? It seems to have a tests case and so on … looks like a section was escaping encoding. --  Jody Garnett On Thursday, 4 April 2013 at 5:44 PM, Frank Gasdorf wrote: My understanding is we can commit as much as we need into the existing repository. Once the new repo at locationtech has been set up and initial code were checked in (after path/packages migration?) its pretty easy to identify the commits since tag 1.4.0. We can add udig-platform as a remote repository to the new clone taken from locationtech afterwards. All commits pushed after 1.4.0 can cherry-picked into a new branch merged back into mainline at locationtech. I would suggest to commit and push. In this case of the current pull we should accept it. Thanks Emily for the fix including a test case!! Cheers,  Frank 2013/4/4 Jody Garnett <jody.garn...@gmail.com> We are kind of in limbo during the migration to eclipse hosting (i.e. we have not sorted out as a team what we want to do - and I do not have a fix on how long it will take for the initial codebase to be available). My understanding is that since you are set up on the eclipse end of things that we can smoothly pull your fix over when the time comes. Ideas? --  Jody Garnett On Thursday, 4 April 2013 at 5:32 AM, Emily Gouge wrote: Thanks for the help Jody. I think I tracked down and solved the problem. I opened a JIRA bug and created a pull request with my updates. https://github.com/uDig/udig-platform/pull/166 Emily On 02/04/2013 8:26 PM, Jody Garnett wrote: Afternoon Emily: While I have not had a chance to test, I have run into similar problems previously. There are two candidates: 1) The code that writes the catalog out to disk, and reads is back in again performs some URL encoding/decoding. 2) Similar code is called when MapImpl is saved (as it wants to save out connection parameters for each of its layers) I have sent emails tracing through these methods before, with notes ... For now: 1. CatalogImpl.saveToFile calls ServiceParameterPersister.store 2. Which rewrites URLs to be relative: URL relativeURL = URLUtils.toRelativePath(this.reference, url); value = URLUtils.urlToString(relativeURL, true); 3. And then encodes: value= URLEncoder.encode( value, ENCODING ); Similar code in restoreProperties performs the reverse. Debug these two methods to see where things have gone astray? On Wed, Apr 3, 2013 at 7:28 AM, Emily Gouge <ego...@refractions.net> wrote: I have a shapefile with a space in the file name ("my test.shp"). When I load this into uDig the first time it loads and displays fine. However when I close and re-open uDig the file is not displayed. This warning message is printed: "Trouble matching file for:file:/C:/data/SMART/**SampleData/countries2/my% **20test.shp#my%20test" This problem only occurs when the space is in the file name. If the space exists in one of the directory names I don't have any problems. Also, it is not specific to shapefiles; it also happens for raster files. Can somebody confirm this behavior and perhaps point me to where I need to look to get it resolved? Thanks, Emily ______________________________**_________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/**mailman/listinfo/udig-devel<http://lists.refractions.net/mailman/listinfo/udig-devel> _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel