Hmmm sometimes I do it.  Sometimes tests pass in eclipse which makes me wonder what is going on when the same test fails with maven.  Turning on tracing (DEBUG) in these cases has some value but it is not used all the time but under these not so rare circumstances.

Alex

On 6/23/07, Chris Custine <chris.custine@gmail.com> wrote:
I forgot to mention that JUnit and slf4j are the only modules that EVERY subproject have in common, so that drove me to thinking that we could simplify the setup.

One more thing, in my own projects I use slf4j-simple as a test scope dependency to satisfy unit testing output.  slf4j-simple outputs INFO, WARN, and ERROR log levels to stdout and that is all it does.  I was thinking we could use that as a standard dependency (test scope) and use nlog4j where we create packages.  Does anyone ever want to output DEBUG while running unit tests?

Chris


On 6/23/07, Alex Karasulu < akarasulu@apache.org> wrote:
Go for it Chris! I trust you have a better grasp of this than I do.

Thanks,
Alex


On 6/21/07, Chris Custine < chris.custine@gmail.com> wrote:
While I was looking into the server-main logging issue ( https://issues.apache.org/jira/browse/DIRSERVER-979 ), I came to the conclusion that our logging config in the poms needs some cleanup so I want to make the following proposal.

1). Add slf4j default dependencies to parent pom.xml for each project such as daemon, shared, apacheds).  There is a lot of duplication of logging setup in every subproject, so this would configure the default as slf4j-api for compile scope and either slf4j-simple or slf4j-nlog4j for test scope (requires concrete slf4j impl for JUnit tests).  This would mean that normal subprojects don't need additional dependencies in their pom and will use the default which works for almost all 35-40 subprojects except those that require actual runtime packaging.  For the remaining projects that require runtime dependencies such as server-installers, server-main, and the plugins, we just add a concrete slf4j implementation like nlog4j to the subproject pom and it will package up all the dependencies.  This config will also help fix https://issues.apache.org/jira/browse/DIRSERVER-979 and it limits transitive dependencies in our maven artifacts so that users can use their own impls.

2). Replace commons-logging with jcl104-over-slf4j which is a clone of commons-logging that will just defer to slf4j.  Commons-logging is required at runtime by spring and possibly some other dependencies but it has some peculiar problems that aren't obvious.  If anyone wants more info on this I can go on for days about it...

I was also thinking we could provide maven profiles for specifying the inclusion of different log impls in server-main since this has come up a few times.  The installers will package nlog4j as a default, and the user can change them out if required.

I would also like to go ahead and update the apacheds, shared, and daemon parent poms to *-parent since it also requires modifying all of the poms in each subproject ( https://issues.apache.org/jira/browse/DIRSERVER-977) as long as no one objects.  I have all of these changes running locally and have tested them out quite a bit today.

Sorry this is a little lengthy.  Does anyone have any opinions or ideas?

Chris