Thanks Brand, I tested here as well but forgot to email the list.
On Fri, Jul 31, 2015 at 9:21 PM Brad Hards wrote:
> I downloaded all the artifacts off the geotools.org (which SourceForge
> redirected me to a mirror in Japan), unpacked them all successfully.
>
> I build the project files (i.e. m
I downloaded all the artifacts off the geotools.org (which SourceForge
redirected me to a mirror in Japan), unpacked them all successfully.
I build the project files (i.e. mvn clean install) for the following
configurations:
- mvn clean install
- mvn clean install -Dall
- mvn clean install -D
I had that when working on the ReferenceEnvelope test cases.
The issue ended up being with any tests that change the settings of the CRS
utility class, because if they do not "undo" this global change then some other
random maven test will fail.
The two popular ways of causing the problem ar
On Tue, May 14, 2013 at 8:23 PM, Frank Warmerdam wrote:
> Perhaps it would be reasonable to log a message or something indicating
> that we have wandered outside the region of "clean invertability" for the
> projection in question.
>
Right, that would be my preference as well.
My only worry is th
Bernard,
I've run into the converse where these tests fail in Eclipse. The problem
seems to relate to some tests needing to be run with assertions disabled
and some confusion with the runtime environment about how this is
controlled. In my case I had to find the Java VM command line arg to
disab
Hello,
in our current project we use a maven setup to manage dependencies and
run unit tests. At some point in development one of our tests stoped
working (we are not sure at what point exactly, so we don't know what
exactly changed). The specific thing failing is a transformation from
cartesian t
On Mon, May 2, 2011 at 3:48 PM, Justin Deoliveira wrote:
> Cool stuff Andrea, I look forward to hearing more about your findings.
Well, it's not that I have much more to add. There is some good stuff in there,
and it's cool to have some tool to "push" us to improve code quality.
> Let me know wh
Cool stuff Andrea, I look forward to hearing more about your findings.
Let me know what you think about integrating it into our primary hudson, or
maybe using a secondary. As you say the build server is doing a lot already
and it sounds like running the tests over the codebase is pretty resource
i
On 04/30/2011 06:24 PM, Andrea Aime wrote:
> On Sat, Apr 30, 2011 at 6:07 PM, Joachim Van der Auwera
> wrote:
>> Cool.
>>
>> Did you do anything special to get this to run? I tried running it on
>> our ci/sonar system a couple of weeks ago but failed.
> This is running on my development machine,
On Sat, Apr 30, 2011 at 6:07 PM, Joachim Van der Auwera
wrote:
> Cool.
>
> Did you do anything special to get this to run? I tried running it on
> our ci/sonar system a couple of weeks ago but failed.
This is running on my development machine, so I just made a manual
maven run.
This is more or le
Cool.
Did you do anything special to get this to run? I tried running it on
our ci/sonar system a couple of weeks ago but failed.
I am a big fan of sonar. Especially the violations drilddown gives a lot
of interesting information. While there are undoubtably a lot of false
positives, most of t
Wow, I want this !
Especially the hints for violations are useful. Really cool !. I take
a deeper look at my imagemosaicJDBC module, interesting hints.
+1 without further comment.
Quoting Andrea Aime :
> Hi all,
> today I had a quick try at Sonar, a tool that computes and publishes
> sof
Hi all,
today I had a quick try at Sonar, a tool that computes and publishes
software metrics aggregating results form tools such as Cobertura,
PMD, FindBugs and the like.
The tool is meant to be used in conjuction with a continout build
system, but just to try it out I had it do a manual run on m
Nevermind, just saw the ubuntu package for it and the result links against
libtiff and all the other image libraries. Cool!
On Mon, Mar 28, 2011 at 8:58 AM, Justin Deoliveira wrote:
>
>
> On Mon, Mar 28, 2011 at 8:44 AM, Andrea Aime > wrote:
>
>> On Mon, Mar 28, 2011 at 4:14 PM, Justin Deoliveir
On Mon, Mar 28, 2011 at 8:44 AM, Andrea Aime
wrote:
> On Mon, Mar 28, 2011 at 4:14 PM, Justin Deoliveira
> wrote:
> > I think it would be fine to install pdiff on the server and have the
> build
> > run those specific tests when it is around. Just as long as it does not
> > become a dependency fo
On Mon, Mar 28, 2011 at 4:14 PM, Justin Deoliveira wrote:
> I think it would be fine to install pdiff on the server and have the build
> run those specific tests when it is around. Just as long as it does not
> become a dependency for setting up a local development I think it is fine.
Yep, if it'
I think it would be fine to install pdiff on the server and have the build
run those specific tests when it is around. Just as long as it does not
become a dependency for setting up a local development I think it is fine.
Just let me know and I will install pdiff on the build server.
On Sun, Mar 2
Ciao Andrea,
I would suggest going for perceptual diff, the problem you have
identified (similarity in images)
is an hard problem to solve per se and I am worried by the fact that
we might be introducing
too much complexity for performing this test, at least unless we find
something java-based that
Hi Andrea and Ian,
I'm following this discussion with great interest. I've also fallen
prey to the difficulty of pixel by pixel comparison across different
platforms in the past.
I'm afraid I don't have any independent suggestions but I'd certainly
support using a tool like PerceptualDiff regardl
On Sat, Mar 26, 2011 at 9:18 PM, Andrea Aime
wrote:
> I think a reasonable way forward could be to start using perceptual diff,
> but encapsulate its usage in a java wrapper that could be evolved
> in portable java code if anybody finds the time to do it.
> But in the meantime we'd at least get so
On Sat, Mar 26, 2011 at 8:28 PM, Ian Turton wrote:
> Some googling threw up glean and Piglit
> (http://www.winehq.org/pipermail/wine-devel/2009-September/078607.html)
> which are in C++ and The Batik tests
> (http://xmlgraphics.apache.org/batik/dev/test.html) which is Java and
> claims to handle v
On 26 March 2011 11:51, Andrea Aime wrote:
> Hi,
> the major bluder in http://jira.codehaus.org/browse/GEOT-3484
> made me think again about how to test map rendering.
>
> So far what we have is largely insufficient, as it's not really comparing
> the maps we're generating wit a known to be good r
Hi,
the major bluder in http://jira.codehaus.org/browse/GEOT-3484
made me think again about how to test map rendering.
So far what we have is largely insufficient, as it's not really comparing
the maps we're generating wit a known to be good result.
I have thought long about this topic and explor
Testing new hudson mail setup
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportuni
Christian Müller a écrit :
> I never succeeded running a "mvn clean install" on an IBM sdk. Can anybody
> notify me if we succeed with sun java 6. Afterwards I will try it with the
> ibm sdk (necessairy for all users running geotools/geoserver in Websphere or
> using geotools on AIX, Linux/ppc o
Maybe we could revert and re-enable the tests? Actually I'm neutral on this
issue, but if I'm understanding right, the tests were disabled for Javadoc
generation? If so, the path of less resistance may be to suffer the javadoc
problems for now and get them solved (as far as referencing is concer
I never succeeded running a "mvn clean install" on an IBM sdk. Can anybody
notify me if we succeed with sun java 6. Afterwards I will try it with the
ibm sdk (necessairy for all users running geotools/geoserver in Websphere or
using geotools on AIX, Linux/ppc or Linux/zOs)
Adrian Custer wri
I've already spent way too much time on this today so I don't want to
get into a long discussion as well.
Right now, to build on Java6, you skip all the tests with
-DskipTests. I disabled the tests in two modules, modules which are
'stable' (i.e. no one should be modifying those modules) and are
s
Adrian Custer ha scritto:
> As per the mail ten seconds later,
>
> tests die in java6, required for java6
> code should not be being modified so tests should not break anew
>
> revert as you will.
Afaik there is a way to make test disabling trigger only on java6,
which is, using a profile
I was trying to say:
tests die in java 6, required for javadoc
while getting geotools building for java 6 seems like a no brainer
anyhow, fixing referencing tests for java 6 seems like a waste of time
given the pending transition to the cleaned version of the base
metadata/referencing code.
Thinking; can we disable these test using a Java 6 profile?
On Mon, Feb 9, 2009 at 10:09 PM, Adrian Custer wrote:
> As per the mail ten seconds later,
>
> tests die in java6, required for java6
> code should not be being modified so tests should not break anew
>
> revert as you will.
>
> --adr
As per the mail ten seconds later,
tests die in java6, required for java6
code should not be being modified so tests should not break anew
revert as you will.
--adrian
On Mon, 2009-02-09 at 22:03 +1100, Jody Garnett wrote:
> Hi Adrian;
>
>
> I watched your commit go by:
> - (9:59:03 P
Hi Adrian;
I watched your commit go by:
- (9:59:03 PM) CIA-21: acuster * r*32439* /trunk/modules/
(library/referencing/pom.xml plugin/epsg-hsql/pom.xml): Build fixes: pull
referencing and epsg-hsql from testing
Something about removing epsh-hsql from testing; we actually like tests here
as it is t
testing
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhe
Andrea Aime ha scritto:
...
> Post at least 3 patches for geotools and some for geoserver as well
> and we'll see to give you commit access so that you can keep the two
> working well in those environment. I'm actually very happy to
> have someone able to work on that one, the more platform we supp
mcr ha scritto:
> Getting the commit access will help a lot. At the moment I am deploying
> geoserver on AIX Boxes and Linux on z/OS will be the next platform. It is
> important to get geotools ibm sdk ready, afterwards I have to focus on
> geoserver which has also some minor bugs in Websphere Appl
Getting the commit access will help a lot. At the moment I am deploying
geoserver on AIX Boxes and Linux on z/OS will be the next platform. It is
important to get geotools ibm sdk ready, afterwards I have to focus on
geoserver which has also some minor bugs in Websphere Application Server
(e.g you
mcr ha scritto:
> I opened a jira as you suggested.
>
> Excluding the ibm sdk means excluding the Websphere App Server platform
> which is the most installed commerical j2ee product. Some times ago I
> discussed with Dave Adler from IBM about deploying geoserver in Websphere
> and i did some tes
I opened a jira as you suggested.
Excluding the ibm sdk means excluding the Websphere App Server platform
which is the most installed commerical j2ee product. Some times ago I
discussed with Dave Adler from IBM about deploying geoserver in Websphere
and i did some tests. It works but some stran
mcr ha scritto:
> Is it possible to test your builds also on an ibm sdk. (All Websphere
> developers would be happy).
GeoTools is built only with Sun JDK 1.4 (2.4.x branch) and Sun JDK 1.5
(trunk). Any other JDK (Sun or not) is not guaranteed to work
> In the trunk there are some some import stat
Is it possible to test your builds also on an ibm sdk. (All Websphere
developers would be happy).
In the trunk there are some some import statements which are sun sdk
specific. The imports are not needed, deleting these lines and the errors
disappear.
A very nasty bug is GEOT_1688 which is very
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Jody Garnett ha scritto:
>> ...
>>> Two ideas:
>>> - you can capture the font handling code by providing a custom
>>> labeler (like we do from uDig) and then just doing normal unit tests
>>> on the labeler to make sure it has collected the expected
Andrea Aime wrote:
> Jody Garnett ha scritto:
> ...
>> Two ideas:
>> - you can capture the font handling code by providing a custom
>> labeler (like we do from uDig) and then just doing normal unit tests
>> on the labeler to make sure it has collected the expected information
> Yeah, that could w
Jody Garnett ha scritto:
...
> Two ideas:
> - you can capture the font handling code by providing a custom labeler
> (like we do from uDig) and then just doing normal unit tests on the
> labeler to make sure it has collected the expected information
Yeah, that could work, thought only for labels
Andrea Aime wrote:
> Some years ago rendering tests were made against simple,
> manually verified exemplars, that is, generated images that
> were stored on disk and then compared pixel by pixel against
> the result of a test render operation. To put it in other words,
> it was checked that the ren
Andrea Aime ha scritto:
...
> Soc is already gone, we'd have to wait for next year.
> As a quick measure of distance, we could do the following. For each
> pixel, extract the R G B A components, make a difference, component
> by component, against the expected value, and sum up the absolute
> value
Andrea Aime ha scritto:
> Rob Atkinson ha scritto:
...
> Yet, the visual comparison could be included in the release producers
> making sure we don't have busted releases like 2.4.3.
Typo: release procedures, not producers
Cheers
Andrea
--
Rob Atkinson ha scritto:
> One could create a index page of output artefacts, for a quick visual
> scan. The human brain is pretty good. If this index page included static
> "expected" samples it would be pretty quick to eyeball.
Hum... one of the major features we want out of a build is to
be h
Hi,
this is a mail I have been meaning to write for quite some time,
the 2.4.3 release issues give me enough reason to take the time
and dump my toughts on a mail.
GeoTools has quite a big problem, we have the rendering modules
(renderer and shapefile-renderer) that have some unit tests, but
none
Hello Jody
Jody Garnett a écrit :
> I had a good chat with my customer on this one; out of that list of
> specific problems I placed on the wiki they are only really concerned
> about three of them...
> 1. Connection leaks
This one may be easy to fix. In FactoryOnOracle constructor, we may invoke
Simone Giannecchini ha scritto:
> Do you think these mailing lists really really hate me?
>
> If you answer NO that will make happy, if I do not hear anything I'll
> think you hate me too! ;-(
Well, I've received your mail and no, I don't hate you :-p
Cheers
Andrea
--
Ciao,
> Well, I've received your mail and no, I don't hate you :-p
>
It's the same for me :-)
so far, I've recieved your e-mail only on the geotools-devel mailing
list
Cheers
Vincent
-
Take Surveys. Earn Cash. Influence
Do you think these mailing lists really really hate me?
If you answer NO that will make happy, if I do not hear anything I'll
think you hate me too! ;-(
Simone.
PS
Be patient, Monday is a bad bad day.
--
---
Eng. Simone Giannecchini
Preside
Andrea Aime a écrit :
> Martin, anything against removing the super constructor calls? Waiting
> for the clover update and the subsequent maven plugin dependency update
> may take long.
Yes, feel free to remove this line.
Martin.
-
Hi,
since cobertura does not seem able to generate aggregate reports
at the moment I decided to try out clover again.
Well, I got two bad results:
* code coverage on main is around 30%!!! Eeek!!!
* clover breaks on the referering module, cannot instrument properly
the Inverse classes in the ref
Cory Horner ha scritto:
> Andrea Aime wrote:
>
>> If you want to try out jalopy with the current settings on a module,
>> go into it and type:
>> mvn -Pjalopy jalopy:format
>>
>> The configuration file is located in the maven/build-configs module
>> (so that it can be shared). Note that I disab
Andrea Aime wrote:
>If you want to try out jalopy with the current settings on a module, go
>into it and type:
>mvn -Pjalopy jalopy:format
>
>The configuration file is located in the maven/build-configs module (so
>that it can be shared). Note that I disabled jalopy javadoc comment reformat
>b
Andrea Aime wrote:
> Hi all,
> I've managed to get the mojo project provide a public snapshot build of
> the jalopy plugin, and I've then committed changes to the main pom so that
> jalopy can be used if you specify a special profile.
>
Amusing just as I gave up hope and committed eclipse form
Hi all,
I've managed to get the mojo project provide a public snapshot build of
the jalopy plugin,
and I've then committed changes to the main pom so that jalopy can be
used if you specify
a special profile.
If you want to try out jalopy with the current settings on a module, go
into it and typ
I am working offline these days and am having to do a couple of patches
to make it through a "maven build -O" ...
I was surprised to find that GeoServerOnlineTest no longer checks the
local geoserver (this is a big plus when working away from the big bad
internet).
We can do two things:
a) Res
I got a couple bounces because:
Your mail to 'Geotools-devel' with the subject
Re: [Geotools-devel] RE: [Geoserver-devel] Re: [Geoserver-users]
netcdf - wcs resource
Is being held until the list moderator can review it for approval.
The reason it is being held:
Too many recipients to
61 matches
Mail list logo
