Hi Ceki,

>There is no Jenkins instance for logback/logback-extensions. There was
>a CI for logback a few years back but I no longer had the time to
>maintain the instance.

I configure a Jenkins instance on http://www.cloudbees.com/
for logback-extensions

1) a new build is triggered instantly after a "git push" on GitHub (via service hook)
2) Jenkins instance is https://smilebase.ci.cloudbees.com/
3) if build fails a email is send to logback-dev@qos.ch

Christian


2012/6/18 ceki <ceki@qos.ch>
On 18.06.2012 17:32, Christian Trutz wrote:
Hi ceki,

thank you very much for your remarks :-)

Remark 1): yes i agree with you, that integration tests are also very
usefull and only
with integration tests you know, that the software do what you want.
I thought that maybe Maven profiles could be very useful to separate
execution of
integration tests. Only with profile (say "integration-tests") the
integration tests will
be executed. Have we any Hudson/Jenkins instance for logback-extensions?

You would need to have an oracle-profile, mysql-profile,
postgres-profile and mongo-db profile. I think it might be easier to
keep track of the machines in code as is done in
DBAppenderIntegrationTest. Using profiles has the advantage of
decoupling the tests run from the test code. The isConformantHost
check is quick-and-dirty but gets the job done.

There is no Jenkins instance for logback/logback-extensions. There was
a CI for logback a few years back but I no longer had the time to
maintain the instance.


Remark 2): I am using TestNG only because it was included, not because I
think it
is necesary. I will change the logback-ext-mongodb unit tests to JUnit
tests.

That would be great thanks.


Remark 3):
 >If I understand correctly, Jmockit relies on a java-agent to execute?
Yes, with jdk1.5 it relies on java-agent, with jdk1.6. it runs also
without java-agent.
We have jdk1.6. so we do not need any java-agent configurations, the
tests run OTB.

Looking at [1], although ootb there is a javaagent attached to the
JVM. I might be wrong here but using a Java agent to run tests seems
like an awfully heavy handed method. It affects every single class
loaded into memory. The MockitoJUnitRunner approach seems less
invasive imho.

[1] http://tinyurl.com/cflvr9r


Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and
access ...

Thank you. To be precise, it's actually logback-mongodb-parent pom
module plus 3 children: logback-mongodb-core, logback-mongodb-classic
and logback-mongodb-access.


 >Notwithstanding the above remarks, I am looking forward to testing
logback-mongodb-* once I install MongoDB on my local machine.
OK please look also to
https://github.com/qos-ch/logback-extensions/wiki/MongoDB

I think it would be easier if you could push the docs onto http://logback.qos.ch directly. We can discuss this later.


--
Ceki
http://twitter.com/#!/ceki
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev