On Mon, Apr 18, 2011 at 9:46 AM, Luca Morandini
<luca.morandi...@gmail.com> wrote:
> On 04/16/2011 04:11 PM, Jody Garnett wrote:
>> Docs ported to sphinx; if you need to update them:
>> - http://docs.geotools.org/latest/userguide/library/render/wkt.html
>
> Does it mean I will have to edit the mark-up of the TXT file in the SVN
> repository
> ? It does not look terribly user-friendly (I know nothing about Sphinx).
Yet it's a viable way to keep the docs versioned along with the code.
We had really bad experiences with Confluence, uses would just not contribute
and developers would not care much either.
In GeoServer at least devs contribute a bit to the sphinx docs, more than they
used to with confluence at least, and we have one set of docs for 1.7.x, one
for 2.0.x, and so on instead of a single chaotic set of docs with various
states of up-to-dateness
>> I would like to sort out a way others configure these classes to use their
>> own
>> property file?
>
> That was my intention too, but.. well, I tried to do this using an URL
> instead of
> the property file name, but dropped that code portion because:
> 1) I deemed inconvenient to expose the URL of some properties file in your
> SLD.
> 2) I was unable to use a "file://" URL without specifying the absolute path.
> 3) There are mechanisms in GeoServer to find out resources relative to the
> data
> dir, but I did not want introduce a dependency on GeoServer in GeoTools.
>
> ...but I am pretty sure you, or other worthy folks, will point me towards a
> solution ;)
I was about to ask something in that direction so that GS could have
wkt libraries
in the data directory.
In GeoServer we have a concept called "Resource Loader":
public interface ResourceLoader {
/** Pseudo URL prefix for loading from the class path: "classpath:" */
String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX;
/**
* Return a Resource handle for the specified resource.
* The handle should always be a reusable resource descriptor,
* allowing for multiple {@link Resource#getInputStream()} calls.
* <p><ul>
* <li>Must support fully qualified URLs, e.g. "file:C:/test.dat".
* <li>Must support classpath pseudo-URLs, e.g. "classpath:test.dat".
* <li>Should support relative file paths, e.g. "WEB-INF/test.dat".
* (This will be implementation-specific, typically provided by an
* ApplicationContext implementation.)
* </ul>
* <p>Note that a Resource handle does not imply an existing resource;
* you need to invoke {@link Resource#exists} to check for existence.
* @param location the resource location
* @return a corresponding Resource handle
* @see #CLASSPATH_URL_PREFIX
* @see org.springframework.core.io.Resource#exists
* @see org.springframework.core.io.Resource#getInputStream
*/
Resource getResource(String location);
/**
* Expose the ClassLoader used by this ResourceLoader.
* <p>Clients which need to access the ClassLoader directly can do so
* in a uniform manner with the ResourceLoader, rather than relying
* on the thread context ClassLoader.
* @return the ClassLoader (never <code>null</code>)
*/
ClassLoader getClassLoader();
}
The wkt system could have some way to register custom resource loaders
for the wk files. Maybe just a static method, if not an SPI extension.
Just my 2 cents.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
