Re: JPMS whitebox testing issues
I forgot to mention that the original mail from Stephen is quite informative and I thank him for that. On 10/10/2024 22:49, Ceki Gulcu wrote: Hi Stephen, Thank you for broaching the issue of whitebox testing with JMPS. I think that it is an important topic. I should also like to mention for a related feature. If JMPS project "Bee" depends on JMPS project "Insect", is often useful to use the insect-tests.jar in the tests of project "Bee". Perhaps if the whitebox testing issue with JMPS is settled on, then depending on tests-jars can be solved as well. Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JPMS whitebox testing issues
Hi Stephen,
Thank you for broaching the issue of whitebox testing with JMPS. I think
that it is an important topic.
I should also like to mention for a related feature.
If JMPS project "Bee" depends on JMPS project "Insect", is often useful
to use the insect-tests.jar in the tests of project "Bee". Perhaps if
the whitebox testing issue with JMPS is settled on, then depending on
tests-jars can be solved as well.
Best regards,
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 23/09/2024 17:47, Stephen Colebourne wrote:
Hi all,
Apologies for the long email, but whitebox testing is a complex topic.
I know not everyone agrees with whitebox testing, but it is a major
factor in how many projects are written, and IMO Maven should fully
and easily support it.
A "whitebox mode" test has two module-info.java files, both with the
same module name. The goal is to support unit testing with full access
to the internals of the module as in the "good ole days" while
ensuring that the test occurs on the module-path (test failures can
occur on the module-path which do not occur on the class-path, and
vice versa):
root
- pom.xml
- src/main/java
-- module-info.java
-- mypackage
--- Main,java
- src/main/resources
-- mypackage
--- main.txt
- src/test/java
-- module-info.java
-- mypackage
--- Test,java
The main module-info would be something like:
module mymodule {
exports mypackage;
}
The test module-info would be something like:
open module mymodule {
// duplicate contents of main module-info
exports mypackage;
// any additional test dependencies/services
requires transitive org.junit.jupiter;
}
The good news is that a setup like this mostly works today in Maven
(tested with v3.9.9 and Java 21).
However there are three key issues:
The way Maven currently operates is:
1) In `testCompile`, the test source code is compiled using:
--module-path target/test-classes:target/classes
--patch-module mymodule=src/main/java
2) In `surefire`, the tests are run with:
--module-path target/test-classes:target/classes:<< dependencies >>
--class-path << surefire jar files >>
What actually happens is (I think) very surprising. TestCompile
compiles BOTH the main and test source code into
`target/test-classes`:
target/classes contains
- module-info.class (from src/main/java)
- mypackage/Main.class
- mypackage/main.txt
target/test-classes contains
- module-info.class (from src/test/java)
- mypackage/Main.class
- mypackage/Test.class
This results in three issues:
A) The code in `src/main/java` is compiled twice, which is
unnecessary, surprising and slows things down
B) There is no need to refer to `target/classes` on the module-path,
as it is not used in TestCompile or Surefire.
C) Any resource files (src/main/resources) are UNAVAILABLE to
Surefire, which results in the tests failing, eg.
`Main.class.getResourceAsStream("main.txt")` will return null. This is
because Surefire sees the code in target/test-classes as the complete
definition of the module, and as shown above `main.txt` is not present
in `target/test-classes`.
-
Option 1:
Do nothing. End users can fix the resource file issue by adding this
to the pom.xml:
org.apache.maven.plugins
maven-surefire-plugin
--patch-module mymodule=src/main/resources;
This causes Surefire to pickup the resource folder and patch it into the module.
Option 2:
Automate the patch-module described above. When Surefire runs in
"whitebox mode", the --patch-module outlined above should be
automatically generated and added to the command line. Care will be
needed not to clash with any patch-module the user adds manually.
This fixes issue C.
Option 3:
Properly address the issue. maven-compiler-plugin already recognises
that there are two module-info.java files and checks the names. If
they are different it sets up "blackbox mode". IMO,
maven-compiler-plugin needs an official "whitebox mode".
The correct approach, as far as I can determine, is for TestCompile to
do the following:
--module-path target/test-classes
--patch-module mymodule=target/classes
This avoids the main source code being compiled twice - it is patched
in instead.
The same change needs to be applied to Surefire
--module-path target/test-classes:<< dependencies >>
--patch-module mymodule=target/classes
This fixes issues A , B and C. (The resource files in target/classes
are patched in alongside the .class files).
Note that the java command line generates a warning about duplicate
module-info.class files, but that is expected in this case,and can be
ignored.
---
So, what do people think? Is there appetite to raise an issue to get
option 2 or 3 done?
thanks for reading this far
Stephen Colebourne
PS. IDEs don't like the two module-info.java files of whitebox
testing, but that's OK - Maven isn't beholden to IDEs. It also turns
out there is an easy workaround for IDEs (which I can describe in
Re: Unexpected behavior of the javadoc plugin?
Hi Tamás, Thank you for your comments. My question is more regarding the need to place a javadoc element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml. Once the javadoc related element is in the BOM file, it works fine. However, given the BOM file is intended to be imported, I would prefer to keep it minimal and have it free of any and elements in order to not pollute importing projects. Is my concern warranted? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 12/28/2023 7:17 PM, Tamás Cservenák wrote: > Hej Ceki, > > I also experience javadoc misbehaviour when JPMS/jigsaw is involved, and _I > think_ it boils down when it tries to be "smart" when it comes to JPMS... > See master of maven-resolver, as it was suffering with similar issues, and > this change: > https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae > (that was a few releases ago, things may have changed around). > > Try out this flag if you are on fairly new version: > https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode > > HTH > Tamas > > On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu wrote: > >> >> Hello all, >> >> Given the javadoc generation is an important part of software projects, >> maybe someone would care to comment whether the behavior described below >> is expected or not? >> >> In the meantime, happy new year to all, >> >> -- >> Ceki Gülcü >> >> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch >> >> On 12/23/2023 9:34 PM, Ceki Gulcu wrote: >>> >>> Hello, >>> >>> I would like to share what looks to me like an unexpected behavior of >>> the javadoc plugin, more specifically when run as javadoc:aggregate. >>> >>> >>> The SLF4J project uses the "Refining the BOM Pattern" variant as >>> explained in Garret Wilson's "Improving the BOM Pattern" [1]. More >>> specifically, the top level pom.xml is the BOM and project modules >>> import ../parent/pom.xml. >>> >>> Source code is available at [2]. >>> >>> Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized >> project. >>> >>> When trying to create aggregated javadocs with the javadoc:aggreate >>> command, the javadoc generation would fail with javadoc complaining >>> about unnamed modules and other miscellaneous problems. The solution was >>> to skip certain modules for which there was no need to generate javadocs >>> to begin with. >>> >>> Surprisingly, adding in parent/pom.xml of the >>> javdoc-plugin configuration would have no effect. However, specifying >>> -Dmaven.javadoc.skippedModules would work as expected. >>> >>> The advice commonly found on various forum about the placement of the >>> javadoc plugin configuration pertain to and/or >>> section. In my case, this advice looks irrelevant (see below). >>> >>> After a lot of head scratching, placing the javadoc-plugin configuration >>> in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin >>> configuration have the desired effect. This is quite surprising as the >>> configuration of other plugins have an effect when placed in >> parent/pom.xml. >>> >>> To reproduce this behavior, you can check out the code of the SLF4J >>> project from [2] and run "mvn javadoc:aggregate". (To observe a failure >>> the javadoc-plugin configuration needs to commented out in top-level >>> pom.xml and uncommented in parent/pom.xml before running "mvn >>> javadoc:aggregate".) >>> >>> I am wondering whether the behavior of javadoc:aggregate described above >>> is expected or actually a problem? >>> >>> Best regards, >>> >>> [1] >> https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern >>> [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x >>> >> >> - >> 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: Unexpected behavior of the javadoc plugin?
Hello all, Given the javadoc generation is an important part of software projects, maybe someone would care to comment whether the behavior described below is expected or not? In the meantime, happy new year to all, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 12/23/2023 9:34 PM, Ceki Gulcu wrote: > > Hello, > > I would like to share what looks to me like an unexpected behavior of > the javadoc plugin, more specifically when run as javadoc:aggregate. > > > The SLF4J project uses the "Refining the BOM Pattern" variant as > explained in Garret Wilson's "Improving the BOM Pattern" [1]. More > specifically, the top level pom.xml is the BOM and project modules > import ../parent/pom.xml. > > Source code is available at [2]. > > Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized project. > > When trying to create aggregated javadocs with the javadoc:aggreate > command, the javadoc generation would fail with javadoc complaining > about unnamed modules and other miscellaneous problems. The solution was > to skip certain modules for which there was no need to generate javadocs > to begin with. > > Surprisingly, adding in parent/pom.xml of the > javdoc-plugin configuration would have no effect. However, specifying > -Dmaven.javadoc.skippedModules would work as expected. > > The advice commonly found on various forum about the placement of the > javadoc plugin configuration pertain to and/or > section. In my case, this advice looks irrelevant (see below). > > After a lot of head scratching, placing the javadoc-plugin configuration > in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin > configuration have the desired effect. This is quite surprising as the > configuration of other plugins have an effect when placed in parent/pom.xml. > > To reproduce this behavior, you can check out the code of the SLF4J > project from [2] and run "mvn javadoc:aggregate". (To observe a failure > the javadoc-plugin configuration needs to commented out in top-level > pom.xml and uncommented in parent/pom.xml before running "mvn > javadoc:aggregate".) > > I am wondering whether the behavior of javadoc:aggregate described above > is expected or actually a problem? > > Best regards, > > [1] https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern > [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Unexpected behavior of the javadoc plugin?
Hello, I would like to share what looks to me like an unexpected behavior of the javadoc plugin, more specifically when run as javadoc:aggregate. The SLF4J project uses the "Refining the BOM Pattern" variant as explained in Garret Wilson's "Improving the BOM Pattern" [1]. More specifically, the top level pom.xml is the BOM and project modules import ../parent/pom.xml. Source code is available at [2]. Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized project. When trying to create aggregated javadocs with the javadoc:aggreate command, the javadoc generation would fail with javadoc complaining about unnamed modules and other miscellaneous problems. The solution was to skip certain modules for which there was no need to generate javadocs to begin with. Surprisingly, adding in parent/pom.xml of the javdoc-plugin configuration would have no effect. However, specifying -Dmaven.javadoc.skippedModules would work as expected. The advice commonly found on various forum about the placement of the javadoc plugin configuration pertain to and/or section. In my case, this advice looks irrelevant (see below). After a lot of head scratching, placing the javadoc-plugin configuration in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin configuration have the desired effect. This is quite surprising as the configuration of other plugins have an effect when placed in parent/pom.xml. To reproduce this behavior, you can check out the code of the SLF4J project from [2] and run "mvn javadoc:aggregate". (To observe a failure the javadoc-plugin configuration needs to commented out in top-level pom.xml and uncommented in parent/pom.xml before running "mvn javadoc:aggregate".) I am wondering whether the behavior of javadoc:aggregate described above is expected or actually a problem? Best regards, [1] https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Loading groovy as a Jigsaw auto-module
Hi Robert, I found running the command mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve \ -DexcludeTransitive to be highly informative. Thank you. Apparently, there were issues in the way I edited MANIFEST.MF file in groovy-2.4.13.jar. I won't bore you with the details. Anyhow, I reverted to the original jar file, ran m-dependency-p and got: Can't extract module name from groovy-2.4.13.jar: Provider class groovy not in module After some investigation, it appeared that this is due to the contents of the file META-INF/services/org.codehaus.groovy.source.Extensions Removing this file solves the problem at least as far as Jigsaw module resolution is concerned. Running m-dependency-p, I see: o.c.groovy:groovy:jar:2.4.13:compile (optional) -- module groovy (auto) Again, thank you very much for your help, -- Ceki On 03.12.2017 14:06, Robert Scholte wrote: On Sun, 03 Dec 2017 13:40:51 +0100, Ceki Gulcu wrote: Hello all, The logback project, more specifically logback-classic, offers the possibility of configuration via a script written in Groovy. Thus, logback-classic has source files written in Java and a few source files in Groovy. While attempting to (Jigsaw) modularize the logback project, I first tried to declare "requires static groovy" in logback-classic's module-info.java file but the compiler was unable to load groovy-2.4.13.jar as an auto-module. To get the ball rolling, I had to resort to the "--add-reads ch.qos.logback.classic=ALL-UNNAMED" compiler directive. This is very unsatisfactory. On twitter, Cédric Champeau suggested manually editing MANIFEST.MF in groovy-2.4.13.jar adding "Automatic-Module-Name: groovylang". I edited the file and also declared "requires static groovylang" in logback-classic's module-info.java. However, this did not help and I still get "module not found: groovylang" Building with maven's -X option, I see that groovy-2.4.13.jar ends up on the compiler's class path instead of the module path. Still on twitter, Robert Scolte responded that m-compiler-p only puts the jars on the module path if they are referred to by a requires statement anywhere in the module descriptors tree. The rest ends up on the classpath. I am assuming here that "module descriptors tree" refers to module-info.java files and not dependency declarations in pom.xml files. Thus, if I understand correctly m-compiler-p parses module-info.java files before invoking javac. Really? Yes, really. In fact it goes beyond that. It also parses module-info.class, reads the MANIFEST.MF for Automatic-Module-Name and uses some specific Java9 code to extract the automatic module name from the jarfile. The code for this can be found at https://github.com/codehaus-plexus/plexus-languages/tree/master/plexus-java If you want to know the module names per jar, please run (with JAVA_HOME pointing to /path/to/java9): mvn compile org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve -DexcludeTransitive thanks, Robert Best regards, -- Ceki Gülcü - 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
Loading groovy as a Jigsaw auto-module
Hello all, The logback project, more specifically logback-classic, offers the possibility of configuration via a script written in Groovy. Thus, logback-classic has source files written in Java and a few source files in Groovy. While attempting to (Jigsaw) modularize the logback project, I first tried to declare "requires static groovy" in logback-classic's module-info.java file but the compiler was unable to load groovy-2.4.13.jar as an auto-module. To get the ball rolling, I had to resort to the "--add-reads ch.qos.logback.classic=ALL-UNNAMED" compiler directive. This is very unsatisfactory. On twitter, Cédric Champeau suggested manually editing MANIFEST.MF in groovy-2.4.13.jar adding "Automatic-Module-Name: groovylang". I edited the file and also declared "requires static groovylang" in logback-classic's module-info.java. However, this did not help and I still get "module not found: groovylang" Building with maven's -X option, I see that groovy-2.4.13.jar ends up on the compiler's class path instead of the module path. Still on twitter, Robert Scolte responded that m-compiler-p only puts the jars on the module path if they are referred to by a requires statement anywhere in the module descriptors tree. The rest ends up on the classpath. I am assuming here that "module descriptors tree" refers to module-info.java files and not dependency declarations in pom.xml files. Thus, if I understand correctly m-compiler-p parses module-info.java files before invoking javac. Really? Best regards, -- Ceki Gülcü - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: bug? strange resolution of commons-logging dependency
Using Maven 2.2.0, the behavior remains the same as with Maven 2.0.9. Moreover, if you remove the dependency on net.sf.ehcache:ehcache:1.6.0 from the pom file for "htmlunitbug", then the test passes (with the original pom files for hibernate-ehcache hibernate-parent referencing commons-logging version 99). In summary, there is strong evidence that common-logging 99 is not the culprit here. Can it be that the various dependencies, some in test scope and some in runtime scope, are confusing Maven's dependency resolution mechanism? Ceki Gulcu wrote: Lucas Bergman wrote: Dennis Lundberg wrote: That is your problem. What this does is mess the dependency-tree. It removes commons-logging from the dependency tree because that version "99.0-..." is larger than the latest current release of commons-logging. The "99.0-..." version should *never ever* reach end users. It can *only* be used by internal project. Thanks for the input. Are you saying that the dependency of the hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug? I'm sympathetic to that view, but I just want to be sure. To be sure, it seems foolish for the Hibernate developers to put something like this in a library's POM, since it would seem to impose their kludge on the programmer using the library. Of course, we fixed our particular problem by adding an for commons-logging from our hibernate-ehcache dependency. Hello, I was able to reproduce the dependency resolution issue with the help of a small test project called "htmlunitbug" as supplied by Lucas Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500". However, I appears that commons-logging version 99 is not the culprit as it is *not* involved in the resolution of commons-logging within "htmlunitbug", the test application supplied by Lucas. At least, the output of "mvn -X test" never mentions version 99. As further proof, I have removed any references to version 99 in the pom files for hibernate-ehcache and hibernate-parent, with the same results. Just as importantly, the pom files for hibernate-ehcache and hibernate-parent reference commons-logging version 99 in *scope* *test*. Given that the test scope is not transitive, and given that even after removing references to version 99, "htmlunitbug" still fails, it would be premature to incriminate version 99. Something else is afoot here. [1] http://tinyurl.com/nfw332 -- Lucas -- 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: bug? strange resolution of commons-logging dependency
I forgot to mention that my tests were conducted using Maven 2.0.9. I will redo the tests with Maven 2.2.0. Ceki Gulcu wrote: Lucas Bergman wrote: Dennis Lundberg wrote: That is your problem. What this does is mess the dependency-tree. It removes commons-logging from the dependency tree because that version "99.0-..." is larger than the latest current release of commons-logging. The "99.0-..." version should *never ever* reach end users. It can *only* be used by internal project. Thanks for the input. Are you saying that the dependency of the hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug? I'm sympathetic to that view, but I just want to be sure. To be sure, it seems foolish for the Hibernate developers to put something like this in a library's POM, since it would seem to impose their kludge on the programmer using the library. Of course, we fixed our particular problem by adding an for commons-logging from our hibernate-ehcache dependency. Hello, I was able to reproduce the dependency resolution issue with the help of a small test project called "htmlunitbug" as supplied by Lucas Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500". However, I appears that commons-logging version 99 is not the culprit as it is *not* involved in the resolution of commons-logging within "htmlunitbug", the test application supplied by Lucas. At least, the output of "mvn -X test" never mentions version 99. As further proof, I have removed any references to version 99 in the pom files for hibernate-ehcache and hibernate-parent, with the same results. Just as importantly, the pom files for hibernate-ehcache and hibernate-parent reference commons-logging version 99 in *scope* *test*. Given that the test scope is not transitive, and given that even after removing references to version 99, "htmlunitbug" still fails, it would be premature to incriminate version 99. Something else is afoot here. [1] http://tinyurl.com/nfw332 -- Lucas -- 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: bug? strange resolution of commons-logging dependency
Lucas Bergman wrote: Dennis Lundberg wrote: That is your problem. What this does is mess the dependency-tree. It removes commons-logging from the dependency tree because that version "99.0-..." is larger than the latest current release of commons-logging. The "99.0-..." version should *never ever* reach end users. It can *only* be used by internal project. Thanks for the input. Are you saying that the dependency of the hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug? I'm sympathetic to that view, but I just want to be sure. To be sure, it seems foolish for the Hibernate developers to put something like this in a library's POM, since it would seem to impose their kludge on the programmer using the library. Of course, we fixed our particular problem by adding an for commons-logging from our hibernate-ehcache dependency. Hello, I was able to reproduce the dependency resolution issue with the help of a small test project called "htmlunitbug" as supplied by Lucas Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500". However, I appears that commons-logging version 99 is not the culprit as it is *not* involved in the resolution of commons-logging within "htmlunitbug", the test application supplied by Lucas. At least, the output of "mvn -X test" never mentions version 99. As further proof, I have removed any references to version 99 in the pom files for hibernate-ehcache and hibernate-parent, with the same results. Just as importantly, the pom files for hibernate-ehcache and hibernate-parent reference commons-logging version 99 in *scope* *test*. Given that the test scope is not transitive, and given that even after removing references to version 99, "htmlunitbug" still fails, it would be premature to incriminate version 99. Something else is afoot here. [1] http://tinyurl.com/nfw332 -- Lucas -- 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: bug? strange resolution of commons-logging dependency
Jörg Schaible wrote: You've been right, I should have read your question closer. See Dennis' answer. Actually there was an attempt to release an official empty commons-logging at Apache recently and it was tunred down exactly because we could foresee this problem you're facing now :-/ Note that we wanted to release version 0.0-EMPTY, not version 99. One could argue that releasing 0.0-EMPTY could have prevented this issue from occurring. - Jörg -- 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
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
> 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
