You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2016/03/30 09:40:08 UTC
4.0 jenkins build failures
Hmm, now 4.0 started failing with random errors. Makes no sense what so ever.
A.
> On Mar 24, 2016, at 10:01 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Savva recently did some tweaks to 3.1 test bootstrap code to ensure that Jenkins is picking up the right DB type (until now it was testing everything with default DB - HSQL , no matter what Jenkins UI showed). I just edited Jenkins configs to make sure these changes can take effect, added Java 8 dimension, and manually started a 3.1 build. Now that the tests are running against HSQL, H2 and Derby, I expected a fair amount of random failures. Though this is pretty bad:
>
> https://builds.apache.org/view/A-D/view/Cayenne/job/cayenne-31/126/
>
> You may remember that the cause of failures is DB cleanup randomness in the tests (not bugs in Cayenne). Those were eradicated in 4.0, stabilizing the builds there. Porting the fixes to 3.1 felt like a huge undertaking and was never pursued. This unfortunately means that now it is hard to separate real errors from noise on the stable branch :-/
>
> Andrus
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
I thought all our tests are using LocalConnection and do not open server sockets. Could be wrong. Something to check.
Andrus
> On Mar 30, 2016, at 10:46 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> The log I just looked at failed inside Hessian serialisation and ultimately:
>
> Caused by: java.lang.NullPointerException: null
> at java.net.URL.readResolve(URL.java:1311)
>
> Could this be a socket problem with multiple jobs running at once on the same machine and trying to grab the same unix socket or port?
>
>
> Ari
>
>
> On 30/03/2016 6:40pm, Andrus Adamchik wrote:
>> Hmm, now 4.0 started failing with random errors. Makes no sense what so ever.
>>
>> A.
>>
>>
>>> On Mar 24, 2016, at 10:01 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>>
>>> Savva recently did some tweaks to 3.1 test bootstrap code to ensure that Jenkins is picking up the right DB type (until now it was testing everything with default DB - HSQL , no matter what Jenkins UI showed). I just edited Jenkins configs to make sure these changes can take effect, added Java 8 dimension, and manually started a 3.1 build. Now that the tests are running against HSQL, H2 and Derby, I expected a fair amount of random failures. Though this is pretty bad:
>>>
>>> https://builds.apache.org/view/A-D/view/Cayenne/job/cayenne-31/126/
>>>
>>> You may remember that the cause of failures is DB cleanup randomness in the tests (not bugs in Cayenne). Those were eradicated in 4.0, stabilizing the builds there. Porting the fixes to 3.1 felt like a huge undertaking and was never pursued. This unfortunately means that now it is hard to separate real errors from noise on the stable branch :-/
>>>
>>> Andrus
>>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
The log I just looked at failed inside Hessian serialisation and ultimately:
Caused by: java.lang.NullPointerException: null
at java.net.URL.readResolve(URL.java:1311)
Could this be a socket problem with multiple jobs running at once on the same machine and trying to grab the same unix socket or port?
Ari
On 30/03/2016 6:40pm, Andrus Adamchik wrote:
> Hmm, now 4.0 started failing with random errors. Makes no sense what so ever.
>
> A.
>
>
>> On Mar 24, 2016, at 10:01 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Savva recently did some tweaks to 3.1 test bootstrap code to ensure that Jenkins is picking up the right DB type (until now it was testing everything with default DB - HSQL , no matter what Jenkins UI showed). I just edited Jenkins configs to make sure these changes can take effect, added Java 8 dimension, and manually started a 3.1 build. Now that the tests are running against HSQL, H2 and Derby, I expected a fair amount of random failures. Though this is pretty bad:
>>
>> https://builds.apache.org/view/A-D/view/Cayenne/job/cayenne-31/126/
>>
>> You may remember that the cause of failures is DB cleanup randomness in the tests (not bugs in Cayenne). Those were eradicated in 4.0, stabilizing the builds there. Porting the fixes to 3.1 felt like a huge undertaking and was never pursued. This unfortunately means that now it is hard to separate real errors from noise on the stable branch :-/
>>
>> Andrus
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
Applied ... Mostly successful: https://travis-ci.org/apache/cayenne/builds/180159289 . 5 out of 6 configurations succeeded. Not bad for the first run. There was a genuine test failure in one of them, which I need to investigate:
DataContextBinaryPKIT.testFetchRelationshipBinaryPK:87 expected:<master1> but was:<null>
But the general conclusion is that Travis works for Cayenne now. The next step will be to try the builds with Docker-based DBs.
Andrus
> On Nov 30, 2016, at 2:19 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> BTW, we have a working Travis patch courtesy of https://github.com/IRus :
>
> https://github.com/apache/cayenne/pull/145
>
> Planning to apply this tonight.
>
> Andrus
>
>> On May 24, 2016, at 3:05 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>>> <dependency>
>>> <groupId>log4j</groupId>
>>> <artifactId>log4j</artifactId>
>>> <version>1.2.17</version>
>>> <scope>test</scope>
>>> </dependency>
>>
>>
>> If we are to use Log4J, let's at least use Log4J2 [1]. Also you will likely need log4j-jcl.jar bridge [2].
>>
>>> And provided commons-logging.properties
>>
>> Not sure what you placed in there, but I think with the bridge, you won't need this file.
>>
>> Andrus
>>
>> [1] http://search.maven.org/#search|ga|1|log4j2
>> [2] https://logging.apache.org/log4j/2.x/faq.html#which_jars
>>
>>
>>> On May 24, 2016, at 2:34 PM, Savva Kolbachev <s....@gmail.com> wrote:
>>>
>>>> Are we using Log4J bridge to commons-logging?
>>> If I understand correctly, we are using slf4j. We have the following
>>> dependencies:
>>>
>>> <dependency>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>jcl-over-slf4j</artifactId>
>>> <scope>test</scope>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-api</artifactId>
>>> <scope>test</scope>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-simple</artifactId>
>>> <scope>test</scope>
>>> </dependency>
>>>
>>> So, I just replaced them with this one:
>>> <dependency>
>>> <groupId>log4j</groupId>
>>> <artifactId>log4j</artifactId>
>>> <version>1.2.17</version>
>>> <scope>test</scope>
>>> </dependency>
>>>
>>> And provided commons-logging.properties and log4j.properties files. I
>>> tested it with cayenne-client module, but it shouldn't be a problem to
>>> apply for the whole project.
>>>
>>> 2016-05-24 14:15 GMT+03:00 Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>>
>>>>> For the purposes of running tests I think it really doesn't matter much
>>>>
>>>> Of course.
>>>>
>>>>> if Savva already has log4j working, then let's just do that.
>>>>
>>>> Are we using Log4J bridge to commons-logging?
>>>>
>>>> Andrus
>>>>
>>>>> On May 24, 2016, at 2:11 PM, Aristedes Maniatis <ar...@maniatis.org>
>>>> wrote:
>>>>>
>>>>> For the purposes of running tests I think it really doesn't matter much
>>>> and if Savva already has log4j working, then let's just do that. The only
>>>> goal here is to fix Travis and that's only so we can get access to some
>>>> additional databases they make available:
>>>> https://docs.travis-ci.com/user/database-setup/
>>>>>
>>>>> Ari
>>>>>
>>>>>
>>>>> On 24/05/2016 8:52pm, Andrus Adamchik wrote:
>>>>>> Yeah, whichever way we bridge commons-logging, we need to do it. There
>>>> are two things to consider:
>>>>>>
>>>>>> 1. logging API used in the code (Cayenne core uses common-logging).
>>>>>> 2. logging implementation that bridges #1 and writes the logs out.
>>>> Choices are: Logback, Log4J, slf4j-simple. The first two are configurable
>>>> via properties.
>>>>>>
>>>>>> I have no preference as to #2. There may be some slight benefit in
>>>> switching #1 to SLF, but this is a different discussion.
>>>>>>
>>>>>> Andrus
>>>>>>
>>>>>>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> I don't know a lot about loggers, but I've tried to use the old log4j
>>>>>>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j
>>>> in
>>>>>>> the test scope and it works. I could handle the behavior
>>>>>>> via commons-logging.properties and log4j.properties files.
>>>>>>>
>>>>>>> So, how about to move from slf4j to log4j for test purposes?
>>>>>>>
>>>>>>>
>>>>>>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>>>>>>>
>>>>>>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>>>>>>>> "mvn -q" suppresses Maven's own logging.
>>>>>>>>
>>>>>>>> We've already got that, but it doesn't stop much.
>>>>>>>>
>>>>>>>>> This leaves Cayenne's logging. To control that, we need to provide
>>>>>>>> proper logging dependencies in the "test" scope. E.g. add
>>>>>>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure
>>>> Logback
>>>>>>>> to use a minimal prefix for each log line.
>>>>>>>>
>>>>>>>> I was proceeding on the assumption that commons-logging sends to the
>>>>>>>> default Java logger when nothing else is configured. Perhaps you are
>>>> right
>>>>>>>> and we add log4j or slf4j to the test dependencies and then try to
>>>> silence
>>>>>>>> that.
>>>>>>>>
>>>>>>>> Ari
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -------------------------->
>>>>>>>> Aristedes Maniatis
>>>>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks and Regards
>>>>>>> Savva Kolbachev
>>>>>>
>>>>>
>>>>> --
>>>>> -------------------------->
>>>>> Aristedes Maniatis
>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks and Regards
>>> Savva Kolbachev
>>
>
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
BTW, we have a working Travis patch courtesy of https://github.com/IRus :
https://github.com/apache/cayenne/pull/145
Planning to apply this tonight.
Andrus
> On May 24, 2016, at 3:05 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>> <dependency>
>> <groupId>log4j</groupId>
>> <artifactId>log4j</artifactId>
>> <version>1.2.17</version>
>> <scope>test</scope>
>> </dependency>
>
>
> If we are to use Log4J, let's at least use Log4J2 [1]. Also you will likely need log4j-jcl.jar bridge [2].
>
>> And provided commons-logging.properties
>
> Not sure what you placed in there, but I think with the bridge, you won't need this file.
>
> Andrus
>
> [1] http://search.maven.org/#search|ga|1|log4j2
> [2] https://logging.apache.org/log4j/2.x/faq.html#which_jars
>
>
>> On May 24, 2016, at 2:34 PM, Savva Kolbachev <s....@gmail.com> wrote:
>>
>>> Are we using Log4J bridge to commons-logging?
>> If I understand correctly, we are using slf4j. We have the following
>> dependencies:
>>
>> <dependency>
>> <groupId>org.slf4j</groupId>
>> <artifactId>jcl-over-slf4j</artifactId>
>> <scope>test</scope>
>> </dependency>
>> <dependency>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-api</artifactId>
>> <scope>test</scope>
>> </dependency>
>> <dependency>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-simple</artifactId>
>> <scope>test</scope>
>> </dependency>
>>
>> So, I just replaced them with this one:
>> <dependency>
>> <groupId>log4j</groupId>
>> <artifactId>log4j</artifactId>
>> <version>1.2.17</version>
>> <scope>test</scope>
>> </dependency>
>>
>> And provided commons-logging.properties and log4j.properties files. I
>> tested it with cayenne-client module, but it shouldn't be a problem to
>> apply for the whole project.
>>
>> 2016-05-24 14:15 GMT+03:00 Andrus Adamchik <an...@objectstyle.org>:
>>
>>>
>>>> For the purposes of running tests I think it really doesn't matter much
>>>
>>> Of course.
>>>
>>>> if Savva already has log4j working, then let's just do that.
>>>
>>> Are we using Log4J bridge to commons-logging?
>>>
>>> Andrus
>>>
>>>> On May 24, 2016, at 2:11 PM, Aristedes Maniatis <ar...@maniatis.org>
>>> wrote:
>>>>
>>>> For the purposes of running tests I think it really doesn't matter much
>>> and if Savva already has log4j working, then let's just do that. The only
>>> goal here is to fix Travis and that's only so we can get access to some
>>> additional databases they make available:
>>> https://docs.travis-ci.com/user/database-setup/
>>>>
>>>> Ari
>>>>
>>>>
>>>> On 24/05/2016 8:52pm, Andrus Adamchik wrote:
>>>>> Yeah, whichever way we bridge commons-logging, we need to do it. There
>>> are two things to consider:
>>>>>
>>>>> 1. logging API used in the code (Cayenne core uses common-logging).
>>>>> 2. logging implementation that bridges #1 and writes the logs out.
>>> Choices are: Logback, Log4J, slf4j-simple. The first two are configurable
>>> via properties.
>>>>>
>>>>> I have no preference as to #2. There may be some slight benefit in
>>> switching #1 to SLF, but this is a different discussion.
>>>>>
>>>>> Andrus
>>>>>
>>>>>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com>
>>> wrote:
>>>>>>
>>>>>> I don't know a lot about loggers, but I've tried to use the old log4j
>>>>>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j
>>> in
>>>>>> the test scope and it works. I could handle the behavior
>>>>>> via commons-logging.properties and log4j.properties files.
>>>>>>
>>>>>> So, how about to move from slf4j to log4j for test purposes?
>>>>>>
>>>>>>
>>>>>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>>>>>>
>>>>>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>>>>>>> "mvn -q" suppresses Maven's own logging.
>>>>>>>
>>>>>>> We've already got that, but it doesn't stop much.
>>>>>>>
>>>>>>>> This leaves Cayenne's logging. To control that, we need to provide
>>>>>>> proper logging dependencies in the "test" scope. E.g. add
>>>>>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure
>>> Logback
>>>>>>> to use a minimal prefix for each log line.
>>>>>>>
>>>>>>> I was proceeding on the assumption that commons-logging sends to the
>>>>>>> default Java logger when nothing else is configured. Perhaps you are
>>> right
>>>>>>> and we add log4j or slf4j to the test dependencies and then try to
>>> silence
>>>>>>> that.
>>>>>>>
>>>>>>> Ari
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -------------------------->
>>>>>>> Aristedes Maniatis
>>>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks and Regards
>>>>>> Savva Kolbachev
>>>>>
>>>>
>>>> --
>>>> -------------------------->
>>>> Aristedes Maniatis
>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>
>>>
>>
>>
>> --
>> Thanks and Regards
>> Savva Kolbachev
>
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>1.2.17</version>
> <scope>test</scope>
> </dependency>
If we are to use Log4J, let's at least use Log4J2 [1]. Also you will likely need log4j-jcl.jar bridge [2].
> And provided commons-logging.properties
Not sure what you placed in there, but I think with the bridge, you won't need this file.
Andrus
[1] http://search.maven.org/#search|ga|1|log4j2
[2] https://logging.apache.org/log4j/2.x/faq.html#which_jars
> On May 24, 2016, at 2:34 PM, Savva Kolbachev <s....@gmail.com> wrote:
>
>> Are we using Log4J bridge to commons-logging?
> If I understand correctly, we are using slf4j. We have the following
> dependencies:
>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-simple</artifactId>
> <scope>test</scope>
> </dependency>
>
> So, I just replaced them with this one:
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>1.2.17</version>
> <scope>test</scope>
> </dependency>
>
> And provided commons-logging.properties and log4j.properties files. I
> tested it with cayenne-client module, but it shouldn't be a problem to
> apply for the whole project.
>
> 2016-05-24 14:15 GMT+03:00 Andrus Adamchik <an...@objectstyle.org>:
>
>>
>>> For the purposes of running tests I think it really doesn't matter much
>>
>> Of course.
>>
>>> if Savva already has log4j working, then let's just do that.
>>
>> Are we using Log4J bridge to commons-logging?
>>
>> Andrus
>>
>>> On May 24, 2016, at 2:11 PM, Aristedes Maniatis <ar...@maniatis.org>
>> wrote:
>>>
>>> For the purposes of running tests I think it really doesn't matter much
>> and if Savva already has log4j working, then let's just do that. The only
>> goal here is to fix Travis and that's only so we can get access to some
>> additional databases they make available:
>> https://docs.travis-ci.com/user/database-setup/
>>>
>>> Ari
>>>
>>>
>>> On 24/05/2016 8:52pm, Andrus Adamchik wrote:
>>>> Yeah, whichever way we bridge commons-logging, we need to do it. There
>> are two things to consider:
>>>>
>>>> 1. logging API used in the code (Cayenne core uses common-logging).
>>>> 2. logging implementation that bridges #1 and writes the logs out.
>> Choices are: Logback, Log4J, slf4j-simple. The first two are configurable
>> via properties.
>>>>
>>>> I have no preference as to #2. There may be some slight benefit in
>> switching #1 to SLF, but this is a different discussion.
>>>>
>>>> Andrus
>>>>
>>>>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com>
>> wrote:
>>>>>
>>>>> I don't know a lot about loggers, but I've tried to use the old log4j
>>>>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j
>> in
>>>>> the test scope and it works. I could handle the behavior
>>>>> via commons-logging.properties and log4j.properties files.
>>>>>
>>>>> So, how about to move from slf4j to log4j for test purposes?
>>>>>
>>>>>
>>>>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>>>>>
>>>>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>>>>>> "mvn -q" suppresses Maven's own logging.
>>>>>>
>>>>>> We've already got that, but it doesn't stop much.
>>>>>>
>>>>>>> This leaves Cayenne's logging. To control that, we need to provide
>>>>>> proper logging dependencies in the "test" scope. E.g. add
>>>>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure
>> Logback
>>>>>> to use a minimal prefix for each log line.
>>>>>>
>>>>>> I was proceeding on the assumption that commons-logging sends to the
>>>>>> default Java logger when nothing else is configured. Perhaps you are
>> right
>>>>>> and we add log4j or slf4j to the test dependencies and then try to
>> silence
>>>>>> that.
>>>>>>
>>>>>> Ari
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -------------------------->
>>>>>> Aristedes Maniatis
>>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks and Regards
>>>>> Savva Kolbachev
>>>>
>>>
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>
>
> --
> Thanks and Regards
> Savva Kolbachev
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Savva Kolbachev <s....@gmail.com>.
> Are we using Log4J bridge to commons-logging?
If I understand correctly, we are using slf4j. We have the following
dependencies:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<scope>test</scope>
</dependency>
So, I just replaced them with this one:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<scope>test</scope>
</dependency>
And provided commons-logging.properties and log4j.properties files. I
tested it with cayenne-client module, but it shouldn't be a problem to
apply for the whole project.
2016-05-24 14:15 GMT+03:00 Andrus Adamchik <an...@objectstyle.org>:
>
> > For the purposes of running tests I think it really doesn't matter much
>
> Of course.
>
> > if Savva already has log4j working, then let's just do that.
>
> Are we using Log4J bridge to commons-logging?
>
> Andrus
>
> > On May 24, 2016, at 2:11 PM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
> >
> > For the purposes of running tests I think it really doesn't matter much
> and if Savva already has log4j working, then let's just do that. The only
> goal here is to fix Travis and that's only so we can get access to some
> additional databases they make available:
> https://docs.travis-ci.com/user/database-setup/
> >
> > Ari
> >
> >
> > On 24/05/2016 8:52pm, Andrus Adamchik wrote:
> >> Yeah, whichever way we bridge commons-logging, we need to do it. There
> are two things to consider:
> >>
> >> 1. logging API used in the code (Cayenne core uses common-logging).
> >> 2. logging implementation that bridges #1 and writes the logs out.
> Choices are: Logback, Log4J, slf4j-simple. The first two are configurable
> via properties.
> >>
> >> I have no preference as to #2. There may be some slight benefit in
> switching #1 to SLF, but this is a different discussion.
> >>
> >> Andrus
> >>
> >>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com>
> wrote:
> >>>
> >>> I don't know a lot about loggers, but I've tried to use the old log4j
> >>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j
> in
> >>> the test scope and it works. I could handle the behavior
> >>> via commons-logging.properties and log4j.properties files.
> >>>
> >>> So, how about to move from slf4j to log4j for test purposes?
> >>>
> >>>
> >>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
> >>>
> >>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
> >>>>> "mvn -q" suppresses Maven's own logging.
> >>>>
> >>>> We've already got that, but it doesn't stop much.
> >>>>
> >>>>> This leaves Cayenne's logging. To control that, we need to provide
> >>>> proper logging dependencies in the "test" scope. E.g. add
> >>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure
> Logback
> >>>> to use a minimal prefix for each log line.
> >>>>
> >>>> I was proceeding on the assumption that commons-logging sends to the
> >>>> default Java logger when nothing else is configured. Perhaps you are
> right
> >>>> and we add log4j or slf4j to the test dependencies and then try to
> silence
> >>>> that.
> >>>>
> >>>> Ari
> >>>>
> >>>>
> >>>> --
> >>>> -------------------------->
> >>>> Aristedes Maniatis
> >>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Thanks and Regards
> >>> Savva Kolbachev
> >>
> >
> > --
> > -------------------------->
> > Aristedes Maniatis
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
--
Thanks and Regards
Savva Kolbachev
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> For the purposes of running tests I think it really doesn't matter much
Of course.
> if Savva already has log4j working, then let's just do that.
Are we using Log4J bridge to commons-logging?
Andrus
> On May 24, 2016, at 2:11 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> For the purposes of running tests I think it really doesn't matter much and if Savva already has log4j working, then let's just do that. The only goal here is to fix Travis and that's only so we can get access to some additional databases they make available: https://docs.travis-ci.com/user/database-setup/
>
> Ari
>
>
> On 24/05/2016 8:52pm, Andrus Adamchik wrote:
>> Yeah, whichever way we bridge commons-logging, we need to do it. There are two things to consider:
>>
>> 1. logging API used in the code (Cayenne core uses common-logging).
>> 2. logging implementation that bridges #1 and writes the logs out. Choices are: Logback, Log4J, slf4j-simple. The first two are configurable via properties.
>>
>> I have no preference as to #2. There may be some slight benefit in switching #1 to SLF, but this is a different discussion.
>>
>> Andrus
>>
>>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com> wrote:
>>>
>>> I don't know a lot about loggers, but I've tried to use the old log4j
>>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j in
>>> the test scope and it works. I could handle the behavior
>>> via commons-logging.properties and log4j.properties files.
>>>
>>> So, how about to move from slf4j to log4j for test purposes?
>>>
>>>
>>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>>>
>>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>>>> "mvn -q" suppresses Maven's own logging.
>>>>
>>>> We've already got that, but it doesn't stop much.
>>>>
>>>>> This leaves Cayenne's logging. To control that, we need to provide
>>>> proper logging dependencies in the "test" scope. E.g. add
>>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback
>>>> to use a minimal prefix for each log line.
>>>>
>>>> I was proceeding on the assumption that commons-logging sends to the
>>>> default Java logger when nothing else is configured. Perhaps you are right
>>>> and we add log4j or slf4j to the test dependencies and then try to silence
>>>> that.
>>>>
>>>> Ari
>>>>
>>>>
>>>> --
>>>> -------------------------->
>>>> Aristedes Maniatis
>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards
>>> Savva Kolbachev
>>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
For the purposes of running tests I think it really doesn't matter much and if Savva already has log4j working, then let's just do that. The only goal here is to fix Travis and that's only so we can get access to some additional databases they make available: https://docs.travis-ci.com/user/database-setup/
Ari
On 24/05/2016 8:52pm, Andrus Adamchik wrote:
> Yeah, whichever way we bridge commons-logging, we need to do it. There are two things to consider:
>
> 1. logging API used in the code (Cayenne core uses common-logging).
> 2. logging implementation that bridges #1 and writes the logs out. Choices are: Logback, Log4J, slf4j-simple. The first two are configurable via properties.
>
> I have no preference as to #2. There may be some slight benefit in switching #1 to SLF, but this is a different discussion.
>
> Andrus
>
>> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com> wrote:
>>
>> I don't know a lot about loggers, but I've tried to use the old log4j
>> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j in
>> the test scope and it works. I could handle the behavior
>> via commons-logging.properties and log4j.properties files.
>>
>> So, how about to move from slf4j to log4j for test purposes?
>>
>>
>> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>>
>>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>>> "mvn -q" suppresses Maven's own logging.
>>>
>>> We've already got that, but it doesn't stop much.
>>>
>>>> This leaves Cayenne's logging. To control that, we need to provide
>>> proper logging dependencies in the "test" scope. E.g. add
>>> SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback
>>> to use a minimal prefix for each log line.
>>>
>>> I was proceeding on the assumption that commons-logging sends to the
>>> default Java logger when nothing else is configured. Perhaps you are right
>>> and we add log4j or slf4j to the test dependencies and then try to silence
>>> that.
>>>
>>> Ari
>>>
>>>
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>
>>
>>
>>
>> --
>> Thanks and Regards
>> Savva Kolbachev
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, whichever way we bridge commons-logging, we need to do it. There are two things to consider:
1. logging API used in the code (Cayenne core uses common-logging).
2. logging implementation that bridges #1 and writes the logs out. Choices are: Logback, Log4J, slf4j-simple. The first two are configurable via properties.
I have no preference as to #2. There may be some slight benefit in switching #1 to SLF, but this is a different discussion.
Andrus
> On May 24, 2016, at 1:32 PM, Savva Kolbachev <s....@gmail.com> wrote:
>
> I don't know a lot about loggers, but I've tried to use the old log4j
> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j in
> the test scope and it works. I could handle the behavior
> via commons-logging.properties and log4j.properties files.
>
> So, how about to move from slf4j to log4j for test purposes?
>
>
> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>
>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>> "mvn -q" suppresses Maven's own logging.
>>
>> We've already got that, but it doesn't stop much.
>>
>>> This leaves Cayenne's logging. To control that, we need to provide
>> proper logging dependencies in the "test" scope. E.g. add
>> SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback
>> to use a minimal prefix for each log line.
>>
>> I was proceeding on the assumption that commons-logging sends to the
>> default Java logger when nothing else is configured. Perhaps you are right
>> and we add log4j or slf4j to the test dependencies and then try to silence
>> that.
>>
>> Ari
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
>
>
> --
> Thanks and Regards
> Savva Kolbachev
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On May 24, 2016, at 1:49 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> Perfect. I've actually never used slf4j, but I think that log4j might be easier to use and better documented.
See my other email. The difference between the two is that SLF is code-facing API that is easy to bridge to anything (including Log4J), and Log4J is an advanced logger implementation that is better kept away from the API.
Andrus
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
Perfect. I've actually never used slf4j, but I think that log4j might be easier to use and better documented. For the tests I think it makes no difference as long as we can get the builds quieter.
Ari
On 24/05/2016 8:32pm, Savva Kolbachev wrote:
> I don't know a lot about loggers, but I've tried to use the old log4j
> http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j in
> the test scope and it works. I could handle the behavior
> via commons-logging.properties and log4j.properties files.
>
> So, how about to move from slf4j to log4j for test purposes?
>
>
> 2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
>
>> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
>>> "mvn -q" suppresses Maven's own logging.
>>
>> We've already got that, but it doesn't stop much.
>>
>>> This leaves Cayenne's logging. To control that, we need to provide
>> proper logging dependencies in the "test" scope. E.g. add
>> SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback
>> to use a minimal prefix for each log line.
>>
>> I was proceeding on the assumption that commons-logging sends to the
>> default Java logger when nothing else is configured. Perhaps you are right
>> and we add log4j or slf4j to the test dependencies and then try to silence
>> that.
>>
>> Ari
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Savva Kolbachev <s....@gmail.com>.
I don't know a lot about loggers, but I've tried to use the old log4j
http://mvnrepository.com/artifact/log4j/log4j/1.2.17 instead of slf4j in
the test scope and it works. I could handle the behavior
via commons-logging.properties and log4j.properties files.
So, how about to move from slf4j to log4j for test purposes?
2016-04-18 9:43 GMT+03:00 Aristedes Maniatis <ar...@maniatis.org>:
> On 18/04/2016 4:27pm, Andrus Adamchik wrote:
> > "mvn -q" suppresses Maven's own logging.
>
> We've already got that, but it doesn't stop much.
>
> > This leaves Cayenne's logging. To control that, we need to provide
> proper logging dependencies in the "test" scope. E.g. add
> SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback
> to use a minimal prefix for each log line.
>
> I was proceeding on the assumption that commons-logging sends to the
> default Java logger when nothing else is configured. Perhaps you are right
> and we add log4j or slf4j to the test dependencies and then try to silence
> that.
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
--
Thanks and Regards
Savva Kolbachev
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 18/04/2016 4:27pm, Andrus Adamchik wrote:
> "mvn -q" suppresses Maven's own logging.
We've already got that, but it doesn't stop much.
> This leaves Cayenne's logging. To control that, we need to provide proper logging dependencies in the "test" scope. E.g. add SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback to use a minimal prefix for each log line.
I was proceeding on the assumption that commons-logging sends to the default Java logger when nothing else is configured. Perhaps you are right and we add log4j or slf4j to the test dependencies and then try to silence that.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Travis errors, Was: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
While we may consider Gradle separately from the logging issue, here are a few suggestions regarding Maven...
"mvn --help" prints all options
"mvn -q" suppresses Maven's own logging.
This leaves Cayenne's logging. To control that, we need to provide proper logging dependencies in the "test" scope. E.g. add SLF4J-to-commons-loging bridge and Logback jars, and then configure Logback to use a minimal prefix for each log line.
Also here is a completely different idea - maybe we can simply do "mvn ... > /tmp/log", to prevent logging to console. Not sure how to retrieve that log from the Travis server though in case we need to debug the builds.
Andrus
> On Apr 18, 2016, at 7:57 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> I just wasted 45 minutes struggling with maven, but I've not managed to get it to quiet logging. I tried all sorts of command line options like:
>
> mvn verify -D -Dorg.apache.commons.logging.simplelog.defaultlog=warn
>
> I put in a logging.properties with just ".level=WARN" and then tried to get surefire to see it:
>
> diff --git a/pom.xml b/pom.xml
> + <property>
> + <name>java.util.logging.config.file</name>
> + <value>logging.properties</value>
> + </property>
>
>
> But ultimately I can't make any dent in what the tests output to the console.
>
> This is the point at which I start to think: "It'd be easier to just move to gradle."
>
> Ari
>
>
>
> On 31/03/2016 6:21pm, Andrus Adamchik wrote:
>>
>>> On Mar 31, 2016, at 1:50 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>>
>>> Should we change most of CommonsJdbcEventLogger to DEBUG? For some reason the whole thing is bound to INFO?
>>>
>>> @Override
>>> public boolean isLoggable() {
>>> return logger.isInfoEnabled();
>>> }
>>>
>>>
>>> logQueryError() should be ERROR or at least WARN. Pretty much everything else should be DEBUG.
>>
>> Cayenne has always logged SQL at INFO level. And I'd like to have it on by default. Turning it off for Jenkins (or your own apps) is not a problem - logger levels are configurable. I am not doing it for other reasons:
>>
>> 1. We often want SQL to be logged during tests for tracing purposes.
>> 2. I am not yet convinced Cayenne logs are the culprit here. Consider that these builds are done with an empty local Maven repo, so Maven downloads a bunch of dependencies. Take a look at raw logs on Travis. It is not yet clear SQL logs are the majority.
>>
>> So I'd like to play with it a bit, and see what we can trim without sacrificing clarity. Long logger names and timestamps are the first candidates.
>>
>> Andrus
>>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Travis errors, Was: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
I just wasted 45 minutes struggling with maven, but I've not managed to get it to quiet logging. I tried all sorts of command line options like:
mvn verify -D -Dorg.apache.commons.logging.simplelog.defaultlog=warn
I put in a logging.properties with just ".level=WARN" and then tried to get surefire to see it:
diff --git a/pom.xml b/pom.xml
+ <property>
+ <name>java.util.logging.config.file</name>
+ <value>logging.properties</value>
+ </property>
But ultimately I can't make any dent in what the tests output to the console.
This is the point at which I start to think: "It'd be easier to just move to gradle."
Ari
On 31/03/2016 6:21pm, Andrus Adamchik wrote:
>
>> On Mar 31, 2016, at 1:50 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>> Should we change most of CommonsJdbcEventLogger to DEBUG? For some reason the whole thing is bound to INFO?
>>
>> @Override
>> public boolean isLoggable() {
>> return logger.isInfoEnabled();
>> }
>>
>>
>> logQueryError() should be ERROR or at least WARN. Pretty much everything else should be DEBUG.
>
> Cayenne has always logged SQL at INFO level. And I'd like to have it on by default. Turning it off for Jenkins (or your own apps) is not a problem - logger levels are configurable. I am not doing it for other reasons:
>
> 1. We often want SQL to be logged during tests for tracing purposes.
> 2. I am not yet convinced Cayenne logs are the culprit here. Consider that these builds are done with an empty local Maven repo, so Maven downloads a bunch of dependencies. Take a look at raw logs on Travis. It is not yet clear SQL logs are the majority.
>
> So I'd like to play with it a bit, and see what we can trim without sacrificing clarity. Long logger names and timestamps are the first candidates.
>
> Andrus
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 31, 2016, at 1:50 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> Should we change most of CommonsJdbcEventLogger to DEBUG? For some reason the whole thing is bound to INFO?
>
> @Override
> public boolean isLoggable() {
> return logger.isInfoEnabled();
> }
>
>
> logQueryError() should be ERROR or at least WARN. Pretty much everything else should be DEBUG.
Cayenne has always logged SQL at INFO level. And I'd like to have it on by default. Turning it off for Jenkins (or your own apps) is not a problem - logger levels are configurable. I am not doing it for other reasons:
1. We often want SQL to be logged during tests for tracing purposes.
2. I am not yet convinced Cayenne logs are the culprit here. Consider that these builds are done with an empty local Maven repo, so Maven downloads a bunch of dependencies. Take a look at raw logs on Travis. It is not yet clear SQL logs are the majority.
So I'd like to play with it a bit, and see what we can trim without sacrificing clarity. Long logger names and timestamps are the first candidates.
Andrus
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 31, 2016, at 1:50 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> On 30/03/2016 10:37pm, Andrus Adamchik wrote:
>> @Ari: BTW, do you have control of where the failure (and success) emails go? Would be great to route them to commits@
>
> As far as I know Travis doesn't send email. There are hooks into github which adds a comment to a pull request, but that's all.
Actually it does for me on other projects. E.g.:
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 30/03/2016 10:37pm, Andrus Adamchik wrote:
> @Ari: BTW, do you have control of where the failure (and success) emails go? Would be great to route them to commits@
As far as I know Travis doesn't send email. There are hooks into github which adds a comment to a pull request, but that's all.
Should we change most of CommonsJdbcEventLogger to DEBUG? For some reason the whole thing is bound to INFO?
@Override
public boolean isLoggable() {
return logger.isInfoEnabled();
}
logQueryError() should be ERROR or at least WARN. Pretty much everything else should be DEBUG.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
Among other things.
@Ari: BTW, do you have control of where the failure (and success) emails go? Would be great to route them to commits@
Andrus
> On Mar 30, 2016, at 2:29 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> It is probably all the SQL logging...
>
>
> On Wed, Mar 30, 2016 at 7:18 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> Builds with itests timeout and die because of too many logs generated:
>> https://travis-ci.org/apache/cayenne/builds . I turned off all the "pmd"
>> checks, but this wasn't enough. I guess we'll need to find other ways to
>> trim the logs. Cayenne is too big for Travis :)
>>
>> A.
>>
>>> On Mar 30, 2016, at 1:18 PM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>>
>>>
>>>> On Mar 30, 2016, at 1:16 PM, Aristedes Maniatis <ar...@maniatis.org>
>> wrote:
>>>>
>>>> I'm just heading home from work now, but go ahead and add whatever
>> changes you need. I don't think maven clean is needed though, and doesn't
>> 'test' already run 'verify' in maven?
>>>
>>> Will do. No, verify is a separate stage that happens after package. So
>> *Test and *IT are run at different stages of lifecycle.
>>>
>>> A.
>>>
>>
>>
Re: 4.0 jenkins build failures
Posted by Michael Gentry <bl...@gmail.com>.
It is probably all the SQL logging...
On Wed, Mar 30, 2016 at 7:18 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Builds with itests timeout and die because of too many logs generated:
> https://travis-ci.org/apache/cayenne/builds . I turned off all the "pmd"
> checks, but this wasn't enough. I guess we'll need to find other ways to
> trim the logs. Cayenne is too big for Travis :)
>
> A.
>
> > On Mar 30, 2016, at 1:18 PM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >
> >
> >> On Mar 30, 2016, at 1:16 PM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
> >>
> >> I'm just heading home from work now, but go ahead and add whatever
> changes you need. I don't think maven clean is needed though, and doesn't
> 'test' already run 'verify' in maven?
> >
> > Will do. No, verify is a separate stage that happens after package. So
> *Test and *IT are run at different stages of lifecycle.
> >
> > A.
> >
>
>
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
Builds with itests timeout and die because of too many logs generated: https://travis-ci.org/apache/cayenne/builds . I turned off all the "pmd" checks, but this wasn't enough. I guess we'll need to find other ways to trim the logs. Cayenne is too big for Travis :)
A.
> On Mar 30, 2016, at 1:18 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>
>> On Mar 30, 2016, at 1:16 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>> I'm just heading home from work now, but go ahead and add whatever changes you need. I don't think maven clean is needed though, and doesn't 'test' already run 'verify' in maven?
>
> Will do. No, verify is a separate stage that happens after package. So *Test and *IT are run at different stages of lifecycle.
>
> A.
>
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 30, 2016, at 1:16 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> I'm just heading home from work now, but go ahead and add whatever changes you need. I don't think maven clean is needed though, and doesn't 'test' already run 'verify' in maven?
Will do. No, verify is a separate stage that happens after package. So *Test and *IT are run at different stages of lifecycle.
A.
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
I'm just heading home from work now, but go ahead and add whatever changes you need. I don't think maven clean is needed though, and doesn't 'test' already run 'verify' in maven?
I've tried to blot out all the maven stuff I have in my head...
Also, was my environment variable setting enough to trigger the different database choices? I'm not sure that was passed on correctly to maven.
Ari
On 30/03/2016 9:12pm, Andrus Adamchik wrote:
> Nice! Especially the status: https://travis-ci.org/apache/cayenne/builds/119484078 :) Let's add something like this:
>
> - script:
> - mvn clean verify
>
> This is needed to run integration tests.
>
> Andrus
>
>> On Mar 30, 2016, at 12:57 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>> On 30/03/2016 8:39pm, Aristedes Maniatis wrote:
>>> enabling travis
>>
>> https://travis-ci.org/apache/cayenne/builds/119484078
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
I also just added a few status badges to our GitHub README.md.
> On Mar 30, 2016, at 1:12 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Nice! Especially the status: https://travis-ci.org/apache/cayenne/builds/119484078 :) Let's add something like this:
>
> - script:
> - mvn clean verify
>
> This is needed to run integration tests.
>
> Andrus
>
>> On Mar 30, 2016, at 12:57 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>> On 30/03/2016 8:39pm, Aristedes Maniatis wrote:
>>> enabling travis
>>
>> https://travis-ci.org/apache/cayenne/builds/119484078
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
Nice! Especially the status: https://travis-ci.org/apache/cayenne/builds/119484078 :) Let's add something like this:
- script:
- mvn clean verify
This is needed to run integration tests.
Andrus
> On Mar 30, 2016, at 12:57 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> On 30/03/2016 8:39pm, Aristedes Maniatis wrote:
>> enabling travis
>
> https://travis-ci.org/apache/cayenne/builds/119484078
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 30/03/2016 8:39pm, Aristedes Maniatis wrote:
> enabling travis
https://travis-ci.org/apache/cayenne/builds/119484078
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 30/03/2016 7:15pm, Andrus Adamchik wrote:
> This will have to go through infra. They only made me a part of the Github "apache" org like a month ago, and I don't have access to the repo "settings" myself either.
For any other committers who want to be joined to the apache github group, just go here https://id.apache.org/ and add your github id to your account yourself.
As for enabling travis, infra need to do that:
https://issues.apache.org/jira/browse/INFRA-11569
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 30, 2016, at 10:59 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> Andrus, can you add me as an admin to https://github.com/apache/cayenne?
This will have to go through infra. They only made me a part of the Github "apache" org like a month ago, and I don't have access to the repo "settings" myself either.
Andrus
Re: 4.0 jenkins build failures
Posted by Aristedes Maniatis <ar...@maniatis.org>.
I've just added the travis file. Andrus, can you add me as an admin to https://github.com/apache/cayenne?
Ari
On 30/03/2016 6:47pm, Andrus Adamchik wrote:
> I wonder if we should experiment with Travis CI, with builds done off of GitHub? In my experience it gives full build isolation, and would also allow us to run our own Docker containers, meaning we can finally test against MySQL and PostgreSQL.
>
> Andrus
>
>
>> On Mar 30, 2016, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Hmm, now 4.0 started failing with random errors. Makes no sense what so ever.
>>
>> A.
>>
>>
>>> On Mar 24, 2016, at 10:01 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>>
>>> Savva recently did some tweaks to 3.1 test bootstrap code to ensure that Jenkins is picking up the right DB type (until now it was testing everything with default DB - HSQL , no matter what Jenkins UI showed). I just edited Jenkins configs to make sure these changes can take effect, added Java 8 dimension, and manually started a 3.1 build. Now that the tests are running against HSQL, H2 and Derby, I expected a fair amount of random failures. Though this is pretty bad:
>>>
>>> https://builds.apache.org/view/A-D/view/Cayenne/job/cayenne-31/126/
>>>
>>> You may remember that the cause of failures is DB cleanup randomness in the tests (not bugs in Cayenne). Those were eradicated in 4.0, stabilizing the builds there. Porting the fixes to 3.1 felt like a huge undertaking and was never pursued. This unfortunately means that now it is hard to separate real errors from noise on the stable branch :-/
>>>
>>> Andrus
>>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: 4.0 jenkins build failures
Posted by Andrus Adamchik <an...@objectstyle.org>.
I wonder if we should experiment with Travis CI, with builds done off of GitHub? In my experience it gives full build isolation, and would also allow us to run our own Docker containers, meaning we can finally test against MySQL and PostgreSQL.
Andrus
> On Mar 30, 2016, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Hmm, now 4.0 started failing with random errors. Makes no sense what so ever.
>
> A.
>
>
>> On Mar 24, 2016, at 10:01 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Savva recently did some tweaks to 3.1 test bootstrap code to ensure that Jenkins is picking up the right DB type (until now it was testing everything with default DB - HSQL , no matter what Jenkins UI showed). I just edited Jenkins configs to make sure these changes can take effect, added Java 8 dimension, and manually started a 3.1 build. Now that the tests are running against HSQL, H2 and Derby, I expected a fair amount of random failures. Though this is pretty bad:
>>
>> https://builds.apache.org/view/A-D/view/Cayenne/job/cayenne-31/126/
>>
>> You may remember that the cause of failures is DB cleanup randomness in the tests (not bugs in Cayenne). Those were eradicated in 4.0, stabilizing the builds there. Porting the fixes to 3.1 felt like a huge undertaking and was never pursued. This unfortunately means that now it is hard to separate real errors from noise on the stable branch :-/
>>
>> Andrus
>