Axe it!
On Thu, May 29, 2014 at 1:22 AM, Jody Garnett wrote:
> I think we should kill "spike" as well :)
>
> Jody Garnett
>
>
> On Thu, May 29, 2014 at 5:22 PM, Jody Garnett wrote:
>
>> it is yours, kill it.
>>
>> Jody Garnett
>>
>>
>> On Thu, May 29, 2014 at 5:09 PM, Andrea Aime <
>> andrea.a..
I think we should kill "spike" as well :)
Jody Garnett
On Thu, May 29, 2014 at 5:22 PM, Jody Garnett wrote:
> it is yours, kill it.
>
> Jody Garnett
>
>
> On Thu, May 29, 2014 at 5:09 PM, Andrea Aime > wrote:
>
>> Hi,
>> as the subject says, shall we drop the axe on unupported shapefile-old
>>
it is yours, kill it.
Jody Garnett
On Thu, May 29, 2014 at 5:09 PM, Andrea Aime
wrote:
> Hi,
> as the subject says, shall we drop the axe on unupported shapefile-old
> module?
>
> Cheers
> Andrea
>
> --
> ==
> Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
> for more inform
Hi,
as the subject says, shall we drop the axe on unupported shapefile-old
module?
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Mass
okay that's good to know. Thanks Andrea.
On Tue, Oct 25, 2011 at 4:27 AM, Andrea Aime
wrote:
> On Tue, Oct 25, 2011 at 2:13 AM, Gabriel Roldan wrote:
>
>> I'm getting the bellow failure when building trunk (r38273) locally, but
>> hudson seems not to be complaining.
>> Is anyone else getting it?
On Tue, Oct 25, 2011 at 2:13 AM, Gabriel Roldan wrote:
> I'm getting the bellow failure when building trunk (r38273) locally, but
> hudson seems not to be complaining.
> Is anyone else getting it?
>
We got it some time ago in another test using the same dataset.
It's a file system iteration orde
I'm getting the bellow failure when building trunk (r38273) locally, but
hudson seems not to be complaining.
Is anyone else getting it?
mvn -U clean install -Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall
org.geotools.process.feature.gs.FeatureGSProcessFactoryFactoryTest
Tests run: 1, Fai
/Users/jody/java/geotools/release/modules/plugin/imagepyramid/target/surefire-reports
I also had a couple of the new raster tests stop the "mvn
-Pextensive.tests,interactive.tests install" build which was a pain as it
prevented it running overnight.
Here is the failure for image pyramid:
j
That is really weird. It looks like the sort of failures you get on
Windows when something else has the file open. Can you please manually
delete the file (mvnn clean would be good) and make sure nothing else
has it open? Might be TortoiseSVN or even a virus scanner. Because this
is a temporary
Ben- regarding your question as to test failures: I'll reply separately
for the geotools and geoserver failures on the appropriate lists.
Ironically, it is my AppSchemaFileDataTest that is giving errors. Here
is the sure-fire report
--
The build schedule is the following
geoserver-trunk,geoserver-2.x, geotools-trunk, geotools-2.6.x with
java 5 and java 6,32 and 64 bit giving a total of 16 build attempts
(mostly unsuccessful) every day.
SUN SDK is used Monday and Thirsday
IBM SDK is used Tuesday and Friday
OPEN JDK (only jav
On 14/09/10 13:59, Andrea Aime wrote:
> Sigh, that was my fault, sorry.
> Was on a notebook on foss4g and only had java 6, did not notice.
> I assumed the build bot would catch any issue, but it did not happen.
This was bound to happen to developers making many commits. :-)
> Btw, dreaming aloud
On 14/09/10 20:03, Justin Deoliveira wrote:
> Ben any chance we can get your builtbot to email the developer list when a
> build fails? It would be nice in cases like these where the primary build
> server misses stuff. Although I admit you serve has a pretty effective proxy
> for your build bot
Very strange. I remember setting up the new hudson to use java 5 for the
builds. But looking now that config is gone... Anyways, minus the demons on
the build server playing tricks on me the intention has always been to
compile java 5 as our baseline. So I will change it back.
Ben any chance we ca
Ben Caradoc-Davies ha scritto:
> The GeoTools trunk build has been failing under Java 5 since r36183 when
> the Java 6 API was used in:
> modules/library/render/src/main/java/org/geotools/renderer/style/ShapeMarkFactory.java
>
> This was a trivial API change: Java 6 added methods taking double ar
The GeoTools trunk build has been failing under Java 5 since r36183 when
the Java 6 API was used in:
modules/library/render/src/main/java/org/geotools/renderer/style/ShapeMarkFactory.java
This was a trivial API change: Java 6 added methods taking double args.
The fix was similarly trivia (conver
Simone Giannecchini ha scritto:
> Thx,
> I have not done any port to trunk for this work since there are a few
> things that I want to improve a bit more.
Your last commit seems to have fixed the build error
Thanks!
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straig
perfect.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - 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://s
Simone Giannecchini ha scritto:
> Thx for reporting, going to look into it.
> Are you running this on ubuntu 9.04?
Yes:
Ubuntu 9.04 with ext4 fs
Java HotSpot(TM) Server VM (build 1.5.0_18-b02, mixed mode)
JAI and JAI ImageI/O extensions installed
Btw, the same module builds fine on trunk
Cheers
A
Thx,
I have not done any port to trunk for this work since there are a few
things that I want to improve a bit more.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
p
Thx for reporting, going to look into it.
Are you running this on ubuntu 9.04?
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 058
Hi all,
I'm experiencing a consistent build failure on my box
on 2.5.x with imagemosaic.
The failure is:
Failed tests:
crop(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
alpha(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
defaultParameterValue(org.geotools.gce.imagemosaic.Ima
Sorry about the problem,
in one or two weeks, we should have a first cut of a more stable
release of imageio-ext since we are going to fuse with another project
in order to get more plugins; we have to finish some work on JPEG2000
first then we'll branch.
More newsd soon.
Simone.
On Fri, May 2, 2
Hi,
mmm... During a slight arcGrid refactoring, I indeed talked with Simone
about keep using StringBuffer instead of 1.5 StringBuilder to let arcGrid
plugin be compatible with GeoTools 2.4.
I was pretty sure to use StringBuffer on ImageIO-ext to be compatible with
GeoTools 2.4 requirements but howe
Hi,
I'm trying to build gt2 2.4.x and I'm getting the following errors:
---
Test set: org.geotools.gce.arcgrid.ArcGridReadWriteTest
---
Tests run:
That would be me; I am on it :-S Sad I am not having a good build week.
Jody
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
trunk/modules/library/main/src/main/java/org/geotools/data/DefaultResourceInfo.java:[54,2
> confirmed, it works, thank you. Wondering, wouldn't it be better to
> include spatialdbbox in geotools?
Cool. and yes. The reason its third party at the moment is because it
was originally part of the project started by david blasby. But the part
used by h2 is so small and simple that we could e
Justin Deoliveira ha scritto:
> Hi Andrea,
>
> You were right.. I updated the spatial functions and that caused an
> incompatibility. If you clean, and rebuild h2 with -U it should work now.
confirmed, it works, thank you. Wondering, wouldn't it be better to
include spatialdbbox in geotools?
>
Hi Andrea,
You were right.. I updated the spatial functions and that caused an
incompatibility. If you clean, and rebuild h2 with -U it should work now.
Also... are you still having other failures you were before? I found
another issue in that module that only came up in windows. i fixed that
as
Confirmed For some reason the build server has not kicked in since last
night... strange. Regardless I am looking into this now.
-Justin
Andrea Aime wrote:
> Hi,
> I'm facing quite a few failures in the h2 module...
> I tried doing a mvn -U clean install but that did not help,
> I'm still gettin
Hi,
I'm facing quite a few failures in the h2 module...
I tried doing a mvn -U clean install but that did not help,
I'm still getting 1 failure and 6 errors.
It seems there are some custom functions that aren't getting registered
properly in h2, or something like that.
I've attached the relevant
Hmm... yeah i have been hacking the filter capabilities interfaces on
geoapi trunk. Seems someone must have done a deploy. I will commit my
changes to geotools trunk shortly.
Martin Desruisseaux wrote:
> Compilation fails on trunk in main module. It seems to be related to new
> abstract methods re
Compilation fails on trunk in main module. It seems to be related to new
abstract methods recently added in GeoAPI FilterFactory interface, but not yet
implemented in GeoTools. Does anyone know more about this FilterFactory
interface change?
Martin
With my luck this is going to be another one of those random file lock
problems:
> Test set: org.geotools.renderer.shape.ShapeRendererTest
> ---
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.296
> se
Hi there,
i just downloaded the gt2-2.4-M3 version, i would like to parse a GML
file to get the FeatureCollection,
after adding the libraries in my classpath i tried to execute this piece
of code:
InputStream input = new FileInputStream(new File(gmlFile));
Configuration co
Okay so that idea works; I will wait to commit until we have punted the
idea around in the IRC meeting.
Andrea Aime wrote:
>> long time = System get time in milliseconds
>> do {
>>Thread.sleep( 15 );
>> } while( time == System get time in milliseconds );
>>
>> May be a "Faster" alternative to
Jody Garnett ha scritto:
> Good detective work ... I am wonder (if this is a test of memory
> datastore) what can possibly be going on... oh wait the feature is
> locked for a Duration.
>
> The lock is only checked when it is tested, so the check should be
> stable regardless of what is going o
Good detective work ... I am wonder (if this is a test of memory
datastore) what can possibly be going on... oh wait the feature is
locked for a Duration.
The lock is only checked when it is tested, so the check should be
stable regardless of what is going on oh I guess we do need to wait
Andrea Aime a écrit :
> Long story short, I do believe that increasing that 50ms sleep
> to something like 200ms may cure the issue we're seeing.
> Martin, can you try that?
It worked (actually I got a random test failure elswhere in the same class -
running "mvn install" again fixed that), but it
Jody Garnett ha scritto:
> What kind of hardware do you run these days? Multi core?
Jody, the test that is failng is:
public void testGetFeatureLockingExpire() throws Exception {
FeatureLock lock = FeatureLockFactory.generate("Timed", 1);
FeatureLocking road = (FeatureLocking)
Jody Garnett a écrit :
> What kind of hardware do you run these days? Multi core?
No, monocore. A 3 years old latop with Pentium 4 on Gentoo.
> The tests have not been changed to my knowledge - near as I can tell
> they are reporting actual locking failures. Please note I have
> refactored the t
What kind of hardware do you run these days? Multi core?
The tests have not been changed to my knowledge - near as I can tell
they are reporting actual locking failures. Please note I have
refactored the tests last year (so the variable names are transaction1
rather than t1) so people should be
Jody Garnett a écrit :
> That does sound bad - Martin you did not accidentally upgrade to maven
> 2.0.6 did you? This was the kind of problem that pushed me back ...
I'm using Maven 2.0.6 for a few months. But the error that I reported was on
Continuum (on my machine too at random occurence, but i
Andrea Aime wrote:
> This is bad, but I don't think it's your fault.
> Developers, did anyone touched memory data store or locking related
> stuff lately? The only change I see on main was made by chorner
> yesterday, but I don't know if it's relevant (does the memory data store
> use the filter
That does sound bad - Martin you did not accidentally upgrade to maven
2.0.6 did you? This was the kind of problem that pushed me back ...
Jody
Andrea Aime wrote:
> Martin Desruisseaux ha scritto:
>
> This is bad, but I don't think it's your fault.
> Developers, did anyone touched memory data
I assume this is testing our ability to handle concurrent access ... I
sometimes get random failures (usually on windows) when two threads are
attacking a shapefile.
In each and every case Jesse went in and looked at the "lock" code and
sorted things out...
I think this is "just" an honest pro
For information the test failure on Continuum is:
---
Test set: org.geotools.data.memory.MemoryDataStoreTest
---
Tests run: 37, Failures: 1, Error
Martin Desruisseaux ha scritto:
> Continuum a écrit :
>> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/878
>
> Does anyone have any idea what is going on with those locking tests? Those
> tests
> fail randomly quite often!! I had t
Continuum a écrit :
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/878
Does anyone have any idea what is going on with those locking tests? Those tests
fail randomly quite often!! I had to launch "mvn install" 4 times with absolutl
AUTO doesn't work on my Macintosh but AUTO2 does work... Something is
fishy here. What versions are people using. I tested with the OSX
Java 5.
Jesse
On May 7, 2007, at 9:24 PM, Jody Garnett wrote:
> Changing the test case to confirm the presense of AUTO (rather than
> AUTO2) seems to work
Jody Garnett a écrit :
> Changing the test case to confirm the presense of AUTO (rather than
> AUTO2) seems to work in all cases (and all machines). I am not sure why
> "AUTO2" no longer registers? But I can confirm that the factory we are
> trying to check is around (the same factory acts for both
Changing the test case to confirm the presense of AUTO (rather than
AUTO2) seems to work in all cases (and all machines). I am not sure why
"AUTO2" no longer registers? But I can confirm that the factory we are
trying to check is around (the same factory acts for both AUTO and AUTO2
as far as I
Very odd ... looking at the unit test in question it is a check to
ensure that "AUTO2" is found.
Cheers,
Jody
> Hi Martin - I have been able to verify the error on one machine:
>
> Windows Vista, Maven 2.0.5, Java 6:
>
>> C:\java\geotools\trunk\modules\library\referencing\target\surefire-repo
Hi Martin - I have been able to verify the error on one machine:
Windows Vista, Maven 2.0.5, Java 6:
> C:\java\geotools\trunk\modules\library\referencing\target\surefire-reports>more
>
> org.geotools.referencing.factory.AllAuthoritiesFactoryTest.txt
>
I'm using Maven v 2.0.5 and Java 5. I'm new to Maven so I'm not sure
how to get a stack trace.
Graham.
Martin Desruisseaux wrote:
>Graham Davis a écrit :
>
>
>>Running org.geotools.referencing.factory.AllAuthoritiesFactoryTest
>>Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed
Graham Davis a écrit :
> Running org.geotools.referencing.factory.AllAuthoritiesFactoryTest
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.031
> sec <<< FAILURE!
Any stack trace? Which Maven / JDK version are you using? I have run "mvn
install" many time today with JDK 1.4 wi
Running org.geotools.referencing.factory.AllAuthoritiesFactoryTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.031
sec <<< FAILURE!
--
Graham Davis
Refractions Research Inc.
[EMAIL PROTECTED]
-
This S
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/geotools/Geotools/trunk/modules/unsupported/geometry/src/main/java/org/geotools/geom
I am not on the 2.3.x branch right now - what is the matter here?
> [INFO] Surefire report directory:
> /home/cruise/continuum-1.0.3-alpha/apps/continuum/working-directory/86/maven/javadoc/target/surefire-reports
>
> Error occurred during initialization of VM Could not reserve enough
> space fo
Compilation failure. Symbols not found:
SeRasterAttr
SeRasterBand
SeRasterTile
SeRaster
PeFactory
PeProjectionException
etc...
Martin
-
Take Surveys. Earn Cash. Influence the Future
Hi guys,
the problem is fixed, it was just a problem of colliding names in the
created test-files.
Anyway, what aaime was saying is true. Using FileChannel on big objects is
dangerous on windows
and we should try to avoid using them, especially for shapefiles.
If anyone is ever interested in r
Hi,
building gt2 trunk today I got the following:
GRAVE:
C:\progetti\geotools\trunk\modules\plugin\arcgrid\target\test-classes\org\geotools\gce\arcgrid\test-data\4796arcGrid56672.prj
(Impossibile eseguire l'operazione specificata su un file la cui sezione
mappata dall'utente Þ aperta)
java.io.
Bad maven no cookie! I will figure this out when I get to work (ie just
now).
Cheers,
Jody
> Seems the java 4 profile is including the java 5 modules.
>
> Continuum wrote:
>
>> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/695
>
Okay I have made normal list of Java 1.4 modules; and made seperate
profiles for JDK 1.5 and JDK 1.6 (a bit of duplication in the pom.xml
but what can you do).
Jody
> Seems the java 4 profile is including the java 5 modules.
>
> Continuum wrote:
>
>> http://geo.openplans.org:9090/continuum/ser
Seems the java 4 profile is including the java 5 modules.
Continuum wrote:
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/695
>
> -
> Take Surveys. Earn Cash.
Notice the build is still down. Are there more chagnes to still come across?
-Justin
Continuum wrote:
> http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/638
>
>
Thanks god Martin you found it :-). I was getting desperate about this
build error since I was not able to reproduce it in any ways. Let me
know exactly wht that is so that I avoid similar errors in the future.
Simone.
On 11/21/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> This is a locale
I would like to backport bug fixes (including http://jira.codehaus.org/browse/GEOT-935) from trunk
to the 2.2 branch. But I can't build the 2.2 branch right now. Surefire test report attached
Martin
---
Battery:
I got the attached failures in JUnit test suite. I'm not sure that it is not caused by pending
changes in my local copy, but I don't think so.
Martin.
---
Test set: org.geotools.gce.imagemosaic.ImageMosaicReaderT
Surefire report attached.
Martin.
---
Test set: org.geotools.gce.imagemosaic.ImageMosaicReaderTest
---
Tests run: 7, Failures: 0, Errors:
I got test failures in FidQueryTest. Does anyone has some tips about what is
going on?
http://maven.geotools.fr/reports/shape/surefire-report.html#org.geotools.data.shapefile.indexedFidQueryTest
Martin.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff
Hmm it build on my box today without any problems. I will look into
it and make try it out on another machine to make sure I don't have
strange jars or some such thing.
Jesse
On 29-Jun-06, at 8:49 PM, Martin Desruisseaux wrote:
> Report there:
>
> http://maven.geotools.fr/reports/wfs/surefi
Report there:
http://maven.geotools.fr/reports/wfs/surefire-report.html
Martin.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based
gt/module/render/src/org/geotools/renderer/lite/LiteShape2.java:[62,16] cannot
find symbol
symbol : class LineIterator2
location: class org.geotools.renderer.lite.LiteShape2
---
Using Tomcat but need to do more? Need to support web services,
module/main/src/org/geotools/styling/StyleFactoryImpl.java:[148,19]
cannot find symbol
symbol : method
setFeatureTypeConstraints(org.geotools.styling.FeatureTypeConstraint[])
location: interface org.geotools.styling.LayerFeatureConstraints
Martin.
> >gt2:main cleaned, compiled
> We have a compilation error in the test suite in the main module:
> .../VisitorCalculationTest.java:[327,8]
> cannot find symbol
> symbol : class QuantileListVisitor
> location: class org.geotools.feature.visitor.VisitorCalculationTest
> ...
My apologies... it
GeoTools2 module build report 20051224
gt2:referencing cleaned, compiled, tested, INSTALLED 2356
gt2:coverage cleaned, compiled, tested, INSTALLED 2356
gt2:api cleaned, compiled, tested, INSTALLED 2356
gt2:main cleaned, compiled
We have a compilation error in the test suite in t
Jody and I fixed that about 30 seconds after we committed, but it looks
like we forgot to commit the fix... will get that cleaned up as soon
as svn is back up.
Cheers,
Cory.
Justin Deoliveira wrote:
I beleive cory and jody were doing some work in this module.
-Justin
Martin Desruisseaux
I beleive cory and jody were doing some work in this module.
-Justin
Martin Desruisseaux wrote:
I get one compilation error in the test suite:
gt/plugin/postgis/test/org/geotools/data/postgis/collection/PostgisFeatureCollectionOnlineTest.java:49:
class PostgisFeatureCollectionTest is public,
I get one compilation error in the test suite:
gt/plugin/postgis/test/org/geotools/data/postgis/collection/PostgisFeatureCollectionOnlineTest.java:49:
class PostgisFeatureCollectionTest is public, should be declared in a
file named PostgisFeatureCollectionTest.java
It seems to be just a matte
The content of META-INF has been deleted, including services
registration, which of course cause test failures. I assume that it is
accidental? I someone working on rooling back the "filterfunction" commit?
Martin.
---
This SF.Net em
82 matches
Mail list logo
