Thanks again for the big docs build speed-up Andrea. It's great !
Michael
On 16 May 2011 18:34, Andrea Aime wrote:
> On Mon, May 16, 2011 at 10:10 AM, Michael Bedward
> wrote:
>> Ah OK. That explains the difference between my macbook and Hudson,
>> although it leaves me guilty of just looking a
On Mon, May 16, 2011 at 10:10 AM, Michael Bedward
wrote:
> Ah OK. That explains the difference between my macbook and Hudson,
> although it leaves me guilty of just looking at the SUCCESS message
> and ignoring the warnings above it.
>
> Andrea, was the -W flag a performance problem ?
Nope, I gue
Ah OK. That explains the difference between my macbook and Hudson,
although it leaves me guilty of just looking at the SUCCESS message
and ignoring the warnings above it.
Andrea, was the -W flag a performance problem ?
Meanwhile, it seems that the "include" directive will not work without
an expl
For those watching, I reopened this issue until the docs build is fixed:
> http://jira.codehaus.org/browse/GEOT-3587
>
> Perhaps we should use the -W command-line flag in the build to treat all
> warnings as errors?
We did have the -W flag on; could we restore it please :-)
Jody ---
Michael,
I also saw the same behaviour. OpenGeo Hudson uses sphinx v1.0b2 which
either defaults to or has been configured to exit with an error when it
encounters the SEVERE warning caused by the missing includes. The sphinx
v1.0.7 that I use (with default settings) produces the same SEVERE
wa
On Mon, May 16, 2011 at 9:46 AM, Michael Bedward
wrote:
> Hi Andrea,
>
> I swapped the sphinx source file extensions to rst earlier today and
> it has broken the Hudson build, however I did a local build before
> committing the mass change and it ran without error. Would the changes
> you made yes
Hi Andrea,
I swapped the sphinx source file extensions to rst earlier today and
it has broken the Hudson build, however I did a local build before
committing the mass change and it ran without error. Would the changes
you made yesterday hide errors somehow ? Or am I not running the local
build pro
I did a check to see what modules were not covered by any documentation; and
came up with 27 entries from plugins and unsupported.
(This was not including the ogc and xsd jars which I documented quickly without
any examples).
Some of these experiments look like they can just be thrown out; other
On 04/19/2011 10:54 AM, Andrea Aime wrote:
> On Tue, Apr 19, 2011 at 10:06 AM, Luca Morandini
>>
>> I got the idea, but I don't like the prospect of putting a dependency on
>> mark-wkt
>> in GeoServer or uDIG or whatever.
>
> The interface would not be the GeoServer one, you roll your own in your
On Tue, Apr 19, 2011 at 10:06 AM, Luca Morandini
wrote:
> On 04/19/2011 08:36 AM, Andrea Aime wrote:
>> On Tue, Apr 19, 2011 at 8:02 AM, Luca Morandini
>>>
>>> I did not get it: how would the software know which is the parent dir in
>>> different
>>> environment (GS or uDIG, for instance) ?
>>
>>
On 04/19/2011 08:36 AM, Andrea Aime wrote:
> On Tue, Apr 19, 2011 at 8:02 AM, Luca Morandini
>>
>> I did not get it: how would the software know which is the parent dir in
>> different
>> environment (GS or uDIG, for instance) ?
>
> I guess you're thinking configurable, I'm thinking programmable.
On Tue, Apr 19, 2011 at 8:02 AM, Luca Morandini
wrote:
>> Something easier like:
>>
>> interface ResourceLocator {
>> InputStream getResource(String location);
>> }
>>
>> could easily be implemented in different ways as something that can lookup
>> in the classpath or relative to a parent folde
On 04/18/2011 10:35 PM, Andrea Aime wrote:
> On Mon, Apr 18, 2011 at 1:24 PM, Luca Morandini
>> This way an absolute path URL may be rendered relative, like:
>> wktlib://file://${GEOSERVER_DATA_DIR}/styles/mywkt.properties
>>
>> What do you think ?
>
> I believe it would inflict quite some pain to
; Patrick Jessup
Cc: geotools-devel@lists.sourceforge.net
Subject: Re: [Geotools-devel] docs typos and sphinx error
A work colleague; Patrick, ran into this issue. He did some interesting fix to
the
Sphinx source code; something like putting a chmod in front of the line that
tries to remove
the
Yes, lots of windows users have seen this error. Anyone else have a
workaround?
On 19/04/11 11:31, Jody Garnett wrote:
> A work colleague; Patrick, ran into this issue. He did some interesting fix
> to the
> Sphinx source code; something like putting a chmod in front of the line that
> tries to
A work colleague; Patrick, ran into this issue. He did some interesting fix
to the
Sphinx source code; something like putting a chmod in front of the line that
tries to remove
the directory.
Patrick do you have your fix handy so Lee can try it out?
Basically it does not look like Sphinx is tested
Sphinx got very nearly done and hit this error:
[exec] writing additional files... search
[exec] Making output directory...
[exec] Exception occurred:
[exec] File "C:\Program Files (x86)\Python27\lib\shutil.py", line
247, in
rmtree
[exec] os.remove(fullname)
[exec
I figured out the sphinx problem -- 0.6.6 is way old. I installed the
latest (1.0.7) and now it's cranking..
Lee
On 4/18/2011 5:59 PM, lee-verizon wrote:
> Hi. As I'm reading various GeoTools docs (user and developer), I see a
> number of minor typos. I have corrected some of them in the .txt fi
Hi Lee,
On Mon, Apr 18, 2011 at 6:59 PM, lee-verizon wrote:
> Hi. As I'm reading various GeoTools docs (user and developer), I see a
> number of minor typos. I have corrected some of them in the .txt files
> in the docs project. What's the best way to submit these changes -- do I
> just create a
Hi. As I'm reading various GeoTools docs (user and developer), I see a
number of minor typos. I have corrected some of them in the .txt files
in the docs project. What's the best way to submit these changes -- do I
just create a patch and attach it to a JIRA as described here:
http://docs.geoto
On Mon, Apr 18, 2011 at 1:24 PM, Luca Morandini
wrote:
> On 04/18/2011 10:03 AM, Andrea Aime wrote:
>> /**
>> * Return a Resource handle for the specified resource.
>> * The handle should always be a reusable resource descriptor,
>> * allowing for multiple {@link Resourc
One thing I have though of here is trying to make it so the "current
directory" for image file references referenced from an SLD - is the same
directory as the SLD? If we could do it for images the same technique could
be used to reference a property file?
Just a thought
Jody
-
On 04/18/2011 10:03 AM, Andrea Aime wrote:
> /**
>* Return a Resource handle for the specified resource.
>* The handle should always be a reusable resource descriptor,
>* allowing for multiple {@link Resource#getInputStream()} calls.
>*
> *Must support fu
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).
To be honest it is not user friendly - it is developer friendly. The text
syntax is basically the same as for a wiki; the only difference is w
On Mon, Apr 18, 2011 at 9:46 AM, Luca Morandini
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
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 k
Docs ported to sphinx; if you need to update them:
- http://docs.geotools.org/latest/userguide/library/render/wkt.html
One thing that was not clear to me until I read the docs was that we could not
add additional property files without placing them into the jar?
I would like to sort out a way ot
On 16 April 2011 19:44, Jody Garnett wrote:
> 1. create mess
> svn
> mv http://svn.osgeo.org/geotools/trunk/docs/user http://svn.osgeo.org/geotools/branches/docs/user
> 2. clean up mess
> --
Ah... techno-talk :)
Michael
---
1. create mess
svn mv http://svn.osgeo.org/geotools/trunk/docs/user
http://svn.osgeo.org/geotools/branches/docs/user
2. clean up mess
--
Jody Garnett
On Saturday, 16 April 2011 at 6:32 PM, Michael Bedward wrote:
> On 16 April 2011 18:10, Jody Garnett wrote:
> > - If anyone is interested in d
On 16 April 2011 18:10, Jody Garnett wrote:
> - If anyone is interested in doing an svn copy we may be able to get the
> docs going for 2.7 as well
Hi Jody: do you just mean copying docs/user from trunk to 2.7.x ?
Michael
-
Got the content ported over to trunk ... 11 words according to this word
processor thing - hey that does not include the tutorials so it is probably a
bit more.
Next up:
- I would like to make a 8-M0 milestone release to capture this thing
- make a blog post; and shut off our user guide wiki
Sorry intended to CC the list on this one.
On Wednesday, 13 April 2011 at 12:02 AM, Jody Garnett wrote:
I was not quite able to get all the code examples sorted; probably need to look
at the test cases to see how it goes. I think I will give up and steal some
examples from the uDig code base.
>
I don't remember actually doing this... svn blame points to jody. But it
makes sense because if we kept it projcet.version links on the website would
link to downloads with SNAPSHOT versions, which we don't have. Unless we
only generated the website from a tag... which we don't currently do.
But M
Hi Jody
> It is supposed to indicate the last stable release; so the website docs
> should match the latest thing you can download.
So why isn't it always set to ${project.version} ?
Michael
--
Enable your software for
It is supposed to indicate the last stable release; so the website docs
should match the latest thing you can download.
Jody
On Thu, Mar 24, 2011 at 3:11 PM, Michael Bedward
wrote:
> Hi Jody, Justin,
>
> I'm just looking at the very beautiful sphinx setup on trunk, trying
> to understand how all
Hi Jody, Justin,
I'm just looking at the very beautiful sphinx setup on trunk, trying
to understand how all the bits now fit together.
In the pom, a hard-coded version string is being passed to the ant task...
Hi Jody,
> So where do we store the website?
> - http://svn.osgeo.org/geotools/web/ (is a suggestion)
> - http://svn.osgeo.org/geotools/trunk/website <-- and have it link to
> seperatly produced & published docs for 1.7 and 1.6?
I've often got more than one version of trunk on my local machine
On 09/05/2010, at 7:38 PM, Michael Bedward wrote:
> I guess the wiki is dead in terms of being a user-supported resource,
> but it's very much alive in terms of there being a huge amount of
> material there that can be re-used. So much easier than starting from
> scratch ! And although there has
Hi Jody,
Thanks for this. I'm with you on making the docs more formally part
of the code base (ie. out of 'spike') and continuing to move things
into sphinx docs with live code links.
I guess the wiki is dead in terms of being a user-supported resource,
but it's very much alive in terms of there
I have some ideas spinning out the docs discussion of on the user list; and
after accosting andrea on the IRC channel have been told to "socialise" them.
Basically:
- we would like to publish docs for stable 2.6
- we would like to publish docs for 2.7
- and we can "end" the experimental spike/web
abilities.
>
> --saul
>
>
> -Original Message-
> From: David Adler [mailto:[EMAIL PROTECTED]
> Sent: Thu 3/29/2007 9:50 AM
> To: Andrea Aime
> Cc: sfarber; geotools-devel@lists.sourceforge.net; Justin Deoliveira
> Subject: Re: [Geotools-devel] Docs to track thoughts on
otools
FilterCapabilities.
--saul
-Original Message-
From: David Adler [mailto:[EMAIL PROTECTED]
Sent: Thu 3/29/2007 9:50 AM
To: Andrea Aime
Cc: sfarber; geotools-devel@lists.sourceforge.net; Justin Deoliveira
Subject: Re: [Geotools-devel] Docs to track thoughts on SQLEncoder new filte
It isn't clear to me what the relationship is of the opengis
FilterCapabilities and the geotools FilterCapabilities.
With the switch to the opengis filters, should the geotools
FilterCapabilities still be used?
I've mostly converted SQLEncoderDB2 over to use FilterToSQL.
Andrea Aime wrote:
>
Andrea Aime ha scritto:
> sfarber ha scritto:
>> No big hullabaloo about this, so I'm going to commit. Check back on the page
>> linked below to keep up on the status of the work.
>
> Saul,
> I think I've found an issue with FilterCapabilities and pre/post filter
> changes.
> The issue being that
sfarber ha scritto:
> No big hullabaloo about this, so I'm going to commit. Check back on the page
> linked below to keep up on the status of the work.
Saul,
I think I've found an issue with FilterCapabilities and pre/post filter
changes.
The issue being that all datastores besides maybe arcsde d
Thanks for the write up Saul :-)
Jody
> No big hullabaloo about this, so I'm going to commit. Check back on the page
> linked below to keep up on the status of the work.
>
> --saul
>
>
> sfarber wrote:
>
>> Per list suggestion, here's a page summarizing thoughts on SQLEncoder
>> porting-to-geo
No big hullabaloo about this, so I'm going to commit. Check back on the page
linked below to keep up on the status of the work.
--saul
sfarber wrote:
>
> Per list suggestion, here's a page summarizing thoughts on SQLEncoder
> porting-to-geoapi-filters questions.
>
> http://docs.codehaus.org/
Per list suggestion, here's a page summarizing thoughts on SQLEncoder
porting-to-geoapi-filters questions.
http://docs.codehaus.org/display/GEOTOOLS/SQLEncoder+Upgrade+to+GeoAPI+Filters
If you're interested/care, please peruse and let me know what you think about
package/class renaming. I'll
48 matches
Mail list logo
