If A and B are only utility modules (not runnable), and you only use the log configuration files for unit testing, I would have moved them to src/test/resources in A and B. That way they are not made available to C. C will have the log configuration file in src/main/resources, at least if it is a war/ear module.
Hope that helps. -ketil On Mon, Apr 27, 2009 at 1:23 PM, Stephen Connolly <[email protected]> wrote: > Create a new module(s) which just has the log configuration... > > then A & B can both depend on this(ese) new module(s)... > > C can exclude the module(s) from it's dependencies on A & B > > 2009/4/26 Olivier Cailloux <[email protected]> > >> Hello list, >> >> I am new to maven and couldn't find a simple and elegant solution to this >> (probably) common problem. >> >> I have three projects : A and B are independent projects and C depends on A >> and B. I use the same logging framework for the three projects (slf4j with >> logback). In A and B, I have a logback.xml configuration file in >> src/main/resources to configure logging behavior (A and B do not necessarily >> have the same configuration). C has also a specific logging configuration >> file. And, naturally, when I run the project C, logback complains that it >> found three logback.xml files in the classpath (the ones from A and B and C) >> when I would like it to find only the one from project C. >> >> I am thus wondering how to avoid this duplication of configuration files >> (or avoid exposure of the A and B configuration files /for dependent >> projects/). (Naturally completely "excluding" logback.xml in A and B >> wouldn't solve my problem as it would also exclude the configuration file >> when running A or B themselves.) >> >> >> More generally, is there some tutorial or best-practice about configuring >> logging for easy deployment and user-tweaking with maven? I would ideally >> like the end-user to be easily able to modify the logging strategy, while >> providing him sensible defaults. Probably the logback.xml file should not be >> embedded in the .jar, but I don't know how to do that (and don't know if >> this is the best solution!) >> >> Thank you for any pointer. >> Olivier >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
