Re: Best practices for avoiding duplicate configuration files
Ceki Gulcu a écrit : Olivier, Since projects A and B seem to be just artifacts, I am still wondering why projects A and B need a configuration file for logging. If it is for testing purposes, why not use logback-text.xml and place it under /src/test/resources/ directory? Indeed, it appears to me now that I was mixing two different purposes for my projects A and B: they aim to produce a usable library (reusable components for developers) AND they are providing some simple main class and launcher to enable direct, simple usage for a non-developer end-user. I guess I should separate these two concerns and develop 1) a project intended as a library, with the logging component and config files only in the "test" scope (and no need to include the launcher here) 2) a project intended for use by the end-user, dependant on the above library, and with the logging component provided at runtime. That might suffice to solve most of my problems of duplicate config files which were due to this mixing of concern in my mind. Anyway, my questions were more general than to be applied only on my current projects, so it was very useful to be able to think about other solutions. (Off-topic again, I must say I appreciate very much slf4j and logback-classic, and the "complain" of logback has not been annoying to me but rather useful as it allowed me to take note of an incorrect design in my projects.) Olivier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Olivier, Since projects A and B seem to be just artifacts, I am still wondering why projects A and B need a configuration file for logging. If it is for testing purposes, why not use logback-text.xml and place it under /src/test/resources/ directory? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
2009/4/29 Ceki Gulcu > > > But what is annoying to me is that these redundant files > > are included when they should not, because from a logical point of > > view project C does not need the config files of project A or B. > => This means you should go into a D project (Stephen proposal) ... even if it is heavy for flyweight issues. To my mind the unpack/repack proposal is far less heavy/complicated than this point ... Particularly, it implies project C to "foresee" existence of certain files in your projects A & B (don't forget these projects could evolve without notifying C) : wouldn't it be dangerous ? > > > This is somewhat off topic, but since the question has been raised in > this forum, allow me to explain. > > First, it is not SLF4J which is complaining, it's logback-classic > which Olivier indicated he was using. During automatic > initialization, if and when logback-classic sees two or more > configuration files on the class path, it emits a warning: > "Hey, I see N different copies of logback.xml on your class path. The > copies are located at path1, path2, ..., pathN. I am picking the first > one." (It's just a warning...) > > Lobgack-classic is noticing an ambiguity and informing the user. > > HTH, > > -- > Ceki Gülcü > Logback: The reliable, generic, fast and flexible logging framework for > Java. > http://logback.qos.ch > > Cool ! I'm rassured ;-)
Re: Best practices for avoiding duplicate configuration files
> About slf4j complaining about multiple configuration files present in > the CP, I suppose it must be possible to overcome this > complaining. But what is annoying to me is that these redundant files > are included when they should not, because from a logical point of > view project C does not need the config files of project A or B. Even > if I get slf4j to ignore them, I would consider that a workaround > rather than a solution. This is somewhat off topic, but since the question has been raised in this forum, allow me to explain. First, it is not SLF4J which is complaining, it's logback-classic which Olivier indicated he was using. During automatic initialization, if and when logback-classic sees two or more configuration files on the class path, it emits a warning: "Hey, I see N different copies of logback.xml on your class path. The copies are located at path1, path2, ..., pathN. I am picking the first one." (It's just a warning...) Lobgack-classic is noticing an ambiguity and informing the user. HTH, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Once again, thank you to everyone who answered. I will investigate these proposals. About slf4j complaining about multiple configuration files present in the CP, I suppose it must be possible to overcome this complaining. But what is annoying to me is that these redundant files are included when they should not, because from a logical point of view project C does not need the config files of project A or B. Even if I get slf4j to ignore them, I would consider that a workaround rather than a solution. So I will investigate the other solutions proposed, namely with assembly & relevant advices... Olivier Nick Stolwijk a écrit : - 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 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:
Re: Best practices for avoiding duplicate configuration files
> - 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 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, nat
Re: Best practices for avoiding duplicate configuration files
On 27 Apr 2009, at 21:32, Frédéric Camblor wrote: 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 section. Have you searched in slf4j if it isn't possible to "disable" this "complaining" ? That's the whole point of the slf4j. You nail down the implementation you want by specifying it up-front. It seems to be a reaction against the commons-logging façade. http://www.slf4j.org/faq.html#yet_another_facade Don't ask me much more, as I just use log4j. :) -Dom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
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 section. Have you searched in slf4j if it isn't possible to "disable" this "complaining" ? Cheers, Frederic 2009/4/27 Brian Fox > > > 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, w
Re: Best practices for avoiding duplicate configuration files
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 default
Re: Best practices for avoiding duplicate configuration files
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
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 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 > >> 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: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
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 > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Best practices for avoiding duplicate configuration files
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
