> - 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 as the project C has) ;
This is not a very good point, as jar files should never be adjusted after releasing. >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 This is a good solution and there exists a plugin for this, ie. the Application Assembler Maven Plugin[1]. Here is a good blog about adding your own files to the app assembly [2]. [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ [2] http://www.joelpm.com/2009/01/23/maven-assembly-plugin-woes/ Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Apr 27, 2009 at 7:41 PM, Olivier Cailloux <[email protected]> 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) ; > - 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 as the project C has) ; > - 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. > > - 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/). > > 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]
