I am going to play with surefire executions and see how that goes.
Gary
On Sep 3, 2011, at 19:37, Mark Struberg <strub...@yahoo.de> wrote:
> Create a test.jar as attached artifact. Then create a sub module where you
> dependency:unpack this test-jar and run the tests in your new configuration.
> This can also be done via the maven-invoker-plugin.
>
> LieGrue,
> strub
>
>
> ----- Original Message -----
>> From: sebb <seb...@gmail.com>
>> To: Commons Developers List <dev@commons.apache.org>
>> Cc:
>> Sent: Saturday, September 3, 2011 5:10 PM
>> Subject: Re: [lang] Running lang under a security manager and LANG-744
>>
>> On 3 September 2011 05:37, Henri Yandell <flame...@gmail.com> wrote:
>>> I'm less concerned with the 115 errors, unless they're all as
>> grievous
>>> as the StringUtils one - ie) the method causing trouble is not the
>>> only one broken.
>>>
>>> If the error happened when calling stripAccents, that would be
>>> workable; but having all of StringUtils unavailable is very painful.
>>> One option would be to move the code out of the static initializer and
>>> make it lazy when stripAccents is first called - leading to only
>>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>>> pain.
>>
>> I thought we'd already fixed that by catching the extra Exception?
>>
>> I already suggested localising the error display to the stripAccents method.
>>
>>> I thought we could simplify things by simply making the java6Available
>>> flag be a real test for Java 6, but Android seems very weird there. Is
>>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>>> compatible? IIUC it reports itself as 0.9, which we've declared as
>>> equivalent to JDK 1.5.
>>
>> Are you sure that is the issue?
>> Surely the Android problem is that we check for the sun class but
>> don't handle all possible errors?
>> So the class does not load; it cannot use the Java6 method even if it exists.
>>
>>> That relates to another (simple) solution - move to Java 6 :)
>>
>> Or capture Exception for both the java6 and sun tests; report the
>> exception(s) if neither is available when required.
>>
>> The static block would then always complete; only methods using the
>> optional code would be affected.
>>
>>> Hen
>>>
>>> On Thu, Sep 1, 2011 at 5:20 PM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>>> WRT LANG-744 "StringUtils throws
>> java.security.AccessControlException on
>>>> Google App Engine"
>>>>
>>>> Well, I've ruminated, pondered and experimented.
>>>>
>>>> Running all unit tests with a security managers results in:
>>>>
>>>> Tests run: 2046, Failures: 2, Errors: 115, Skipped: 0
>>>>
>>>> Clearly, we need a good overall solution to avoid 117 new Jiras (an
>>>> exaggeration I know.)
>>>>
>>>> I've created a JAAS policy file to grant just enough permissions to
>> run the
>>>> unit tests in {{src/test/resource/java.policy}}
>>>>
>>>> The file contains instructions for using it with JAAS.
>>>>
>>>> What this shows is that we should either:
>>>>
>>>> # Run all unit tests a second time with JAAS enabled, or
>>>> # Run all unit tests with JAAS enabled, always
>>>>
>>>> We should our solution as a pattern for other Commons component.
>>>>
>>>> Specifically for StringUtils, should we have a SunStringUtils? This
>> would
>>>> let you know that you are depending on com.sun code.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Thank you,
>>>> Gary
>>>>
>>>> http://garygregory.wordpress.com/
>>>> http://garygregory.com/
>>>> http://people.apache.org/~ggregory/
>>>> http://twitter.com/GaryGregory
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
