Hi Olivier, This is only a point of view but... Isn't the problem coming from the slf4f framework ?
I don't really know this logging framework, but it astonishes me that it complains about multiple configuration in the classpath. Generally, framework takes (like commons-logging or log4j) the first config file found in the classpath so that responsibility is delegated to the order in which you put artefacts in your <dependencies> section. Have you searched in slf4j if it isn't possible to "disable" this "complaining" ? Cheers, Frederic 2009/4/27 Brian Fox <[email protected]> > > > Olivier Cailloux wrote: > >> Thanks to everybody who answered. I answer to everyone together: >> - Projects A and B are to be runnable independently and deployable without >> C. So putting the log config in test resources would not work. >> - Putting the log files in a dependent module is possible. But: >> - it would render the pom and project management more complex. Currently >> these projects are not multi-modules, they are very simple, and that >> solution would involve transforming them to multi-module projects with one >> module being a whole module for only one stupid configuration file! And then >> having the project C exclude the right sub-module. But I admit that it is >> not my main concern (I could accept a complex solution if it was very good >> in other aspects) ; >> > > That's right but generally this config file would not be part of the same > tree that you build everytime. That is to say it has it's own lifecycle and > is released far less often than the projects that use it. > >> - it is not very elegant as any project depending on A or B would have to >> not forget to exclude the sub-module containing the log files (any dependent >> project would have the same problem a >> s the project C has) ; >> > Not true because you don't have to mark it as a dependency. You can use > dependency unpack (as opposed to unpack-dependencies) and this will not > affect the dependency tree. Or you could use scope=provided / optional=true > which means upstream dependencies would ignore it. > >> - it does not solve the question of the log configuration file not being >> integrated in the jar for easily modification by the end-user after >> deployment ; >> - the problem I face is a general problem, as I always use log >> configuration files in my projects, so I would like to find a good solution >> once and for all. >> >> You can unpack the zip file and leave them with just the log config file. > >> - The use of Assembly and Dependency plugins is maybe part of a solution, >> but I don't see clearly how I can configure all this to do what I would like >> and avoiding ending up with pom files more complex than needed. >> >> To re-cap, I dream of a solution allowing me the following two >> possibilities, for any project I create: >> - a possibility to create and expose (for use by dependent projects) a >> .jar file NOT containing the log configuration file ; >> - a possibility to create and deploy (for end-user usage) a .zip file >> containing the above .jar AND the log configuration file, which is then easy >> for the end-user to modify ; and some start-up script (portable) or >> something equivalent to correctly configure the classpath to include the log >> configuration file and allow the end-user to easily start the application >> (this is the part I don't see how to do with the FAQ provided at >> http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). >> >> >> This is also possible, just don't put the log file in /target/classes and > it won't get jar'd up. You can then use the assembly plugin to zip up the > final jar along with the config file unpacked earlier. > > > Although the solutions proposed did not fully satisfy my needs, I have to >> thank those who responded because it gave me good hints and allowed me to >> re-think about my problem. Any more advices would be very appreciated >> because I am a beginner in Maven and I think there must be somehow a simple >> solution to my needs which I simply overlooked. I am wondering how the >> others do as this must be a very common problem (everybody use logging >> framework!). >> >> Also, sorry for my English... >> Olivier >> >> Brian Fox a écrit : >> >>> See the 9th bullet point here: >>> http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ >>> >>> On 4/26/2009 3:17 PM, Olivier Cailloux wrote: >>> >>>> 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] >>> >>> >> >> >> --------------------------------------------------------------------- >> 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] > > -- Frédéric Camblor
