>> I built GeoTools trunk recently (for the OSGi project we are trying to
>> set up with Jody) on a OpenJdk 6 b16 on CentOS 5.5 x86_64 and it went
>> very smoothly.
>
> Did you build with -Dall?
he, he, no I didn't.
I have no time to do it right now, but I'll give it a try later.
On 04/06/10 19:27, Mathieu Baudier wrote:
> I built GeoTools trunk recently (for the OSGi project we are trying to
> set up with Jody) on a OpenJdk 6 b16 on CentOS 5.5 x86_64 and it went
> very smoothly.
Did you build with -Dall?
>> is stupidly dependent on hash iteration order, though other time
Christian, you are a champion. I was sure it was your Hudson with spaces
in the build path. Well done.
On 07/06/10 16:47, christian.muel...@nvoe.at wrote:
> Do you have a blank in your build path. ?
>
> Exception in thread "main" java.lang.NoClassDefFoundError: 32/tmp
>
> The absolute path is
>
>
+1
On 04/06/10 17:18, Andrea Aime wrote:
> 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
>
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and Resource Eng
On 04/06/10 22:12, Joachim Van der Auwera wrote:
> Considering that java5 is still just the previous version (even if it is
> already a couple years old),
Six years.
> I would not require java6 unless there is a
> very compelling reason.
(1) It is a pain in the arse to get the Java 5 JDK.
(2) Op
On 7 June 2010 18:53, Andrea Aime wrote:
>
> Aha, I see, so it's a legitimate bug.
> Sigh... that module has no maintainer...
>
I could put my hand up for the maven/javadoc module. I got to know it
when getting the @source tag processing to work.
I'm happy to stand back if there are any other vo
christian.muel...@nvoe.at wrote:
> Do you have a blank in your build path. ?
>
> Exception in thread "main" java.lang.NoClassDefFoundError: 32/tmp
>
> The absolute path is
>
> "/home/hudson 32/tmp"
>
> I am sure if I remove the blank, this bug will disappear. But I can
> remember that it was a
Do you have a blank in your build path. ?
Exception in thread "main" java.lang.NoClassDefFoundError: 32/tmp
The absolute path is
"/home/hudson 32/tmp"
I am sure if I remove the blank, this bug will disappear. But I can
remember that it was a wish to have blanks in the build path.
The 64 bit
Just had a quick look at the users' poll to see if anyone had voted.
11 votes in so far with more for than against.
Michael
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MAS
Andrea Aime wrote:
> christian.muel...@nvoe.at wrote:
>> This is an interesting thread, so I want to spend my 2 cents.
>>
>> 1) I am astonished about discussing to check a build on SUN SDK 6
>>
>> http://gis.linux4all.at/hudson32
>> http://gis.linux4all.at/hudson64
>>
>> Everybody can look at it, d
christian.muel...@nvoe.at wrote:
> This is an interesting thread, so I want to spend my 2 cents.
>
> 1) I am astonished about discussing to check a build on SUN SDK 6
>
> http://gis.linux4all.at/hudson32
> http://gis.linux4all.at/hudson64
>
> Everybody can look at it, developers knowing the cred
-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
This is an interesting thread, so I want to spend my 2 cents.
1) I am astonished about discussing to check a build on SUN SDK 6
http://gis.linux4all.at/hudson32
http://gis.linux4all.at/hudson64
Everybody can look at it, developers knowing the credentials from the
official hudson build server c
>
>> is stupidly dependent on hash iteration order, though other times
>> there are less obvious issues).
>
> Yes, we had this as well and ended up hacking the unit tests to check
> which version we are running. A bit ugly but I did not find any better
> solution.
>
I would recommend checking the
2010/6/5 Andrea Aime :
> 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 muc
Jody Garnett ha scritto:
> Workspace issues also cuts the other way; when I am handed a machine at work
> it comes with Java 6 installed. And I have to go out of my way (and now
> further out of my way) in order to find a Java 5 SDK to compile geotools
> against.
>
> Truth be told I just run Ja
ue out in the foreseeable and will be 2 versions old by then.
>>
>> After a while, people look at technology and think of it as stale if it has
>> not been kept up with the pace.
>>
>> -Original Message-----
>> From: lim goh [mailto:cl...@student.cs.uwaterloo
On 5 June 2010 16:39, Andrea Aime wrote:
> Michale, you're the users list master, if you feel like asking, just
> go ahead :-p
>
Phooey - I've never mastered anything :-) But I will ask them...
Michael
--
ThinkGeek and
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
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
e, people look at technology and think of it as stale if it has
> not been kept up with the pace.
>
> -Original Message-
> From: lim goh [mailto:cl...@student.cs.uwaterloo.ca]
> Sent: 04 June 2010 16:13
> To: geotools-devel
> Subject: Re: [Geotools-devel] Informal poll:
has not
been kept up with the pace.
-Original Message-
From: lim goh [mailto:cl...@student.cs.uwaterloo.ca]
Sent: 04 June 2010 16:13
To: geotools-devel
Subject: Re: [Geotools-devel] Informal poll: how good are we for a switch to
Java 6 now?
I'm also a +1 just to clarify.
I thi
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
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
-
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.
-
36 matches
Mail list logo
