You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Olivier Cailloux <ol...@ulb.ac.be> on 2009/04/26 21:17:29 UTC
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Olivier Cailloux <ml...@ulb.ac.be>.
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 <ml...@ulb.ac.be> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best practices for avoiding duplicate configuration files
Posted by Nick Stolwijk <ni...@gmail.com>.
> - 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 <ml...@ulb.ac.be> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Dominic Mitchell <do...@semantico.com>.
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 <dependencies> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Frédéric Camblor <fc...@gmail.com>.
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 <br...@infinity.nu>
>
>
> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Frédéric Camblor
Re: Best practices for avoiding duplicate configuration files
Posted by Brian Fox <br...@infinity.nu>.
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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Olivier Cailloux <ml...@ulb.ac.be>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Brian Fox <br...@infinity.nu>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Ketil Aasarød <ke...@gmail.com>.
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
<st...@gmail.com> 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 <ol...@ulb.ac.be>
>
>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Posted by Stephen Connolly <st...@gmail.com>.
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 <ol...@ulb.ac.be>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>