It doesn't change.
On 07/04/11 10:10, Michael Bedward wrote:
> What have you get against the number 2 ?
>
> On 7 April 2011 11:54, Ben Caradoc-Davies wrote:
>> Dropping the "2." off svn branches sounds good to me.
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and R
What have you get against the number 2 ?
On 7 April 2011 11:54, Ben Caradoc-Davies wrote:
> Dropping the "2." off svn branches sounds good to me.
>
> On 07/04/11 05:36, Jody Garnett wrote:
>> We will just smoothly go over to 2.6.x, 2.7.x, 8.x, 9.x etc... from this
>> standpoint we are simply dro
Hi Jody
gt-render already depends on the batik library for SLD stuff. I
remember we specifically excluded the batik library in the example
poms at some stage because we didn't want all that stuff confusing
users (or was it for another reason ?). So I wonder whether it's a
good idea to have such a
Dropping the "2." off svn branches sounds good to me.
On 07/04/11 05:36, Jody Garnett wrote:
> We will just smoothly go over to 2.6.x, 2.7.x, 8.x, 9.x etc... from this
> standpoint we are simply dropping the "2".
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and Re
Currently it is a module; in the demo directory. I could take on svg as a
dependency for docs/ and have this as a simple code example instead.
I have no svg plans afoot.
But yeah it occurs to me that an unsupported "svg", "print" and "pdf" module
would not go amiss as they are common rendering
Hi Jody,
It's only tiny - is it worth a module ? Perhaps just make it an
example instead. Or do you have SVG plans afoot ?
Michael
On 7 April 2011 00:55, Justin Deoliveira wrote:
> Sounds good to me.
>
> On Wed, Apr 6, 2011 at 8:47 AM, Jody Garnett wrote:
>>
>> The gt-svgsupport class has be
Yep - Ignore me, I read it as "we allow modules to each have their own
version number" rather than "we do not..."
Hadn't had my coffee yet :-(
On 7 April 2011 10:06, Jody Garnett wrote:
> um it is easy; we currently do it? We grab the project.version from our
> parent pom.xml.
> In the dawn of t
Your scenario sounds fine; but I thought the handling of major/minor/patch was
a different topic?
> >
> > To me it seems to make sense to consider them in the same proposal
> > conversation. Since one directly impacts the other does it not?
>
>
>
>
I have updated the page to indicate the do
um it is easy; we currently do it? We grab the project.version from our parent
pom.xml.
In the dawn of time (like GeoTools 2.0) we experimented with allowing module to
each have their own version number; the resulting confusion as people tried to
sort out what jars would work together was like
On 7 April 2011 01:33, Jody Garnett wrote:
> In particular we do not allow modules to each have their own version number.
>
That's really hard to do in a maven-based modular project. I recently
investigated it for jai-tools and there was no off-the-shelf solution,
only one or two experimental plu
And ready for review:
- http://docs.geotools.org/latest/userguide/guide/library/jdbc/index.html
It is mostly just the contents from the wiki; I expect we may have more formats
than are listed.
I left placeholders in:
- ingres that is still in unsupported right?
- teradata (for when jesse gets to
On Wed, Apr 6, 2011 at 9:33 AM, Jody Garnett wrote:
> > Your scenario sounds fine; but I thought the handling of major/minor/patch
> > was a different topic?
> >
> > To me it seems to make sense to consider them in the same proposal
> > conversation. Since one directly impacts the other does it
On Wed, Apr 6, 2011 at 1:34 PM, DGIS Devels wrote:
> Hi, list
>
> It's possible to label polygon vertexs in a FeatureTypeStyle pragmatically ?
What label would you give to the polygon vertices?
In any case, it's not something we have support for now, though it's doable on
trunk (not on 2.7.x) bui
On Wed, Apr 6, 2011 at 9:33 AM, Jody Garnett wrote:
> Your scenario sounds fine; but I thought the handling of
> major/minor/patch was a different topic?
>
> To me it seems to make sense to consider them in the same proposal
conversation. Since one directly impacts the other does it not?
> On
Your scenario sounds fine; but I thought the handling of major/minor/patch was
a different topic?
On Thursday, 7 April 2011 at 1:13 AM, Justin Deoliveira wrote:
In general I support the idea but I think the proposal lacks some specifics
about how version number changes relate to api changes. Cur
In general I support the idea but I think the proposal lacks some specifics
about how version number changes relate to api changes. Currently we have
the numbering system .. and our policy is:
major: while I have never been around for major version change I take this
to mean all changes are fair g
Sounds good to me.
On Wed, Apr 6, 2011 at 8:47 AM, Jody Garnett wrote:
> The gt-svgsupport class has been hanging out in "demo" forever. Now that we
> have this unsupported directory can we move it over and document the silly
> thing?
>
> --
> Jody Garnett
>
>
>
> ---
The gt-svgsupport class has been hanging out in "demo" forever. Now that we
have this unsupported directory can we move it over and document the silly
thing?
--
Jody Garnett
--
Xperia(TM) PLAY
It's a major breakthrough
Steve you may want to start a jira issue on this subject; we do have a users
list for general discussion . This list is primarily devoted to developing the
library.
--
Jody Garnett
On Wednesday, 6 April 2011 at 11:31 PM, Steve Way wrote:
> Hi All,
>
> Maybe this is an issue with RC2, but I s
Hi All,
Maybe this is an issue with RC2, but I seem to have a major issue when
re-projecting data from BNG to ETRS:1989.
Attached will show you the issue, first Screenshot is vector and raster layer
in BNG - which is native. Second will show you Vector and Raster requested in
WGS:84. Third w
Hi, list
It's possible to label polygon vertexs in a FeatureTypeStyle pragmatically ?
Thanks
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it want
21 matches
Mail list logo
