Thanks for a prompt reply. I am building directly from a clone of git master. Is there a specific tag I should use to choose a suitable commit? Maven reports: Tests in error: autoConfigFromSystemProperties(ch.qos.logback.classic.util.ContextInitialize rTest) autoStatusListener(ch.qos.logback.classic.util.ContextInitializerTest) autoOnConsoleStatusListener(ch.qos.logback.classic.util.ContextInitializerTe st) testGetExistingContext(ch.qos.logback.classic.selector.ContextJNDISelectorTe st) testCreateContext(ch.qos.logback.classic.selector.ContextJNDISelectorTest) defaultContext(ch.qos.logback.classic.selector.ContextJNDISelectorTest) testDetach(ch.qos.logback.classic.selector.ContextDetachingSCLTest) testDetachWithMissingContext(ch.qos.logback.classic.selector.ContextDetachin gSCLTest) scan1(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) randomTest(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) scanWithFileInclusion(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) scanWithResourceInclusion(ch.qos.logback.classic.turbo.ReconfigureOnChangeTe st) includeScanViaInputStreamSuppliedConfigFile(ch.qos.logback.classic.turbo.Rec onfigureOnChangeTest) gscan1(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) scan_lbclassic154(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) directPerfTest(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) indirectPerfTest(ch.qos.logback.classic.turbo.ReconfigureOnChangeTest) Tests run: 374, Failures: 0, Errors: 17, Skipped: 10 You may have forgotten to check in some files? Have your CI-engine reported anything? If you use IDEA and it works well, I'll have a go tomorrow. We happen to have a license for IntelliJ IDEA 9. /Thorbjørn -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of ceki Sent: 25. oktober 2011 13:59 To: logback users list Subject: Re: [logback-user] Building logback when tests fail Hi Thorbjørn, Are you building from git master or from a released version? More inline. On 25/10/2011 1:45 PM, Thorbjørn Ravn Andersen wrote:

Hi.

I am trying to set up Logback for development in order to write a JDK14Appender (based on the bridge) and my cloned source fails in testing with “[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.6:test (default-test) on project logback-classic: There are test failures.” so I cannot run the "mvn package" command listed on the documentation page.

Can you provide more information on the test failures?

Running “mvn -Dmaven.test.skip=true package” gives me “[ERROR] Failed to execute goal on project logback-classic: Could not resolve dependencies for project ch.qos.logback:logback-classic:jar:0.9.30-SNAPSHOT: Could not find artifact ch.qos.logback:logback-core:jar:tests:0.9.30-SNAPSHOT

Logback classic test requires logback-core-test.jar.

I'd like to get this up and running in Eclipse but it is not quite easy even with both egit and Eclipse Maven plugins.

Logback now relies on both Groovy (GafferConfigurator) and Scala (for tests) in addition to Java. IntelliJ IDEA deals with this particular language configuration very nicely. I've heard that running Groovy+Scala projects may be difficult to set up with Eclipse. I'd be quite interested in your feedback in this regard.

What would you suggest me to do to get up and running?

The current situation where Java+Groovy+Scala projects cannot be run in Eclipse is rather problematic. It needs to be addressed asap. -- Ceki http://twitter.com/#!/ceki _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user

In that case it appears that I am missing some files. IDEA 10 (Community Edition) complains about plenty e..g not being able to find SizeBasedRolling_STest.class, TimeBasedRolling_STest.class, SizeAndTimeBasedFNATP_STest.class And there were some comments about refactoring these five months ago. Can anybody else either confirm my findings that logback doesn't build or confirm that repository X builds as is of today? -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of ceki Sent: 25. oktober 2011 15:03 To: logback users list Subject: Re: [logback-user] Building logback when tests fail On 25/10/2011 2:34 PM, Thorbjørn Ravn Andersen wrote:

Thanks for a prompt reply.

I am building directly from a clone of git master. Is there a specific tag I should use to choose a suitable commit?

No, need to chose a special tag or commit. Clone of master should be fine.

Maven reports:

Tests in error:

autoConfigFromSystemProperties(ch.qos.logback.classic.util.ContextInitialize

rTest)

[snip] That's a lot of failures.

Tests run: 374, Failures: 0,git Errors: 17, Skipped: 10

You may have forgotten to check in some files? Have your CI-engine reported anything?

No, logback build on different machines. However, on busy or slow machines build failures occur frequently. Failures in ContextInitializerTest seem to indicate that the tests are not run in an independent JVM. Failures in ReconfigureOnChangeTest indicate that the tests are run on a slow/busy machine. It sucks that logback does not build on all machines.

If you use IDEA and it works well, I'll have a go tomorrow. We happen to have a license for IntelliJ IDEA 9.

IDEA licenses are date-based, at the least the license I have is. So you should be able to upgrade to the latest version of IDEA with your existing license. -- Ceki _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user

BTW, I am working on making the tests more robust. In principle, you should be able to build the project in maven, which will create the required scala test classes. Once the scala test classes are built, you won't even need to install the Scala plugin for IDEA. (However, I have not tried this, so the Scala plugin might be required after all.) If you run into trouble, just ask for help here. On 25/10/2011 8:36 PM, ceki wrote:

Classes ending in STest are tests classes written in Scala. You need to add the Scala plugin to IDEA and then add Scala facet to the project.

On 25/10/2011 6:17 PM, Thorbjørn Ravn Andersen wrote:

...

In that case it appears that I am missing some files. IDEA 10 (Community Edition) complains about plenty e..g not being able to find

SizeBasedRolling_STest.class, TimeBasedRolling_STest.class, SizeAndTimeBasedFNATP_STest.class

And there were some comments about refactoring these five months ago.

Can anybody else either confirm my findings that logback doesn't build or confirm that repository X builds as is of today?

-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of ceki Sent: 25. oktober 2011 15:03 To: logback users list Subject: Re: [logback-user] Building logback when tests fail

On 25/10/2011 2:34 PM, Thorbjørn Ravn Andersen wrote:

...

Thanks for a prompt reply.

I am building directly from a clone of git master. Is there a specific tag I should use to choose a suitable commit?

No, need to chose a special tag or commit. Clone of master should be fine.

...

Maven reports:

Tests in error:

autoConfigFromSystemProperties(ch.qos.logback.classic.util.ContextInitialize

...

rTest)

[snip]

That's a lot of failures.

...

Tests run: 374, Failures: 0,git Errors: 17, Skipped: 10

You may have forgotten to check in some files? Have your CI-engine reported anything?

No, logback build on different machines. However, on busy or slow machines build failures occur frequently. Failures in ContextInitializerTest seem to indicate that the tests are not run in an independent JVM. Failures in ReconfigureOnChangeTest indicate that the tests are run on a slow/busy machine.

It sucks that logback does not build on all machines.

...

If you use IDEA and it works well, I'll have a go tomorrow. We happen to have a license for IntelliJ IDEA 9.

IDEA licenses are date-based, at the least the license I have is. So you should be able to upgrade to the latest version of IDEA with your existing license.

-- Ceki

-- -- Ceki http://twitter.com/#!/ceki

Answers in-line. On 28.10.2011 11:11, Thorbjørn Ravn Andersen wrote:

Hi.

After quite a bit of poking I found several things:

* IntelliJ IDEA 9 didn't support the Scala facet.

OK although not surprising.

* IntelliJ IDEA 10 Community Edition works. You need to install the Scala facet _first_ and configure it inside IDEA, and under Windows install the latest git distribution before using the github method on the front page to pull out from a VCS.

Installing the Scala facet first is a good point. I had reached a similar conclusion as well. As for git support in IDEA, I personally prefer the command line and have no experience with IDEA's support for git.

Now I have a workspace without compilation errors and absolutely no idea of how to continue from here in an IDE I am unfamiliar with. It is a testament to the usefulness of logback that I even got this far without deciding my time is better used on something else.

Absolutely, imposing IDEA as the IDE for logback is not the most inviting proposal for new contributors.

May I suggest that you consider lowering the threshold of how much work is actually needed to be _able_ to contribute to logback?

Makes a lot of sense.

If I want to add a few lines to the current "How to build logback" instructions on the web sites, I am expected to open a _bug report_ preferably with a patch attached to the underlying html-pages which you then need to have time to approve, check in, rebuild and deploy the website.

You can fork logback on github, make your changes and submit a pull request. Once your changes are verified, thet are fairly trivial to merge. The changes will be available with the next release. The only serious bottle neck is the verification. I sometimes reject or delay good contributions.

That is probably not optimal. As you already know JIRA, you might also find Confluence (the Atlassian Wiki product) interesting, and it is free for open source projects (http://www.atlassian.com/software/views/open-source-license-request).

Currently, logback documentation consists of plain html file. These files are in maintained in git under the logback-site module. Would moving to Confluence entail that these files be migrated/moved into Confluence?

If you want to keep strict control of the official documentation, then just have a "Comments" link on the bottom of each page for a identically named page in Confluence.

What would that do?

For now, I have decided that I will develop the JDK14Appender I need based on a binary logback distribution instead.

You can build logback under maven and let Eclipse pickup the .class files associated with the STest test classes. Actually, working with the binary has the same effect. Right?

Thanks for your prompt help

That's the least I could do.

/Thorbjørn

-- Ceki

(Not answering inline as this is Outlook) I like the git command line for its powers, but navigation in history, branches etc. is frequently easier inside an IDE. I like to have both options. Regarding what you impose, it is your choice as the dictator, but you may want to update the build instructions. While checking out the instructions again, I see you've released 1.0.0. Congratulations on reaching that milestone. I see you've added a link to Building with an IDE (misspelling: udner). I will have a look at the instructions, notably for Eclipse, at a later time. The reason for allowing commentary on your existing documentation would be exactly that - to allow people to comment without having to submit patches to you, have them approved and you at your leisure release a new version. Having the Wiki separately would allow you to keep the existing infrastructure and approval process, while lowering the threshold for submitting information fragments. If you are not familiar with a grassroot wiki and what it may result in as opposed to the tightly controlled Wikipedia, check out the original Wiki at http://c2.com/cgi/wiki. The discussion style I'm thinking about is shown at http://c2.com/cgi/wiki?OnlySayThingsThatCanBeHeard (which was just picked randomly). You can then once in a while harvest the best comments for real documentation. And another thing. I was wondering why you brought Groovy into it in the first place (biting us now making the IDE configuration tedious). Is it to provide for a more expressive configuration language than static XML which does not allow writing runnable code, so you have to bring in all kinds of interpretation at parse time to essentially allow the user to execute code at run time. If so, I have had thoughts on whether a tiny Lisp interpreter could be useful for having essentially code provided in your configuration files for your Java programs. Much the same thought that caused GNU to create the Guile library. This would give the same tinkering capability as found in Emacs if done properly. /Thorbjørn -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of ceki Sent: 28. oktober 2011 14:43 To: logback users list Subject: Re: [logback-user] Building logback when tests fail Answers in-line. On 28.10.2011 11:11, Thorbjørn Ravn Andersen wrote:

Hi.

After quite a bit of poking I found several things:

* IntelliJ IDEA 9 didn't support the Scala facet.

OK although not surprising.

* IntelliJ IDEA 10 Community Edition works. You need to install the Scala facet _first_ and configure it inside IDEA, and under Windows install the latest git distribution before using the github method on the front page to pull out from a VCS.

Installing the Scala facet first is a good point. I had reached a similar conclusion as well. As for git support in IDEA, I personally prefer the command line and have no experience with IDEA's support for git.

Now I have a workspace without compilation errors and absolutely no idea of how to continue from here in an IDE I am unfamiliar with. It is a testament to the usefulness of logback that I even got this far without deciding my time is better used on something else.

Absolutely, imposing IDEA as the IDE for logback is not the most inviting proposal for new contributors.

May I suggest that you consider lowering the threshold of how much work is actually needed to be _able_ to contribute to logback?

Makes a lot of sense.

If I want to add a few lines to the current "How to build logback" instructions on the web sites, I am expected to open a _bug report_ preferably with a patch attached to the underlying html-pages which you then need to have time to approve, check in, rebuild and deploy the website.

You can fork logback on github, make your changes and submit a pull request. Once your changes are verified, thet are fairly trivial to merge. The changes will be available with the next release. The only serious bottle neck is the verification. I sometimes reject or delay good contributions.

That is probably not optimal. As you already know JIRA, you might also find Confluence (the Atlassian Wiki product) interesting, and it is free for open source projects (http://www.atlassian.com/software/views/open-source-license-request).

Currently, logback documentation consists of plain html file. These files are in maintained in git under the logback-site module. Would moving to Confluence entail that these files be migrated/moved into Confluence?

If you want to keep strict control of the official documentation, then just have a "Comments" link on the bottom of each page for a identically named page in Confluence.

What would that do?

For now, I have decided that I will develop the JDK14Appender I need based on a binary logback distribution instead.

You can build logback under maven and let Eclipse pickup the .class files associated with the STest test classes. Actually, working with the binary has the same effect. Right?

Thanks for your prompt help

That's the least I could do.

/Thorbjørn

-- Ceki _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user