Andrea Aime wrote:
>>> Another option could be to have the build server build with
>>> -Pextensive (shall we rename this to -Pexpensive ;-) ?)
>> +1 for the rename.
>
> I was just joking :)
I know, but it was a good suggestion.
> This Eclipse XSD issue seem relevant as well and it's being discus
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> I'm ok to put up with extensive build time and high memory usage for
>> a short time, provided there are serious plans to address both,
>> one way or the other. GeoTools has already bad rep enough without
>> having to require a server like setu
Gabriel Roldan wrote:
> you're right at pointing a finger at it. I have a suggestion for you.
> Besides upgrading to a newer EMF, the problem with app schema is startup
> time. Once you got the schemas parsed you're good to go with less memory.
> If I remember well, EMFAppSchemaReader does a two st
Andrea Aime wrote:
> I'm ok to put up with extensive build time and high memory usage for
> a short time, provided there are serious plans to address both,
> one way or the other. GeoTools has already bad rep enough without
> having to require a server like setup to build it (512M heap
> mean 600-7
Ben Caradoc-Davies ha scritto:
> Jody Garnett wrote:
>> Not from here; you do have the option of marking tests that are
>> extensive and only engaging them if needed (we use that for some of
>> the really slow tests).
>
> Al the tests together take about two minutes. We intend to reduce this
> su
Hi Andrea,
I created an issue (http://jira.codehaus.org/browse/GEOT-2600) with an attached
patch (includes a test case) for the layer bounds problem. Could you review and
maybe apply it to 2.5.x and trunk? Would be great!
Thanks so far,
Frank
> > And by the way:
> > Strange code found (trunk
That would be great! We need to fix it for GeoServer too. In each case,
Hudson should be consistent with the pom, to avoid unpleasant surprises.
(Even building with -Dall was a nasty trap until I added this to our
builds; too easy to have a local build pass and Hudson fail.)
Justin Deoliveira w
Yes, in modules/unsupported/pom.xml I moved it from its own "app-schema"
profile to the "unsupported" profile activated by -Dall. I performed
this change in r33530, and reverted it in r22531 when the build failed
(presumably because it uses -Dtest.maxHeapSize=256M).
As soon as -Dtest.maxHeapSiz
So I assume this means adding app-schema to the profile which gets
engaged with -Dall ?
Ben Caradoc-Davies wrote:
> I'm assuming that, because app-schema is an approved unsupported module,
> I can include it in the build (once it passes on Hudson). I expect it to
> add about two minutes to the
The reason this was put in there was to tame the build. Before this was
sit getting a build server able to handle the geotools build was a bit
challenging. So I fear if we remove it it will lead to a much less
stable build server. But I am willing to try it out though.
-Justin
Ben Caradoc-Davi
Jody Garnett wrote:
> Not from here; you do have the option of marking tests that are
> extensive and only engaging them if needed (we use that for some of
> the really slow tests).
Al the tests together take about two minutes. We intend to reduce this
substantially with some refactoring in the n
Not from here; you do have the option of marking tests that are
extensive and only engaging them if needed (we use that for some of
the really slow tests). Care should be taken to check tests are
isolated into OnlineTests if they hit other web services etc...
Jody
On Thu, Jul 9, 2009 at 1:04 PM,
Client properties on simple attributes aren't encoded
-
Key: GEOT-2607
URL: http://jira.codehaus.org/browse/GEOT-2607
Project: GeoTools
Issue Type: Bug
Components: ext xml-xsd
Ben Caradoc-Davies wrote:
> I can't figure out why app-schema fails to build on Hudson.
Justin, I think I found the problem:
http://hudson.opengeo.org/hudson/job/geotools-trunk/1792/consoleText
[gt_trunk] $ /opt/actual/apache-maven-2.1.0/bin/mvn -U clean install
-Djava.awt.headless=true -Dtest.m
I'm assuming that, because app-schema is an approved unsupported module,
I can include it in the build (once it passes on Hudson). I expect it to
add about two minutes to the build time. We are working to reduce this.
Any objections?
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration
Justin Deoliveira wrote:
> 32 bit. Indeed a hudson set up on a 64 bit JVM would be nice.
Help!
I can't figure out why app-schema fails to build on Hudson. I know it
uses huge amounts of memory in a 64-bit JVM, but it seems fine on our
32-bit continuous integration engine. I think it would be ve
32 bit. Indeed a hudson set up on a 64 bit JVM would be nice.
Ben Caradoc-Davies wrote:
> I can't get app-schema to build on Hudson. I had to kick it out. Is
> Hudson running a 32 or 64 bit JVM?
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1793/changes
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applicat
I can't get app-schema to build on Hudson. I had to kick it out. Is
Hudson running a 32 or 64 bit JVM?
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
---
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1792/changes
Changes:
[bencaradocdavies] Enabled app-schema in the build (alongside the other
unsupported modules built with -Dall)
[bencaradocdavies] Removed registered function support from app-schema.
Disabled gt-jdbc-regfunc module.
A big +1 here. We are already spread pretty thin in GeoTools in terms of
developer resources vs number of modules so sharing maintainence burden
with another community outweighs any edge that the code that is sitting
unmaintained at the moment might have.
And as Andrea states what they have is
Ben Caradoc-Davies wrote:
> Andrea Aime wrote:
>> Given we use EMF bindings this _might_ be relevant
>
> Thanks, Andrea. I am sure it is relevant. We use an ancient EMF, and I
> am pointing the finger squarely at it.
>
Indeed, faster EMF would be nice. I will throw it on the TODO list of
thing
Hi again
The software from which the CRS is coming from is Terralib
(http://www.terralib.org/), for which we have developped a GeoTools
DataStore (we intend to release it to the GeoTools community as soon as
it is ready to go). The library is C++ by the way, we made the plugin
using JNI.
In r
Milton Jonathan ha scritto:
> Hello again, and thanks a lot for the fast feedback!
>
> Well, in my really humble opinion, if the guy stated that the code is
> EPSG:6618, then that is what he wants, regardless of any imprecisions in
> the WKT. If he wanted something else, why put the code?
>
> L
Hello again, and thanks a lot for the fast feedback!
Well, in my really humble opinion, if the guy stated that the code is
EPSG:6618, then that is what he wants, regardless of any imprecisions in
the WKT. If he wanted something else, why put the code?
Looking at things from my perspective, I th
Hi lists,
The ImageIO-Ext 1.0.3 version have been released.
Major changes are:
- Added Kakadu support (A R/W plugin leveraging on the Kakadu driver via
JNI)
- Added DOQ1 and DOQ2 support (2 new plugins leveraging on GDAL).
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are
availa
Hi Ben,
Ben Caradoc-Davies wrote:
> Andrea Aime wrote:
>> Given we use EMF bindings this _might_ be relevant
>
> Thanks, Andrea. I am sure it is relevant. We use an ancient EMF, and I
> am pointing the finger squarely at it.
you're right at pointing a finger at it. I have a suggestion for you.
Be
Milton Jonathan ha scritto:
> 1b. This issue has other consequences. Since many such object
> comparisons seem to ignore the EPSG code, I have the following problem:
> a WKT was generated where the numbers were printed with only a certain
> level of precision, making the WGS84 SPHEROID's inverse
Hey Andrea
Thanks a lot for the feedback. I wish to apologize for not sending a new
e-mail yesterday with what I was finding out.
Turns out that, yeah, when I came back the next morning, this exact WKT
was working (but not the real one I'm getting in my system here). I must
have messed somethi
ArrayIndexOutOfBoundsException in ShapefileRenderer
---
Key: GEOT-2606
URL: http://jira.codehaus.org/browse/GEOT-2606
Project: GeoTools
Issue Type: Bug
Components: ext shapefilerender
Milton Jonathan ha scritto:
Hi there
Once again, the axis issue attacked me :P. I guess this may have
something to do with changes from 2.5.x to 2.6.x (has LONGITUDE_FIRST
become the default now?).
The situation is like this: I have a (valid) WKT generated for a
Projected CRS with longitude
Andrea Aime wrote:
> Given we use EMF bindings this _might_ be relevant
Thanks, Andrea. I am sure it is relevant. We use an ancient EMF, and I
am pointing the finger squarely at it.
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Di
Jody Garnett ha scritto:
> Andrea has done a good job setting up a collaboration opportunity for
> us with the deegree team. Looks like there is an IRC breakout meeting
> later today:
> -
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=7&day=8&hour=9&min=30&sec=0&p1=215
I cant make this meeting at short notice, but I'd like to express my
support for the idea of collaboration.
The similarities between Deegree and Geoserver lead to quite
reasonable questions of "which horse do I back", which may result in
failure to commit to anything - having a collaboration makes
34 matches
Mail list logo
