> > I have seen your patch, updated my repo and I am running a build. It has
> > passed the troublesome module.
>
> Good. Has it finished yet?
I have finished a successful build on Windows using JDK7. It took awhile
because I am having some trouble with my internet connection being flaky. I had
to disable the online portion of the org.geotools.gml3.GML3EncodingTest in the
XSD-GML3 module and restart the build process a number of times due to 'hangs'
> > I known that with latter versions of JUnit the execution order of test can
> > be controlled; one option is random. It is just a thought to make the build
> > more robust. It would detect these type of issue more often.
>
> Eh, in GeoServer we upgraded to 4.11, but in order to make exactly the
> opposite choice: to cast
> down the test execution order to be a specific one.
> The rationale being that, with few resources dedicated to bug fixing, it's
> better to use them to fix
> real bugs than issues in the tests themselves:
> http://www.mail-archive.com/[email protected]/msg13297.html
>
> I guess we should propose the same in GeoTools....
The reason I suggested what I did was that test should be independent of order
and each other. The choice taken in GeoServer is quite reasonable given the
constraints. My suggestions just sets the bar higher but it may be unattainable
with constrained resources.
Brett
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
