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]
