Re: [Geotools-devel] gt-xml dependencies

Reviewing gt-xml; it is very much non core. It is simply collecting the first generation gtxml parser design (for some reason I though that the SLDParser and others were here (instead they are still in main). So that leaves me running in circles... Idea: - move gt-xml to extension/xml (allowing

Re: [Geotools-devel] Publishing documentation

Hi Justin, > My main question is from what branch should the site be generated? Trunk > or the latest stable branch? The sphinx docs (examples) on trunk are the only ones that have been getting attention. Confusingly, they refer to the 2.6.x code (links in the docs are to tags/2.6.4). This is my

[Geotools-devel] gt-xml dependencies

After friendly IRC chat with Gabriel... Looks like asking gt-xml to take on the task is the best way forward; it offers a central spot for GML handling that other modules can use. My strategy will be to review the wps parser configuration (where it is configured with with both GML2 and GML3 all

Re: [Geotools-devel] Setting up a new branch to work on ImageMosaic

Sounds good; for a wile we tried to make a wiki page describing any long lived branch; but it is probably better to stick a branch.txt description with the same information. Related link: - http://docs.codehaus.org/display/GEOTOOLS/Branch I gotta say it sounds less risky to use GIT for any long

[Geotools-devel] wfs maintainers: GMLEncode/GMLDecode

Hi Justin: After a bit of research I can produce a GMLDecode/GMLEncode class. You recommended using "the gml" module as a location; trouble is only the wfs module depends on all the needed configurations. To parse results from WFS and OpenLayers we need to depend on the WFS configuration as we

Re: [Geotools-devel] Publishing documentation

That is great. The rest of your email is the plan as I understand it; we discussed breaking the examples out into userguide so we could link to them from the website. I am interested in messing with the template a bit for the userguide (more content less navigation). Jody On 02/06/2010, at 7

[Geotools-devel] Hudson build is back to normal: geotools-2.6.x #385

See -- ___ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/list

[Geotools-devel] Publishing documentation

Hi all, I am on the last step of the documentation proposal, which is pushing built docs to the geotools.org site. My main question is from what branch should the site be generated? Trunk or the latest stable branch? For the website itself it would make sense just to generate it from the trun

[Geotools-devel] Build failed in Hudson: geotools-2.6.x #384

See -- A SCM change trigger started this job Updating http://svn.osgeo.org/geotools/branches/2.6.x ERROR: Failed to update http://svn.osgeo.org/geotools/branches/2.6.x org.tmatesoft.svn.core.SVNCance

Re: [Geotools-devel] GeoTools OSGi compatibility

> Is the proposal going to ask that every module maintainer picks > the dependencies only from the Spring repos, or otherwise dependencies > that have the proper OSGI meta-files? What if we need a dependency > that is not there, must we go and repack it with the proper informations > and upload to

Re: [Geotools-devel] GeoTools OSGi compatibility

Jody Garnett ha scritto: > Hi Mathieu: > > I am going to try and turn your email into a proposal as I understand > it. The proposal will need to have a couple of examples in it to > explain to PMC members what it is we are planning to do. I was not > aware of the progress made by the spring source

Re: [Geotools-devel] GeoTools OSGi compatibility

> I am going to try and turn your email into a proposal as I understand it. The > proposal will need to have a couple of examples in it to explain to PMC > members what it is we are planning to do. I was not aware of the progress > made by the spring source maven repo - interesting. examples =>

Re: [Geotools-devel] Setting up a new branch to work on ImageMosaic

Daniele Romagnoli ha scritto: > Hi list, > we would like to setup a separated branch to do some works and > refactorings on the ImageMosaic plugin without modifying > trunk/modules/plugin/imagemosaic (as happened in the previous days). I > have noticed that Jody and Michael did a similar thing f

[Geotools-devel] Setting up a new branch to work on ImageMosaic

Hi list, we would like to setup a separated branch to do some works and refactorings on the ImageMosaic plugin without modifying trunk/modules/plugin/imagemosaic (as happened in the previous days). I have noticed that Jody and Michael did a similar thing for the simple-feature work and the swing-re

Re: [Geotools-devel] GeoTools OSGi compatibility

Hi Mathieu: I am going to try and turn your email into a proposal as I understand it. The proposal will need to have a couple of examples in it to explain to PMC members what it is we are planning to do. I was not aware of the progress made by the spring source maven repo - interesting. I woul

Re: [Geotools-devel] GeoTools OSGi compatibility

Hello Jody, I gave a first try to integrating the Maven Bundle Plugin with the GeoTools build process. It went pretty well and I could build all the jars with OSGi metadata in their MANIFEST. (more details below) This was the easy part and now the hard part is to see how we can have a set of modu

[Geotools-devel] [jira] Created: (GEOT-3129) Swing module, DnDList bug

Swing module, DnDList bug - Key: GEOT-3129 URL: http://jira.codehaus.org/browse/GEOT-3129 Project: GeoTools Issue Type: Bug Components: swing Affects Versions: 2.7-M0, 2.6.0 Reporter: Michael

[Geotools-devel] Extend the property identifier rule to allow defining propery name between doble quote

Extend the property identifier rule to allow defining propery name between doble quote -- Key: GEOT-3122 URL: http://jira.codehaus.org/browse/GEOT-3122 Project: GeoTo