Hi all,
updated 2): Jenkins instance is NOT https://smilebase.ci.cloudbees.com/ ! The correct URL is
https://logback.ci.cloudbees.com
@ceki: you are now admin of https://logback.ci.cloudbees.com
If someone wants to access the Jenkins instance, please create an Cloudbees account and
send me an email.
@ceki: can you please add the email address
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.chChristian2012/6/18 ceki <ceki@qos.ch>
On 18.06.2012 17:32, Christian Trutz wrote:You would need to have an oracle-profile, mysql-profile,
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?
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.That would be great thanks.
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.
Looking at [1], although ootb there is a javaagent attached to the
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.
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/cflvr9rThank you. To be precise, it's actually logback-mongodb-parent pom
Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and
access ...
module plus 3 children: logback-mongodb-core, logback-mongodb-classic
and logback-mongodb-access.I think it would be easier if you could push the docs onto http://logback.qos.ch directly. We can discuss this later.
>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
--
Ceki
http://twitter.com/#!/ceki
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev