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: Working around "Can't compile test sources when main sources are missing a module descriptor"
Hi Mark, I ran into a similar problem today, July 12th. In the logback project in order to test support for jigsaw/jpms in maven-module 'x', we create a maven-module called x-blackbox. The x-blackbox module contains junit5 tests under src/test/java and without a src/main folder. This works nicely. I have tried to do the same for the jul-to-slf4j module in slf4j. Thus, I have created jul-to-slf4j-bloackbox module following the same recipe as in the logback project. To my astonishment this resulted in the following error: Execution default-testCompile of goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile failed: Can't compile test sources when main sources are missing a module descriptor I have tried fixing the problem by tweaking plugin and jdk versions to no avail. However, as far as I can tell, the only significant difference between slf4j and logback is that slf4j uses junit4 and logback uses junit5. Moving jul-to-slf4j-bloackbox module into a distinct project and using junit 5 fixed the issue. It seems to me that moving to Junit 5 is the critical element. WARNING: The assertion above is speculative as I have not tried to debunk said assertion. Best regards, ps. I did not have time to read https://github.com/junit-team/junit5/discussions/3370 -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 6/29/2023 7:02 PM, Mark Raynsford wrote: > (Re-sent using correct address!) > > Hello! > > I recently started a discussion thread on the JUnit 5 repos detailing a > problem I'd been running into on a lot of projects: > > https://github.com/junit-team/junit5/discussions/3370 > > Long story short: In my projects, for various reasons, I put all of the > tests in one module rather than having a src/test/java in each. This > works fine, except for the fact that I have to maintain duplicate module > descriptors in the src/main/java and src/main/test directories of the > *.tests module, and I also have to maintain a shadow package hierarchy > in src/main/java filled with empty classes (one for each exported > package). > > I'm about to start experimenting with putting test sources in > src/main/java in the *.tests module, but I'm slightly nervous about > doing this. It's quite an obvious divergence from Maven's conventions > (although arguably putting all tests in a *.tests module might be > considered one too [although the conventions were chosen before > Java platform modules existed!]). I'm not clear on how all of the tools > might misbehave if tests aren't in the source directory they're expected > to be in. > > I realized I'm really only doing this because the Maven Compiler plugin > produces the error above if I don't have module descriptors in both > directories: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile > (default-testCompile) on project com.io7m.idstore.tests: Execution > default-testCompile of goal > org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile > failed: Can't compile test sources when main sources are missing a > module descriptor -> [Help 1] > > Is there perhaps a better way to get the Compiler plugin to ignore > src/main/java and just compile the tests? > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BOM files referencing optional dependencies
On 6/17/2023 9:32 PM, Ceki Gülcü wrote: > > Hello, > > Is it considered good practice to reference optional dependencies in BOM > files? My question is probably silly as BOM files are reserved for declaring artifacts a project builds itself and not for dependencies, optional or otherwise. -- 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
BOM files referencing optional dependencies
Hello, Is it considered good practice to reference optional dependencies in BOM files? -- 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: Modular path vs. class path determination
Hello Martin, Olivier, Since I posted on this thread, I have abandoned the idea of integration testing in the same Maven module. Instead, for module X, white-box testing is still done within X/src/test/ and integration testing done in a new and separate module X-blackbox which is also Jigsaw/JPMS modular. This approach is a lot less painful than in-single-module testing. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 10/17/2022 1:27 PM, Martin Desruisseaux wrote: > Le 17/10/2022 à 12:33, Olivier Lamy a écrit : > >> I wanted to have some opinions on what sort of configurations we could >> add but this didn't get much attention :) >> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody >> really cares of jpms... >> > On my side I do care a lot about JPMS. But I got the feeling that Maven > model is not well suited to JPMS, which caused me to stop following JPMS > issues on Maven and look for other build solution. > > The difficulty I have with JPMS in Maven is that I would like to break > the "one Maven module = one JPMS module" relationship. Instead I would > like "one Maven module = one compilation unit", i.e. a single call to > javac, javadoc or other java tools, which may itself comprise many JPMS > module. > > Martin > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Modular path vs. class path determination
Hello all, The logback is attempting to migrate to Junit 5. As a consequence of this migration, a handful of tests that were previously successful, now fail. For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest recently failed with the following error: java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException During surefire execution, the j.m.i.AddressException class is not found. It is part of jakarta-mail.jar. I believe this artifact is on the module path but somehow is not resolved. Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to help. Don't ask me why... I am also puzzled by the fact that many JMPS modularized artifacts are placed on the class path instead of the module path when the tests are run. Anyway, I think I may have stumbled upon a bug in Maven or the surefire plugin. Indeed, when I run mvn install from within the logback-classic module, the DilutedSMTPAppenderTest mentioned above succeeds. However, when I run it as mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest the test fails with the following exception [ERROR] ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy Time elapsed: 0.001 s <<< ERROR! java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException at ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) [cut]... Caused by: java.lang.ClassNotFoundException: jakarta.mail.internet.AddressException at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ... 74 more Comparing the command line of the two executions, the 'mvn install' execution has jakarta-mail-api on the module-path, whereas the 'mvn test -D=..." has jakarta-mail-api on the class-path. If you wish to confirm this, I have created tag 'possible_mvn_issue' in the logback repository on github . https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue Let me know if this merits the creation of a Jira issue. Your feedback would be most appreciated. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch--module-path "C:\\home\\buzz\\logback\\logback-classic\\target\\classes; C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\logback\\logback-core\\1.4.2-SNAPSHOT\\logback-core-1.4.2-SNAPSHOT.jar; C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\slf4j-api\\2.0.1\\slf4j-api-2.0.1.jar; C:\\Users\\buzz\\.m2\\repository\\jakarta\\mail\\jakarta.mail-api\\2.1.0\\jakarta.mail-api-2.1.0.jar; C:\\Users\\buzz\\.m2\\repository\\jakarta\\activation\\jakarta.activation-api\\2.1.0\\jakarta.activation-api-2.1.0.jar; C:\\Users\\buzz\\.m2\\repository\\org\\eclipse\\angus\\angus-mail\\1.0.0\\angus-mail-1.0.0.jar; C:\\Users\\buzz\\.m2\\repository\\org\\eclipse\\angus\\angus-activation\\1.0.0\\angus-activation-1.0.0.jar; C:\\Users\\buzz\\.m2\\repository\\org\\codehaus\\janino\\janino\\3.1.9-SNAPSHOT\\janino-3.1.9-SNAPSHOT.jar; C:\\Users\\buzz\\.m2\\repository\\org\\codehaus\\janino\\commons-compiler\\3.1.9-SNAPSHOT\\commons-compiler-3.1.9-SNAPSHOT.jar; C:\\Users\\buzz\\.m2\\repository\\jakarta\\servlet\\jakarta.servlet-api\\5.0.0\\jakarta.servlet-api-5.0.0.jar" --class-path "C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-booter\\3.0.0-M7\\surefire-booter-3.0.0-M7.jar; C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-api\\3.0.0-M7\\surefire-api-3.0.0-M7.jar; C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-logger-api\\3.0.0-M7\\surefire-logger-api-3.0.0-M7.jar; C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-shared-utils\\3.0.0-M7\\surefire-shared-utils-3.0.0-M7.jar; C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-extensions-spi\\3.0.0-M7\\surefire-extensions-spi-3.0.0-M7.jar; C:\\home\\buzz\\logback\\logback-classic\\target\\test-classes; C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\slf4j-api\\2.0.1\\slf4j-api-2.0.1-tests.jar; C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\log4j-over-slf4j\\2.0.1\\log4j-over-slf4j-2.0.1.jar; C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\jul-to-slf4j\\2.0.1\\jul-to-slf4j-2.0.1.jar; C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\reload4j\\reload4j\\1.2.18.4\\reload4j-1.2.18.4.jar; C:\\Users\\buzz\\.m2\\repository\\org\\dom4j\\dom4j\\2.0.3\\dom4j-2.0.3.jar; C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\logback\\logback-core\\1.4.2-SNAPSHOT\\logback-core-1.4.2-SNAPSHOT-tests.jar; C:\\Users\\buzz\\.m2\\repository\\com\\icegreen\\greenm
Re: Race condition in slf4j-simple
Hi Tibor, Your analysis makes sense. As SimpleLogger acts as an appender as found in log4j/logback backends, SimpleLogger should cater for concurrent access with some sort of synchronization. It currently does not. Please create a jira issue for this problem. Best regards, -- Ceki Gülcü On 08.07.2021 15:23, Tibor Digaňa wrote: Hi Ceki, We have observed a strange behavior of the logger slf4j-simple when two or more parallel Maven modules log the exceptions and the messages. It produces corrupted lines in the log and they are partially mixed with other lines. The lines look like this and they are obviously not expected in the log. [ERROR] R] *.util.json.formatter.JsonFormatterTest [ERROR] Process Exit Code: 0 [ERROR] *.util.json.formatter.JsonFormatterTest After our analysis we found the place in SLF4J code which seems to be the root cause. The method [1] is a critical section and must be synchronized with a singleton lock which avoids reordering of the nested method calls across multiple Threads. Without it, the normal messages and stack trace may mix especially if two parallel Maven modules print the stacktrace. [1]: https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243 <https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243> Pls analyse the class SimpleLogger.java and answer with your opinion about this issue and a proposal with the fix. If there are more other critical sections which need to have some concurrency treatments, we can talk about it in this mailing list. -- Cheers Tibor - 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 <c...@qos.ch> 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
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 exclusion 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 exclusion 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
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 exclusion 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
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
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: Dependency scopes
On 8/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The difference between the runtime and test scopes is also not very clear to me. Nick Veys [EMAIL PROTECTED] wrote on 17.08.2006 06:16:40: This was already answered, but the test dependencies aren't needed for normal runtime, so they are left out. It allows you to pull in a test harness, or mock libraries during your tests but leave that out for real execution or packaging. While I understand that certain libs may be required at compile time but not compile time, I don't see what normal runtime means in terms of Maven. Maven is a build system, it does not execute your applications, so how can it have a runtime classpath? There is no such thing as runtime Maven or is there? DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
Re: Re: Dependency scopes
So, this means that war and ear plug-ins reference the runtime classpath instead of say compile or test. Correct? Martijn Dashorst [EMAIL PROTECTED] wrote on 30.08.2006 15:37:56: No, but maven is also used to create war, ear and other distribution packages. These packages need those actual runtime dependencies inside them. So for testing I need junit, but not at runtime - test scope For testing I may not have a need for oracle-jdbc (using hsqldb for unittests), but at runtime I will (if deploying on an oracle database) - runtime scope. For testing I need the interfaces for the servlet api, but those interfaces are available at runtiime in the tomcat server for my web application. So the servlet api JAR (javax.servlet-2.3.jar) is needed for compile *and* test, but doesn't need to go into the WAR archive - provided scope. hth. Martijn DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
Re: Re: Re: Dependency scopes
Thanks! Martijn Dashorst [EMAIL PROTECTED] 30.08.2006 16:17 Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Re: Re: Dependency scopes Reviewed by Category Yes, but runtime classpath != runtime scope runtime classpath == union(compile, runtime scope) Martijn On 8/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So, this means that war and ear plug-ins reference the runtime classpath instead of say compile or test. Correct? Martijn Dashorst [EMAIL PROTECTED] wrote on 30.08.2006 15:37:56: No, but maven is also used to create war, ear and other distribution packages. These packages need those actual runtime dependencies inside them. So for testing I need junit, but not at runtime - test scope For testing I may not have a need for oracle-jdbc (using hsqldb for unittests), but at runtime I will (if deploying on an oracle database) - runtime scope. For testing I need the interfaces for the servlet api, but those interfaces are available at runtiime in the tomcat server for my web application. So the servlet api JAR (javax.servlet-2.3.jar) is needed for compile *and* test, but doesn't need to go into the WAR archive - provided scope. hth. Martijn DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. * -- Download Wicket 1.2.2 now! New Ajax components: Tree, TreeTable and ModalWindow -- http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
Re: Dependency scopes
Nick, I very much appreciate your response. I wish the article of reference on subject, namely, Introduction to the Dependency Mechanism was somewhat more precise. Perhaps the maintainers of the document could have another look at it. Is filing a bug report appropriate? Nick Veys [EMAIL PROTECTED] wrote on 17.08.2006 06:16:40: On 8/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The said article mentions the notion of runtime classpath. While I can see what compile and test classpaths mean, I fail to understand what a runtime classpath is, in particular how it differs from the test classpath. Think of Runtime as somewhat of an optimization for the build process. The jar itself is not needed to compile the code as it has no direct dependency on it, though the code itself still needs this jar to execute, as such it will travel along transitively in case it is needed down the line, and will also be included in the test scope as it may be called upon since the code has a runtime dependency on it. Moreover, the article defines provided scope as follows: provided - this is much like compile, but indicates you expect theJDK or a container to provide it. It is only available on the compilation classpath, and is not transitive. However, in a small project I've created to test dependency scopes, it seems that a dependency declared with the provided scope is available when compiling the source, compiling the test cases as well as when running them (the test cases). Thus, it looks like the provided scope is the same as the compile scope, except that the provided scope is not transitive. The documentation may be slightly wrong, as you experienced the provided scope jars are available to tests (at least in my experience), though I believe only that local project tests, as you have no transitivity (I may be wrong here, corrections?). Provided is very much like compile w/o transitivity. It is assumed that your container or system will provide this jar when needed. The difference between the runtime and test scopes is also not very clear to me. This was already answered, but the test dependencies aren't needed for normal runtime, so they are left out. It allows you to pull in a test harness, or mock libraries during your tests but leave that out for real execution or packaging. The small table which illustrates the effects of scopes on transitivity is not easy to grok. In particular, the explanation (quoted below) preceding the table does not define the direction of any of the dependencies. I'm guessing it's trying to tell you the precidence of dependencies when the same dependency is referenced in multiple scopes in one project, but you're right, the preceeding paragraph is not exactly clear in what it is talking about. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
Re: Dependency scopes
Mike, thank you for taking the time to respond. My question had several parts and your response relates to the difference between runtime scope and the test scope. I wonder if someone would care to respond to the remaining parts. Mike Perham [EMAIL PROTECTED] wrote on 15.08.2006 18:04:17: Runtime - contains things that you don't need at compile but you do need for your app to actually run. You might compile against JMS but require ActiveMQ at runtime (i.e. a JMS engine). Test - contains test specific classes. Junit, mocks, a lightweight database like HSQLDB, etc. [EMAIL PROTECTED] wrote on 08/15/2006 08:32:26 AM: Hello, I would like to ask a question regarding dependency scopes in Maven2. After reading the article Introduction to the Dependency Mechanism [1], I've got several questions that may have been answered previously. I apologize in advance if that is the case. The said article mentions the notion of runtime classpath. While I can see what compile and test classpaths mean, I fail to understand what a runtime classpath is, in particular how it differs from the test classpath. Moreover, the article defines provided scope as follows: provided - this is much like compile, but indicates you expect theJDK or a container to provide it. It is only available on the compilation classpath, and is not transitive. However, in a small project I've created to test dependency scopes, it seems that a dependency declared with the provided scope is available when compiling the source, compiling the test cases as well as when running them (the test cases). Thus, it looks like the provided scope is the same as the compile scope, except that the provided scope is not transitive. The difference between the runtime and test scopes is also not very clear to me. The small table which illustrates the effects of scopes on transitivity is not easy to grok. In particular, the explanation (quoted below) preceding the table does not define the direction of any of the dependencies. quote Each of the scopes affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, dependencies with the scope across the top row will result in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency will be omitted. /quote Your enlightenment would be greatly appreciated, [1] http://maven.apache.org/guides/introduction/introduction-to- dependency-mechanism.html DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dependency scopes
Hello, I would like to ask a question regarding dependency scopes in Maven2. After reading the article Introduction to the Dependency Mechanism [1], I've got several questions that may have been answered previously. I apologize in advance if that is the case. The said article mentions the notion of runtime classpath. While I can see what compile and test classpaths mean, I fail to understand what a runtime classpath is, in particular how it differs from the test classpath. Moreover, the article defines provided scope as follows: provided - this is much like compile, but indicates you expect theJDK or a container to provide it. It is only available on the compilation classpath, and is not transitive. However, in a small project I've created to test dependency scopes, it seems that a dependency declared with the provided scope is available when compiling the source, compiling the test cases as well as when running them (the test cases). Thus, it looks like the provided scope is the same as the compile scope, except that the provided scope is not transitive. The difference between the runtime and test scopes is also not very clear to me. The small table which illustrates the effects of scopes on transitivity is not easy to grok. In particular, the explanation (quoted below) preceding the table does not define the direction of any of the dependencies. quote Each of the scopes affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, dependencies with the scope across the top row will result in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency will be omitted. /quote Your enlightenment would be greatly appreciated, [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to be compatible with both M1 and M2 repos
Hello, An slf4j user recently observed that he could not get maven2 to include slf4j as a dependency. He traced the cause to the incompatibility between maven1 and maven2 pom files. I suspect the problem is due to the fact that we export pom.xml files using the maven1 format. Is there a way to upload dependencies on ibiblio so that they are compatible with both maven1 and maven2? Thank you for your input, -- Ceki Gülcü http://ceki.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] jetty6 plugin log4j
David,
I am not very familiar with maven-jetty6-plugin. However, from what
you describe, it looks like jetty is using SLF4J's SimpleLogger
binding instead of its log4j binding. This is attested by the
following line:
2 [main] INFO org.mortbay.log - Logging to
[EMAIL PROTECTED] via org.mortbay.log.Slf4jLog
When Jetty uses SLF4J's SimpleLogger binding log4j configuration files
have no affect as log4j is not used by Jetty. You need to instruct
Maven or Jetty to use the correct binding. For more details on SLF4J
bindings please see http://www.slf4j.org.
Hello all -
Could anyone help me to understand how to change the log level that
the maven-jetty6-plugin uses? I would like to put debug logging
statements into my code, but then I can't seem to figure out how to
get the plugin to change from its default info level. I would also
like to set different logging levels on package name.
Note also that I am using the Spring framework. So first I tried
using its Log4jConfigListener web util class in web.xml and pointing
it at my log4j.properties file. Info messages appeared indicating
that it was alive and had read my configuration:
929 [main] INFO /myapp - Initializing Log4J from [/Users/davidm/
dev/myapp/src/main/resources/webapp/WEB-INF/log4j.properties]
But no changes were evident in the logged message, neither in format
nor level.
Then I found a posting on Gmane that indicated you can give Jetty
your own log4j.properties file by configuring a systemProperty named
log4j.configuration, which I did in pom.xml. Again, messages
indicated that Jetty recognized my property setting:
[INFO] Property log4j.configuration=/WEB-INF/log4j.properties was
set
but nothing seemed to change the way it logs. In fact, two lines
later in the log, there is this message:
2 [main] INFO org.mortbay.log - Logging to
[EMAIL PROTECTED] via org.mortbay.log.Slf4jLog
Here's my (very simple) log4j.properties file:
log4j.rootLogger=WARN, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c
{1}:%L - %m%n
log4j.logger.net.sf.hibernate=WARN
log4j.logger.net.sf.hibernate.type=WARN
log4j.logger.org.springframework=WARN
I read Jetty's tutorial on logging, but it :
http://www.mortbay.org/jetty/tut/logging.html
Finally, I gave the -DDEBUG and -DDEBUG_PATTERNS=net.sf.hibernate
a shot, but these too seemed to be ignored.
I get the feeling that I am clashing somehow with Jetty's own
logging. Can anyone help me unravel this?
Thanks
--David
--
Ceki Gülcü
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quickly changing the Maven template
Thank you very much, Dion. At 08:34 PM 9/21/2003 +1000, [EMAIL PROTECTED] wrote: It's in the documentation. See http://maven.apache.org/reference/plugins/xdoc/faq.html#navigation-images -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Ceki Gülcü [EMAIL PROTECTED] wrote on 20/09/2003 05:37:06 AM: Hello all, How difficult is it to change the Maven template so that the generated project pages contain an extra image? For an example of what is meant please refer to: http://jakarta.apache.org The image for ApacheCon 2003 was added by modifying a template file for Anakia. Is there a similar procedure for doing the same with Maven? Your answers will be collated and forwarded to the various ASF projects using Maven. TIA, -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - 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] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quickly changing the Maven template
At 10:40 PM 9/19/2003 -0400, Jason van Zyl wrote: On Fri, 2003-09-19 at 15:37, Ceki Gülcü wrote: Hello all, How difficult is it to change the Maven template so that the generated project pages contain an extra image? For an example of what is meant please refer to: http://jakarta.apache.org Are you asking if we will change the template so that all projects using Maven advertise ApacheCon? I am assuming not. No, that is not it. If you mean for the maven.apache.org site that would be easy enough. For example, the for the OJB project which uses Maven, Thomas wanted to modify the template so all OJB pages would be affected. However, he did not know how to do it. I am just asking whether there is a way to do modify the template and if so, could it be described for the benefit of all projects. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
