You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2008/03/02 23:26:58 UTC

Continuum Failures

It may seem like I broke a number of builds with my changes today, but
half of them [codec, discovery, JCI, VFS] were already failing before,
for the rest...

1) Validator - now fixed (caused by upgrade of surefire plugin from
2.3 to 2.4.1 in commons-parent).
2) IO - very strange, I upgraded the build profile from Java 1.4 to
Java 5 a few weeks ago (see previous build[1]) - so either Continuum
*lost* my change or someone reverted it. Anyway I've set it again to
Java 5, so it should build OK after the next change to IO
3) Lang - not sure why it failed - works OK for me locally
4) Logging - I get this failure, reverting to surefire 2.3 fixes this
- but not sure how to fix this properly

Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Mar 3, 2008 at 9:56 AM, Jörg Schaible
<Jo...@elsag-solutions.com> wrote:
> jcarman@carmanconsulting.com wrote:
>  > On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>  >> It may seem like I broke a number of builds with my changes today,
>  >>  but half of them [codec, discovery, JCI, VFS] were already failing
>  >> before,  for the rest...
>  >>
>  >>  1) Validator - now fixed (caused by upgrade of surefire plugin from
>  >>  2.3 to 2.4.1 in commons-parent).
>  >>  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>  >>  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>  >>  *lost* my change or someone reverted it. Anyway I've set it again to
>  >>  Java 5, so it should build OK after the next change to IO
>  >>  3) Lang - not sure why it failed - works OK for me locally
>  >>  4) Logging - I get this failure, reverting to surefire 2.3 fixes
>  >>  this - but not sure how to fix this properly
>  >>
>  >
>  > We've had some build failures when we upgraded from 2.3 also.  The
>  > problem we saw was that the tests weren't run in the same order
>  > anymore for some reason.  Could that be what you're seeing?
>
>  Did you try surefire 2.4.2? That one was supposed to solve the compatibility problems.

yes thats the version specified in commons-parent-8

Niall

>  - Jörg
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


RE: Continuum Failures

Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
jcarman@carmanconsulting.com wrote:
> On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>> It may seem like I broke a number of builds with my changes today,
>>  but half of them [codec, discovery, JCI, VFS] were already failing
>> before,  for the rest... 
>> 
>>  1) Validator - now fixed (caused by upgrade of surefire plugin from
>>  2.3 to 2.4.1 in commons-parent).
>>  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>>  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>>  *lost* my change or someone reverted it. Anyway I've set it again to
>>  Java 5, so it should build OK after the next change to IO
>>  3) Lang - not sure why it failed - works OK for me locally
>>  4) Logging - I get this failure, reverting to surefire 2.3 fixes
>>  this - but not sure how to fix this properly
>> 
> 
> We've had some build failures when we upgraded from 2.3 also.  The
> problem we saw was that the tests weren't run in the same order
> anymore for some reason.  Could that be what you're seeing?

Did you try surefire 2.4.2? That one was supposed to solve the compatibility problems.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by James Carman <ja...@carmanconsulting.com>.
On 3/3/08, simon.kitching@chello.at <si...@chello.at> wrote:
> I'll try to find time to look into it, but it won't be for at least a
>  couple of weeks.
>
>  Commons-logging does some *very* unusual things with classpaths during
>  integration-tests, because the tests need to check how things work in
>  all sorts of odd classloader setups. The same test is sometimes called
>  multiple times, for example, with different classpaths set up on each
>  invocation.
>
>  Logging's test cases should be reasonably well documented though; I put
>  some effort into this as it is so unusual.
>

Maybe it's time Commons Logging got an overhaul.  I suggested quite
some time ago (http://markmail.org/message/oqesn6dhlqdhzsbh) that we
split JCL into multiple modules (like slf4j does).  I wouldn't mind
helping with it.  It would just have to be a major release (2.0) of
JCL to avoid any backward compatibility gripes.  Unfortunately, since
slf4j already does this, it will seem like a rip-off, but it's the
right way to do it.

>
>  Regards,
>
> Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Mar 3, 2008 at 10:01 AM, simon.kitching@chello.at
<si...@chello.at> wrote:
> simon.kitching@chello.at schrieb:
>
>
> > Niall Pemberton schrieb:
>  >
>  >> On Mon, Mar 3, 2008 at 3:26 AM, James Carman <ja...@carmanconsulting.com> wrote:
>  >>
>  >>
>  >>> On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>  >>>  > It may seem like I broke a number of builds with my changes today, but
>  >>>  >  half of them [codec, discovery, JCI, VFS] were already failing before,
>  >>>  >  for the rest...
>  >>>  >
>  >>>  >  1) Validator - now fixed (caused by upgrade of surefire plugin from
>  >>>  >  2.3 to 2.4.1 in commons-parent).
>  >>>  >  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>  >>>  >  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>  >>>  >  *lost* my change or someone reverted it. Anyway I've set it again to
>  >>>  >  Java 5, so it should build OK after the next change to IO
>  >>>  >  3) Lang - not sure why it failed - works OK for me locally
>  >>>  >  4) Logging - I get this failure, reverting to surefire 2.3 fixes this
>  >>>  >  - but not sure how to fix this properly
>  >>>  >
>  >>>
>  >>>  We've had some build failures when we upgraded from 2.3 also.  The
>  >>>  problem we saw was that the tests weren't run in the same order
>  >>>  anymore for some reason.  Could that be what you're seeing?
>  >>>
>  >>>
>  >> I don't know the internals of commons logging - hopefully one of the
>  >> logging devs will have more of a clue. When I run mvn integration-test
>  >> I see the following error
>  >>
>  >> org.apache.maven.surefire.testset.TestSetFailedException:
>  >> org.apache.commons.logging.logkit.StandardTestCase; nested exception
>  >> is java.lang.UnknownError: Logical lib [logkit] is not defined as a
>  >> System property.
>  >>
>  >> Don't know if its related but logkit.StandardTestCase' s suite()
>  >> method is called twice using Surefire 2.3 - but only once with
>  >> Surefire 2.4.2
>  >>
>  >>
>  >
>  > I'll try to find time to look into it, but it won't be for at least a
>  > couple of weeks.
>  >
>  > Commons-logging does some *very* unusual things with classpaths during
>  > integration-tests, because the tests need to check how things work in
>  > all sorts of odd classloader setups. The same test is sometimes called
>  > multiple times, for example, with different classpaths set up on each
>  > invocation.
>  >
>  > Logging's test cases should be reasonably well documented though; I put
>  > some effort into this as it is so unusual.
>  >
>  Oh, and by the way the easiest solution is just to lock
>  commons-logging's version of maven-surefire-plugin to 2.3.1 (or whatever
>  works).
>
>  Locking plugin versions is good practice anyway; there is no need to
>  upgrade to a later version of a plugin if an earlier version does
>  everything that is currently needed, so logging can just stick with
>  2.3.1 until we find that we need something newer - and fix the problem then.

OK I've done this - would be good to find a proper solution to get it
working with surefire 2.4.1+ at some point though.

http://svn.apache.org/viewvc?view=rev&revision=633041

Niall

>  Feel free to update the commons-logging pom in trunk, or I will do that
>  in the next few days.
>
>  Cheers,
>
>
> Simon
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by "simon.kitching@chello.at" <si...@chello.at>.
simon.kitching@chello.at schrieb:
> Niall Pemberton schrieb:
>   
>> On Mon, Mar 3, 2008 at 3:26 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>   
>>     
>>> On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>>>  > It may seem like I broke a number of builds with my changes today, but
>>>  >  half of them [codec, discovery, JCI, VFS] were already failing before,
>>>  >  for the rest...
>>>  >
>>>  >  1) Validator - now fixed (caused by upgrade of surefire plugin from
>>>  >  2.3 to 2.4.1 in commons-parent).
>>>  >  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>>>  >  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>>>  >  *lost* my change or someone reverted it. Anyway I've set it again to
>>>  >  Java 5, so it should build OK after the next change to IO
>>>  >  3) Lang - not sure why it failed - works OK for me locally
>>>  >  4) Logging - I get this failure, reverting to surefire 2.3 fixes this
>>>  >  - but not sure how to fix this properly
>>>  >
>>>
>>>  We've had some build failures when we upgraded from 2.3 also.  The
>>>  problem we saw was that the tests weren't run in the same order
>>>  anymore for some reason.  Could that be what you're seeing?
>>>     
>>>       
>> I don't know the internals of commons logging - hopefully one of the
>> logging devs will have more of a clue. When I run mvn integration-test
>> I see the following error
>>
>> org.apache.maven.surefire.testset.TestSetFailedException:
>> org.apache.commons.logging.logkit.StandardTestCase; nested exception
>> is java.lang.UnknownError: Logical lib [logkit] is not defined as a
>> System property.
>>
>> Don't know if its related but logkit.StandardTestCase' s suite()
>> method is called twice using Surefire 2.3 - but only once with
>> Surefire 2.4.2
>>   
>>     
>
> I'll try to find time to look into it, but it won't be for at least a
> couple of weeks.
>
> Commons-logging does some *very* unusual things with classpaths during
> integration-tests, because the tests need to check how things work in
> all sorts of odd classloader setups. The same test is sometimes called
> multiple times, for example, with different classpaths set up on each
> invocation.
>
> Logging's test cases should be reasonably well documented though; I put
> some effort into this as it is so unusual.
>   
Oh, and by the way the easiest solution is just to lock
commons-logging's version of maven-surefire-plugin to 2.3.1 (or whatever
works).

Locking plugin versions is good practice anyway; there is no need to
upgrade to a later version of a plugin if an earlier version does
everything that is currently needed, so logging can just stick with
2.3.1 until we find that we need something newer - and fix the problem then.

Feel free to update the commons-logging pom in trunk, or I will do that
in the next few days.

Cheers,
Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by "simon.kitching@chello.at" <si...@chello.at>.
Niall Pemberton schrieb:
> On Mon, Mar 3, 2008 at 3:26 AM, James Carman <ja...@carmanconsulting.com> wrote:
>   
>> On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>>  > It may seem like I broke a number of builds with my changes today, but
>>  >  half of them [codec, discovery, JCI, VFS] were already failing before,
>>  >  for the rest...
>>  >
>>  >  1) Validator - now fixed (caused by upgrade of surefire plugin from
>>  >  2.3 to 2.4.1 in commons-parent).
>>  >  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>>  >  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>>  >  *lost* my change or someone reverted it. Anyway I've set it again to
>>  >  Java 5, so it should build OK after the next change to IO
>>  >  3) Lang - not sure why it failed - works OK for me locally
>>  >  4) Logging - I get this failure, reverting to surefire 2.3 fixes this
>>  >  - but not sure how to fix this properly
>>  >
>>
>>  We've had some build failures when we upgraded from 2.3 also.  The
>>  problem we saw was that the tests weren't run in the same order
>>  anymore for some reason.  Could that be what you're seeing?
>>     
>
> I don't know the internals of commons logging - hopefully one of the
> logging devs will have more of a clue. When I run mvn integration-test
> I see the following error
>
> org.apache.maven.surefire.testset.TestSetFailedException:
> org.apache.commons.logging.logkit.StandardTestCase; nested exception
> is java.lang.UnknownError: Logical lib [logkit] is not defined as a
> System property.
>
> Don't know if its related but logkit.StandardTestCase' s suite()
> method is called twice using Surefire 2.3 - but only once with
> Surefire 2.4.2
>   

I'll try to find time to look into it, but it won't be for at least a
couple of weeks.

Commons-logging does some *very* unusual things with classpaths during
integration-tests, because the tests need to check how things work in
all sorts of odd classloader setups. The same test is sometimes called
multiple times, for example, with different classpaths set up on each
invocation.

Logging's test cases should be reasonably well documented though; I put
some effort into this as it is so unusual.


Regards,
Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, Mar 3, 2008 at 3:26 AM, James Carman <ja...@carmanconsulting.com> wrote:
>
> On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
>  > It may seem like I broke a number of builds with my changes today, but
>  >  half of them [codec, discovery, JCI, VFS] were already failing before,
>  >  for the rest...
>  >
>  >  1) Validator - now fixed (caused by upgrade of surefire plugin from
>  >  2.3 to 2.4.1 in commons-parent).
>  >  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>  >  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>  >  *lost* my change or someone reverted it. Anyway I've set it again to
>  >  Java 5, so it should build OK after the next change to IO
>  >  3) Lang - not sure why it failed - works OK for me locally
>  >  4) Logging - I get this failure, reverting to surefire 2.3 fixes this
>  >  - but not sure how to fix this properly
>  >
>
>  We've had some build failures when we upgraded from 2.3 also.  The
>  problem we saw was that the tests weren't run in the same order
>  anymore for some reason.  Could that be what you're seeing?

I don't know the internals of commons logging - hopefully one of the
logging devs will have more of a clue. When I run mvn integration-test
I see the following error

org.apache.maven.surefire.testset.TestSetFailedException:
org.apache.commons.logging.logkit.StandardTestCase; nested exception
is java.lang.UnknownError: Logical lib [logkit] is not defined as a
System property.

Don't know if its related but logkit.StandardTestCase' s suite()
method is called twice using Surefire 2.3 - but only once with
Surefire 2.4.2

Niall

>  >  Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: Continuum Failures

Posted by James Carman <ja...@carmanconsulting.com>.
On 3/2/08, Niall Pemberton <ni...@gmail.com> wrote:
> It may seem like I broke a number of builds with my changes today, but
>  half of them [codec, discovery, JCI, VFS] were already failing before,
>  for the rest...
>
>  1) Validator - now fixed (caused by upgrade of surefire plugin from
>  2.3 to 2.4.1 in commons-parent).
>  2) IO - very strange, I upgraded the build profile from Java 1.4 to
>  Java 5 a few weeks ago (see previous build[1]) - so either Continuum
>  *lost* my change or someone reverted it. Anyway I've set it again to
>  Java 5, so it should build OK after the next change to IO
>  3) Lang - not sure why it failed - works OK for me locally
>  4) Logging - I get this failure, reverting to surefire 2.3 fixes this
>  - but not sure how to fix this properly
>

We've had some build failures when we upgraded from 2.3 also.  The
problem we saw was that the tests weren't run in the same order
anymore for some reason.  Could that be what you're seeing?

>  Niall
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org