Michael Bedward ha scritto:
>> Thanks Justin that is beautiful :-)
>>
>
> What Jody said. Much appreciated Justin.
Justin++ (ah, these new programming languages, they
just on keep popping up...)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from
Michael Bedward ha scritto:
> I agree with the points that Justin has made. The codebase is a much
> bigger hurdle for prospective developers than the Java version and I
> think it's extremely important to be mindful of what our users'
> constraints are. There's not much point "embracing change" (y
> Thanks Justin that is beautiful :-)
>
What Jody said. Much appreciated Justin.
Michael
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental
I agree with the points that Justin has made. The codebase is a much
bigger hurdle for prospective developers than the Java version and I
think it's extremely important to be mindful of what our users'
constraints are. There's not much point "embracing change" (yuk) if it
results in a shrinking use
Thanks Justin that is beautiful :-)
Jody
On 05/06/2010, at 8:13 AM, Justin Deoliveira wrote:
> is up and running. geotools.org is pointing it for documentation.
>
> The docs showcase the stable docs with a link to the trunk docs at the
> bottom.
>
> Let me know what you think.
>
> The follow
Trunk, if someone has a moment they can copy the property file back to 2.6.x.
For the next month my intension is to work very hard on 2.7; not all of the
changes will be back-ported.
Jody
On 05/06/2010, at 1:14 AM, Joachim Van der Auwera wrote:
> Jody,
>
> In which version was this updated?
>
is up and running. geotools.org is pointing it for documentation.
The docs showcase the stable docs with a link to the trunk docs at the
bottom.
Let me know what you think.
The following hudson jobs will continually update the docs on the site.
http://hudson.opengeo.org/hudson/view/geotools/jo
These are pretty strong statements. Noone is saying that users should
not use Java 6 or 7 if they choose. Indeed they get the performance
benefits by doing so.
The decision here is whether moving to Java 6 for development
convenience is worth no longer supporting Java 5. There is nothing
stopp
I am also a +1 for this.
I think we need to be technology leaders in this area.
Users who have a stable production environment will be sticking with that
particular version of geotools anyway, and will not constantly upgrade (unless
bug fix). When a production environment has an upgrade path,
JP2KReader should not depend on Kakadu to get the UUIDBox
-
Key: GEOT-3135
URL: http://jira.codehaus.org/browse/GEOT-3135
Project: GeoTools
Issue Type: Improvement
Components:
Jody,
In which version was this updated?
Thanks,
Joachim
On 06/04/2010 04:43 PM, Jody Garnett wrote:
> Got a refresh of codes from epsg-hsql (thanks andrea) and combined with the
> custom codes we had defined.
>
> Number of codes went from 2799 up to 4770!
>
> Jody
> ---
A bit more action on the GMLEncoder front today.
We have access to the fast Transformer (is this legacy?)
GMLEncoder encode = new GMLEncoder( out, Version.GML2 );
encode.setNamespace("location", "http://localhost/location.xsd";);
encode.setLegacy(true);
encode.encode(
I'm also a +1 just to clarify.
I think IT should upgrade when they should. Not upgrading due to IT
issues are very sad though definitely understandable.
I'm very sure all of us are essentially saying what Justin said about
mixed feelings, it is clearly:
1. We should upgrade to the new default +1
Got a refresh of codes from epsg-hsql (thanks andrea) and combined with the
custom codes we had defined.
Number of codes went from 2799 up to 4770!
Jody
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad
Justin Deoliveira ha scritto:
> I have mixed feelings about this one. I definitely agree that it is a
> pain to require developers to use java 5 when java 6 is the new default.
>
> But I also know there exist users that can't make the shift in an
> organization because IT requires them to use an
I have mixed feelings about this one. I definitely agree that it is a
pain to require developers to use java 5 when java 6 is the new default.
But I also know there exist users that can't make the shift in an
organization because IT requires them to use an older java version.
All in all I would
-1
I fear a lot of servers haven't upgraded to java6 yet, so this would
make inclusion in some applications problematic.
Considering that java5 is still just the previous version (even if it is
already a couple years old), I would not require java6 unless there is a
very compelling reason.
That
So thus far I am the only +1 :-P
> Eh, OpenGeo wise we're kind at the end of the rope for the Hudson build
> server, we can hardly host any other build, disk space is exhausted.
I was more thinking of leaving Hudson exactly the way it is; just changing our
policy. Ie allow volunteers to use Ja
Jody Garnett ha scritto:
>>From the uDig stand point am fine with upgrading to Java 6.
>
> I with you on the need to make it easy for developers to contribute to the
> project; open source projects feed on volunteers after all.
>
> Could we do a trial on Java 6 with the following conditions:
> -
>From the uDig stand point am fine with upgrading to Java 6.
I with you on the need to make it easy for developers to contribute to the
project; open source projects feed on volunteers after all.
Could we do a trial on Java 6 with the following conditions:
- allow 2.7.x to be build with Java 6
-
There are a large number of other "Collection" methods; are there any more
candidates for removal?
A couple weeks ago I mentioned the add/remove listener methods as something
that is just not implemented.
Jody
On 04/06/2010, at 6:31 PM, Michael Bedward wrote:
> On 4 June 2010 17:58, Jody Garne
I personally had trouble downloading Java 5 when I wanted to start
working on Geotools.
I think when we are using technologies like Java, we should be
prepared to follow through the leadership of the owner of the
technology.
We don't have to immediately switch, of course, but when Java 5 is
already
+0
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.
> Grabbing a JDK 5 today requires quite some extra jumps in the downloads,
very true, and it has become even harder since Oracle's purchase of Sun
> and we formally support building only against Java 5, by this
> meaning Java 6 builds might actually fail (sometime a unit test
I built GeoTools tr
Mathieu Baudier ha scritto:
> To put it short: I would really analyze closely whether the benefits
> of dropping Java 5 support go beyond the "comfort" of some new Java 6
> features, because such a switch is easy to do in a development setting
> but can cause a lot of headache when deploying.
Rig
> quick informal poll. What about switching the current trunk to Java 6?
> Would you be pro? Against? Don't care?
We have started only very recently to use GeoTools (and we love it!)
and I'm not a contributor to this project, so I will just speak from a
general experience in Java in an enterprise
+0 for me I think.
I'd be +1 except that I know it will leave behind anyone using OSX on
older mac hardware (32 bit) for which Apple has failed to provide Java
6.
Michael
--
ThinkGeek and WIRED's GeekDad team up for the
Hi,
quick informal poll. What about switching the current trunk to Java 6?
Would you be pro? Against? Don't care?
I would be pro.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
-
On 4 June 2010 17:58, Jody Garnett wrote:
> Took a run at deprecating the methods that have anything to do with iterator:
> - iterator()
> - close( Iteator )
> - close( FeatureIterator )
> - purge() // was already deprecated and could be removed
>
Cool ! Thanks Jody. I love it when things get si
Took a run at deprecating the methods that have anything to do with iterator:
- iterator()
- close( Iteator )
- close( FeatureIterator )
- purge() // was already deprecated and could be removed
On 04/06/2010, at 5:32 PM, Michael Bedward wrote:
> Thanks both for the explanations.
>
> Is there any
So this makes two things to clean up?
- FeatureCollection.iterator() to be deprecated
- FeatureSource.setTransaction( transaction ) to be added
Jody
On 04/06/2010, at 4:21 PM, Andrea Aime wrote:
> Michael Bedward ha scritto:
>> Hi folks,
>>
>> For my (occasional) javadoc editing I'm trying to g
Thanks both for the explanations.
Is there any problem with marking Iterator as deprecated in 2.7 ?
When looking at Jody's FeatureCollection wiki page I though it just
confuses the reader having both.
Michael
--
ThinkGee
32 matches
Mail list logo
