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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
