Jody Garnett wrote: > I think this is a case were we can come to a decision without a formal > proposal since this just effects us the devel community and the change is not > visible to user code. But that is my take on it - we are still sorting out > when a proposal is useful and when it is a waste of time :-)
Jody, Jody, I am hyperventilating. http://n2.nabble.com/Prevent-silent-failures-of-online-tests-tp1954287p1954294.html "That works for me; but remember you will need to make a formal proposal on this one (since we are trying to change the build policies)." - Jody Garnett, 2008-08-18 http://n2.nabble.com/Proposal%3A-support-test-fixtures-that-fail-on-failed-connection--GEOT-1951--tp1958345p1958349.html "So I would really like a proposal no matter what; that is GeoTools policy for build level changes. Notice I made a proposal last week for something that amounted to adding a bunch of profiles so you did not need to build unsupported modules. Just so I am clear: if you are hoping to make your patch small enough to avoid writing a proposal - I am afraid I must disappoint you :-) It is the subject area you are working (namely something that effects several modules) that makes the need for a proposal clear. And also the need to update the developers guide." - Jody Garnett, 2008-08-26 > I see what you are getting at; and I think we could be more specific and > still cover all out bases. I would like to disable the test when the service > in question cannot be reached (either due to firewall issues or something > like that). If we actually have a problem making the connection because of > version incompatibility or something then that is a perfectly good error to > report. > Does the difference make sense? Yes, but how do you tell? OnlineTestCase would need to know all exception types that might be thrown by future implementations on connection failure. Some may be RuntimeException. How do we tell if this is a transient connection failure? And what if the implementation is incorrect and throws a could-not-contact exception when it is broken? These are only tests, and do not have to be feature-complete. I just want them to fail when something goes wrong. That is why they are there. > I think it would also be okay to have a build time property that you could > set to *ensure* the external service is contacted. -Donline=required, or > -Dstrict =true or something. I think Andrea's earlier comment reminds us that one person's remote service is another person's local service , so per-fixture configuration is useful. Kind regards, -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
