[logback-user] Building logback when tests fail
Thorbjørn Ravn Andersen
thunderaxiom at hotmail.com
Wed Nov 9 10:05:45 CET 2011
(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
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
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
You can then once in a while harvest the best comments for real
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.
From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at 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
On 28.10.2011 11:11, Thorbjørn Ravn Andersen wrote:
> 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
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
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.
Logback-user mailing list
Logback-user at qos.ch
More information about the Logback-user