Re: [VOTE] Require Java 17 for Maven 4
+1 (non binding) The preceding discussion was quite insightful and informative. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 2/28/2024 8:30 AM, Benjamin Marwell wrote: > Hi Maven Devs/Users/Committers and PMC members! > > After several discussions on the mailing lists, I would like to > start a vote in favour of setting the minimal Java bytecode target > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. > > This is a procedural majority vote [1*]: > You can also vote with fractions and negative votes are not vetoes. > > Please also notice: > * Maven 3 will stay at Java 8 no matter what. > * We may raise Maven 4 to JDK 21 later if we feel like it (depending > on the release date). > This is not part of this vote. > * The linked PR is not part of this vote (this is not a code vote). > But you may take a look at it to understand the intended change. > > PR: https://github.com/apache/maven/pull/1430 > > Maven-Parent will not be raised with this vote, the other PR is not > part of this vote. > > Please refrain from starting discussions in this thread, but do > include a reasoning on downvotes and feel free to start a new > discussion on the mailing list, or comment on the existing ones. > > --- > > Vote open for 72 hours: > > [ ] +1 (set JDK17 min version for Maven 4.x) > [ ] +0 > [ ] -1 (please include reasoning) > > --- > > - Ben > > [1*]: https://www.apache.org/foundation/voting.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On 2/25/2024, 2:49 PM Elliotte Rusty Harold wrote: >> For #2, reproducible builds mean we have to be able to support what >> customers are using and that can be anything from Java 8 - 21. It is >> not sufficient to say Java 21 can compile to Java 8 since that does >> not produce the same byte code as compiling with Java 8. On 2/26/2024 8:22 PM, Benjamin Marwell wrote: > That is the point. > If you built the project with JDK 21 using the -release=8, you can get > the same (reproducible) output with a similar OS and JDK 21. I wrote about 6 or 7 paragraphs of word salad to essentially convey the same message as Benjamin. If the goal is verification of the artifact with respect to the code in the software repo, the verifier needs the same JDK version as the version used to produce the artifact being checked in order to compare binaries. The Java version can be any Java version and only depends on the producer of the artifact (the owner of the artifact). Obviously, this Java version needs to be equal or higher than the "release" version, but that is it. Claiming that if the release version is 8, the Java version must also be 8 seems quite incorrect. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
Hello Bernd, I was unaware of the capabilities of the release flag. Thank you for explaining. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 2/25/2024 1:37 AM, Bernd Eckenfels wrote: > It has been mentioned before, but just to add, since the bytecode > level is IMHO the smallest problem: > > Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00): >> you can use JDK 17 to produce Java 8 bytecode using Java 8 >> features, that is the distinction I made between runtime and build time, >> but it looks it's still not clear. > > In the past a newer JDK version could compile for an older Bytecode version > and > compatible with the source code constructs, BUT it used its own classlibrary > which > had usually different method and therefore create NON-compat results. For that > reason you had to provide the old bootpath if you wanted a clean build (or, > since this > Is nearly the same work than just using the old JDK always use the same > build/target > Version, this was very typical for java7 builds and many think it is needed > for 8 as well). > > But, this is no longer a problem since Java9, the new -release option does > not only simplify > -source and -target into a single option it additionally makes the Java > compiler use an > internal list of approved JCL signatures, therefore being save for cross > compile (only > If you switch to the new flag). > > Unfortunatelly -release 8 has still problems with removed libraries, so it is > a bit of a > work to use newer JDKs to compile old codebase (not a drop-in in some cases > like jaxb). > > Btw Java8 POMs are a bit annoying since you can’t build them on Java 8 > With maven.compiler.release and you can’t (should not) build them on 9+ with > maven.compiler.target. Luckily you can solve that with a profile activated by > runtime version. > https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html > > Gruß > Bernd > — > https://bernd.eckenfels.net > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MR-Jar support in Maven
Hi Robert, I would have thought that it was not Maven's responsibility to ascertain that test passed in various JDKs, old and new. Nevertheless, there is no doubt that once you pay attention to the details, things can get messy awfully quick. BTW, thank you for your previous response. -- Ceki On 3/24/2017 11:45, Robert Scholte wrote: Hi Ceki, the compilation-part isn't the real issue (it is acutally the easy part), but e.g. the testing-part is. You must ensure that surefire is also executed at least twice: once for pre-java9 and for java9. And what to do with other plugins which are part of the lifecycle up until the package-phase? Very likely they need to be executed twice as well. If you look closer you'll see that you're actually executing 2 build lifecycles which are in the end packaged to a single jar. The demo-project is the purest form but comes with overhead. Maven has a forking mechanism, but I don't think it is strong enough (yet) to fully support this. thanks, Robert On Fri, 24 Mar 2017 11:34:20 +0100, Ceki Gülcü <c...@qos.ch> wrote: Hi All, Currently in the process modularizing the SLF4J project in preperation for Java 9/Jigsaw, I ran into many wrinkles most of which are due to my own ignorance about Java 9 modules. Now that the initial phase of modularization is done, I am looking into creating mutlti-release jars (MR-Jars). Herve's mutli-version demo project [1] (thanks Hervé) while instructional, shows that MR-Jar support in Maven is perhaps lacking at the moment. As a developer, I really don't want to muck about with multiple maven project modules or learn the intricacies of the maven assembly plugin just to add module-info.java to my project's artifact. As a moderately-skilled Maven user, I would like to see MR-Jar supported by way of directory layout conventions, perhaps along the lines of: src/main/java/ -> target/classes src/test/java/ -> target/test/classes src/main/java-9/ -> target/classes/META-INF/versions/9 src/test/java-9/ -> target/test-classes/META-INF/versions/9 Thus, I would need to change little in my pom.xml files to support MR-jars. Most of the leg work would be done by the compiler plug-in and Maven conventions. Comments? -- Ceki [1] https://github.com/hboutemy/maven-jep238 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Thoughts on MR-Jar support in Maven
Hi All, Currently in the process modularizing the SLF4J project in preperation for Java 9/Jigsaw, I ran into many wrinkles most of which are due to my own ignorance about Java 9 modules. Now that the initial phase of modularization is done, I am looking into creating mutlti-release jars (MR-Jars). Herve's mutli-version demo project [1] (thanks Hervé) while instructional, shows that MR-Jar support in Maven is perhaps lacking at the moment. As a developer, I really don't want to muck about with multiple maven project modules or learn the intricacies of the maven assembly plugin just to add module-info.java to my project's artifact. As a moderately-skilled Maven user, I would like to see MR-Jar supported by way of directory layout conventions, perhaps along the lines of: src/main/java/ -> target/classes src/test/java/ -> target/test/classes src/main/java-9/ -> target/classes/META-INF/versions/9 src/test/java-9/ -> target/test-classes/META-INF/versions/9 Thus, I would need to change little in my pom.xml files to support MR-jars. Most of the leg work would be done by the compiler plug-in and Maven conventions. Comments? -- Ceki [1] https://github.com/hboutemy/maven-jep238 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
SimpleLogger prints to the latest value of System.out
Hello all, In issue SLF4J-389 [1] user Igor Polevoy observed that once initialized, SimpleLogger always used the same reference to System.out (or System.err). He feels that this can interfere in test where System.out is modified in order to capture log output. Commit 69be5f7f [2] ensures that SimpleLogger prints to the latest value of System.out. Please let me know if this may be an issue for you. Best regards, -- Ceki [1] http://jira.qos.ch/browse/SLF4J-389 [2] https://github.com/qos-ch/slf4j/commit/69be5f7f9875 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Log4j2/Logback integration updates
FYI, in the next version of logback, i.e. 2.0, we will be using JDK 1.6. However, the logback 1.1.x series will continue to be based on JDK 1.5. On 16.07.2013 07:06, Stephen Connolly wrote: So what I am hearing is that until we bump core to require JDK6 (or 7) then logback is the only runner from a technical point of view (never mind that log4j2 is still not GA) OTOH I would be interested in bumping JDK all the way to 7 if we were happy that toolchains is good enough and we had tests in play that use toolchains - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
Hello all, Out of curiosity, are there any other non-resolved issues holding up this release? Best regards, On 23.04.2013 12:24, Stephen Connolly wrote: +1 (binding) for 3.1.0-alpha-1 The following issue needs to be resolved before I will vote +1 on a non-alpha release: http://jira.codehaus.org/browse/MNG-5470 RAT is reporting the 391 files are either missing license headers or have not been flagged as files that cannot support a license header. Most of these are test data files and I would be happy to argue that the test may require a specific exact content for reproducibility, but the following I do not feel I can make a case for. I will require these 39 files to be addressed in some way before the final 3.1.0 release or I cannot provide a binding vote for the release. (the MANIFEST.MF may be one where a header does not make sense, but it is a non-generated file) I cannot speak for the rest of the PMC, but my understanding is that as a PMC member it is one of our duties to ensure that the source (which is what the vote is on) has met with the ASF requirements for license headers. *** Unapproved licenses: apache-maven/src/bin/m2.conf apache-maven/src/conf/logging/simplelogger.properties maven-aether-provider/src/main/java/org/apache/maven/repository/internal/package.html maven-aether-provider/src/site/apt/index.apt maven-artifact/src/site/apt/index.apt maven-compat/compatibility.cfl maven-compat/src/main/resources/META-INF/maven/plugin.xml maven-core/lifecycle-executor.txt maven-core/plugin-manager.txt maven-core/project-builder.txt maven-core/src/main/resources/org/apache/maven/messages/build.properties maven-core/src/site/apt/artifact-handlers.apt maven-core/src/site/apt/configuration-management.apt maven-core/src/site/apt/default-bindings.apt.vm maven-core/src/site/apt/getting-to-container-configured-mojos.apt maven-core/src/site/apt/index.apt maven-core/src/site/apt/inheritance.apt maven-core/src/site/apt/lifecycles.apt.vm maven-core/src/site/apt/offline-mode.apt maven-core/src/site/apt/plugin-execution-isolation.apt maven-core/src/site/apt/scripting-support/marmalade-support.apt maven-core/src/site/resources/design/2.1-lifecycle-refactor.graffle maven-embedder/src/examples/simple-project/src/main/java/org/apache/maven/embedder/App.java maven-embedder/src/examples/simple-project/src/test/java/org/apache/maven/embedder/AppTest.java maven-embedder/src/main/resources/META-INF/MANIFEST.MF maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties maven-embedder/src/site/apt/cli.apt.vm maven-embedder/src/site/apt/index.apt.vm maven-embedder/src/site/apt/logging.apt maven-model/src/main/java/org/apache/maven/model/io/xpp3/package.html maven-model/src/main/java/org/apache/maven/model/merge/package.html maven-model/src/main/java/org/apache/maven/model/package.html maven-model/src/site/apt/index.apt maven-model-builder/src/site/apt/index.apt maven-model-builder/src/site/apt/super-pom.apt.vm maven-plugin-api/src/site/apt/index.apt maven-plugin-api/src/test/resources/plugin.xml maven-repository-metadata/src/site/apt/index.apt maven-settings/src/site/apt/index.apt Attached is the full report (if it makes it through the mailing list filters) -Stephen On 1 April 2013 13:12, Jason van Zyl ja...@tesla.io mailto:ja...@tesla.io wrote: Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven pull request: Fix call to SimpleLoggerFactory.reset method
sorry about the unused INSTANCE field in SimpleLoggerFactory which is unnecessarily confusing. Just got rid of it: https://github.com/qos-ch/slf4j/commit/192f47034eda752 On 18.03.2013 19:59, mcculls wrote: GitHub user mcculls opened a pull request: https://github.com/apache/maven/pull/4 Fix call to SimpleLoggerFactory.reset method Use LoggerFactory to make sure we get the right instance to reset, as SimpleLoggerFactory.INSTANCE is not actually used by slf4j-simple's StaticLoggerBinder (instead it has its own SINGLETON field to hold the logger factory). Can now remove temporary reflection workaround. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcculls/maven slf4j-simple-reset Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/4.patch commit bae4b5a5613737c99ae99eca7d5ea7bbed99419a Author: Stuart McCulloch mccu...@gmail.com Date: 2013-03-18T18:57:04Z Fix call to SimpleLoggerFactory.reset method (use LoggerFactory to make sure we get the right instance to reset, as SimpleLoggerFactory.INSTANCE is not actually used by slf4j-simple's StaticLoggerBinder) and remove temporary reflection workaround -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logger and Embedded Maven Core ITs
On 17.03.2013 00:47, Jason van Zyl wrote:
If that's the case Ceki might be able to add the clearing of the logger map to
the reset method.
Ceki, would this be hard to change?
I just added a reset method to SimpleLoggerFactory. See
https://github.com/qos-ch/slf4j/commit/6dd3a60ee77a5cd17e for the
commit. Here is sample code for invoking this method in Maven tests:
import org.slf4j.ILoggerFactory;
import org.slf4j.LoggerFactory;
ILoggerFactory iLoggerFactory = LoggerFactory.getILoggerFactory();
if(iLoggerFactory instanceof SimpleLoggerFactory) {
((SimpleLoggerFactory) iLoggerFactory).reset();
}
As the reset() method is package protected, it needs to be invoked from
code in the org.slf4j.impl package. A friend class could expose the
reset method to classes in other packages.
Anyway, let me know how if this works for you.
On Mar 16, 2013, at 4:38 PM, Stuart McCulloch mccu...@gmail.com wrote:
On 16 Mar 2013, at 13:58, Jason van Zyl wrote:
Hervé,
Can you take a look at the logging changes you made to try and use the SLF4J
package private method for resetting the logger? The streams are being reset
correctly but the logging level doesn't appear to be reset which causes the
embedded ITs to fail.
Did some investigating and the issue seems to be that SLF4J Simple uses a
static singleton logger factory which contains a map of cached loggers.
Because embedded test mode uses the same classloader for all the tests (it only
forks once at the start) each test therefore sees the same logger factory and
any previously cached loggers.
This means that although the MavenCLI successfully resets SLF4J to refresh the
log level, the new setting doesn't affect previously cached loggers (they only
pick up the level in their constructor).
This can be shown with the following hack to clear the logger map (not sane
code, just proof-of-concept) which solves the embedded logging IT failures:
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
index 6a7f385..f1af143 100644
---
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
+++
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
@@ -58,5 +58,20 @@ public void activate()
// property for root logger level or System.out redirection need to be
taken into account
MavenSlf4jFriend.reset();
MavenSlf4jSimpleFriend.init();
+
+try
+{
+ org.slf4j.ILoggerFactory loggerFactory =
org.slf4j.LoggerFactory.getILoggerFactory();
+ synchronized ( loggerFactory )
+ {
+ java.lang.reflect.Field loggerMap =
loggerFactory.getClass().getDeclaredField( loggerMap );
+ loggerMap.setAccessible( true );
+ ( (java.util.Map) loggerMap.get( loggerFactory ) ).clear();
+ }
+}
+catch ( Exception e )
+{
+// ignore for now...
+}
}
}
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Ceki
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
On 11.12.2012 21:28, Mark Struberg wrote: Folks, don't you see it? we cannot use logback as this is a LocationAwareLogger and would break all projects which use slf4j 1.6 and older. Please go back to the original mail from 4 month where Ceki himself explained it! Hi Mark, You are assuming that a plugin somehow sees it's own version of slf4j-api on the class path but sees logback (the version that ships** with Maven) instead of it's preferred logging framework. Isn't that an overly pessimistic scenario which could not occur in practice? **subject to approval LieGrue, strub -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On 07.12.2012 07:25, Anders Hammar wrote: *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. Very nicely put. /Anders -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On 07.12.2012 02:34, Jason van Zyl wrote: One benefit is that it would hopefully fix the Sonar problem. But I'm not sure what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already loaded. Ceki might want to comment on how that works. If two SLF4J systems can run in the same JVM it may work. For the non-SLF4J case it's not using SLF4J, obviously, so there is no need to block it. SLF4J uses an extremely simple/primitive binding (aka plugin) mechanism. When the LoggerFactory class is loaded into memory by a given class loader, the first call to the getILoggerFactory() will perform initialization. The getILoggerFactory() method is called by the getLogger(String) method. Thus, if LoggerFactory class is loaded into memory N times but various class loaders, then LoggerFactory class will be initialized N times, under the very likely assumption that the getLogger() method is called at least once for each LoggerFactory instance. HTH, -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On 07.12.2012 18:32, Jason van Zyl wrote: Kristian, I'm going to look at problem with the logging while embedding and Hervé wants to look at the SLF4J isolation. From what I understand in talking to Ceki, for each classloader SLF4J can be initialized so it appears theoretically possible to block the all SLF4J from reaching a plugin and it will still be able to initialized its own SLF4J system though it will not be connected to the core's. So then it's a matter of deciding on sensible defaults and I agree with Anders here in that the default should be to pass on the core's SLF4J implementation. I think exceptional cases should use a flag for exceptional cases. This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. The above seems very reasonable. I hesitate to bring up another angle to this already heated debate. If it were up to me which it clearly is not, I'd go with exporting slf4j-api and the underlying logging framework to all plugins without hindrance. This would translate into the following worse-is-better [1] logging policy: As of 3.1.0. Maven exports its SLF4J logging environment to its plugins. Plugins are encouraged to use this SLF4J logging environment. They may attempt to configure this environment but should not blindly assume that the underlying logging framework is the default logging framework shipping with Maven. This policy would break the current Sonar plugin. Although I imagine a new version of Sonar would be released within weeks including the relevant fix. After a short adaptation period, I'd expect the rare plugins doing their own logging to fall in line with the worse-is-better logging policy outlined above. The alternative policy outlined by Jason while offering compatibility, would be murkier, at least to the uninitiated. [1] http://en.wikipedia.org/wiki/Worse_is_better Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On 07.12.2012 18:52, Anders Hammar wrote: This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. I'm thinking this will introduce another problem. If a plugin wants to use slf4j for logging instead of Plexus logger, but want the logging to be handled by core's logging. They would then need to declare a dependency to slf4j-api. If they're only supporting v3.1+, then they could declare a provided scope dependency and not include a dep to an impl. But if they want their plugin to work with older Maven versions as well (which they very likely want), then they need to have a compile scope dependency to slf4j AND an impl. So true. Every plugin would want to be compatible with Maven 3.1 as well as older versions. As such, I withdraw by earlier worse-is-better logging policy. /Anders -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0
On 04.12.2012 19:18, Jason van Zyl wrote:
I've been talking to Ceki about configuration in SLF4J as there is
really no way to change the log level without assuming an
implementation. If that's the way then for embedding the user can
change the SLF4J implementation but for the CLI this will not be
possible. What I would effectively have to do is what the Sonar folks
did which is to grab hold of the implementation and programmatically
change the log level.
So if the default log level is INFO I don't think it's possible to
ship all implementations and be able to flip to debug mode easily. So
I think if we pick one implementation then for the CLI we can make
that assumption. Again this should not affect folks who embed like m2e
as we just use the components and do our own SLF4J integration.
It would be possible to set the level of a logger by invoking
framework-specific directives. Here is some pseudo-code:
// pseudo code
public void setLevel(Logger logger, int level) {
if(logger instanceof org.apache.log4j.Logger) {
log4jSetLevel(logger, level);
} else if(logger instanceof ch.qos.logback.classic.Logger) {
logbackSetLevel(logger, level);
} else if (logger instanceof java.util.logging.Logger) {
julSetLevel(logger, level);
} else if (you get the idea...) {
...
}
}
Historically, SLF4J has shied away from providing abstractions for
logging configuration for two reasons:
1) logging configuration can have quite a large scope.
2) insufficient demand
If the scope of configuration is limited to logger level
configuration, the problem becomes much easier to tackle as
illustrated by the pseudo code above. Would Maven's logging
configuration requirements be satisfied by logger level configuration
or are there requirements beyond logger level configuration?
By the way, the is no reason why Maven could not implement similar
level configuration code on its own without depending on a slf4j
configuration module which currently does not exist.
--
Ceki
http://twitter.com/#!/ceki
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Hi All, In sonar-core, looking at the Logback class in the org.sonar.core.config package, you can find following lines: import ch.qos.logback.classic.LoggerContext; import org.slf4j.LoggerFactory; ... LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); Sonar is assuming that SLF4J is bound with Logback, not an unreasonable assumption for stand-alone Sonar or for a maven-plugin before Maven started using SLF4J. However, with Maven 3.1, this assumption proves to be incorrect. I would suggest to contact Sonar people so that the code which configures Logback first checks that SLF4J is bound to Logback. If not, the code should not attempt to configure logback. Basically, Sonar should add a few lines of defensive code. My 2c. -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Merged or separated logs WAS: SLF4J integration
On 12.10.2012 00:01, Jason van Zyl wrote: Ceki made some sample plugins and we'll post something tomorrow about some options for integration. Basically Merged vs Mixed: do we want to funnel everything into the the core logging backend, or let the plugin completely decided by declaring both the API and implementation. The outcome of this discussion will determine how to export (or not) packages from the core. I prefer to use the term separated logging to mixed logging. Now is a good time to discuss the merged vs. separated logging strategies for Maven. In the merged strategy, all logging goes through the slf4j-api instance created by maven-core, regardless of slf4j-related dependency declarations in a given plugin. In the separated strategy, a given plugin gets its own separate logging environment by declaring slf4j-related dependencies. The separated strategy raises the issue of whether getLog() and injected SLF4J loggers should be attached to the maven-core logging environment or the plugin's own logging environment. I am a big fan of separated logging strategy in application servers where forced merging the logs of all applications with the logs of the server is rather counter-intuitive not to say counter-productive. In the case of Maven however, I fail to see the added value in letting a given plugin have a separated logging environment. Merged logging offers the following advantages: 1) a very simple mental model for logging in Maven 2) seems that it is already implemented in trunk 3) few possible surprises in the future. and the following disadvantages: 1) the logging behavior of existing plugins (those declaring dependencies on slf4j) will change, i.e. merged into maven-core logging 2) relatively heavy handed approach In the context of Maven, is there any added value in pluging having a separated logging environment? If there is no added value, then merged logging is the way to go. -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
On 11.10.2012 08:37, Mark Struberg wrote: Hi Mark, Hi Ceki, thanks for the reply! The method signatures of classes in the org.slf4j package such as? Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.? No they are not. I did a diff between 1.2 and the latest and it seems a few trace() methods got added. This is only a minor problem but still. This change is perfectly backward compatible, but it's not forward compatible. If there is any new signature added/changed in a newer version which we will not yet use, then we would just crash if a plugin uses the newer version. Now this is highly unlikely. But I've seen this with commons logging and I've seen this with the LocationAwareLoger as you already mentioned below. This is btw exactly the reason why we shade in all commons-* stuff to private packages... Correct. The trace method was added in SLF4J version 1.4 released on May 16th 2007. Interestingly enough, I can't remember a single complaint about missing trace method. About 1% of slf4j-users use versions earlier than 1.4. Among that 1%, even fewer have a dependency requiring the trace method. As an end result, and as far as I can tell, no one complains about the missing trace method in earlier slf4j versions. My point is that there are some imaginary problems that never occur in practice. In practice, the slf4j version some software is compiled with is never a problem assuming it only imports from the org.slf4j package. this means that the minor version of the SLF4J binding must match that of the slf4j-api. The maintenance number is unimportant. That's perfectly fine that way! Please understand that this is nothing against slf4j! I just like to avoid that we introduce build problems to existing projects. As highlighted in my previous post there ARE ways to do that (by shielding via ClassWorlds), but this is not in place in trunk yet. Also there are zero integration tests for it atm! OK. Maven uses a child-first classloading strategy (with exceptions) - a plugin would only see exactly 1 version. Currently (again: there is atm no shielding in place yet) if a plugin would would provide it's own slf4j-api-1.4.2 then the plugin would get this version of the Class. And if the plugin would invoke LoggerFactory.getLogger(this.class()) then what would happen? Most probably a classcast exception, right? There is a minor chance that we do not blow up as there is a complex ClassLoading environment in place. But we only know after we have some IT in place which do not exist yet. All the change got committed without a single IT, thus my -1 in the first place. While I agree with the gist of your argument, I still maintain that slf4j versions is not the crux of the matter here. However, as you point out, class isolation should be implemented and tested. 2.) if you use slf4j, then ALL the funnels and logging backends must have the very same version number than the slf4j-api. Otherwise you are pretty much doomed. Ceki, is this correct as well? I would not go as far as doomed. For example, the following combination will work fine: slf4j-api-1.7.2.jar, sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar, jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words, you can freely mix artifacts in the 1.6.x and 1.7.x families. But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No you cannot as far as I've seen. So we cannot make a general assumption on that! The only safe rule is to not mix slf4j parts with diverging major or minor number. Is this correct? Yes, that is correct. Sounds good. I would recommend isolation regardless of the version of the discovered slf4j dependency. The plugin author probably wishes logging isolation. Maven should let the plugin have its own separate logging environment distinct from Maven's own logging. But that would actually be a big step backwards imo. No, separating maven logging and plugin logging (for the plugins that explicitly set their own slf4j logging environment) is not a step backwards. On the contrary, it preserves existing behavior. In my earlier message, I apparently did not insist enough on the the point that isolation was only required for the minority of plugins which set up their own slf4j-based logging environment. The vast majority of plugins which do not declare an slf4j dependency, would get their slf4j loggers either via injection or via getLogger(). Currently any plugin is forced to 'funnel' the output into the logger it obtains via getLogger() itself. This is an instance of org.apache.maven.plugin.logging.Log and we have it perfectly under our own control. It's not a perfectly convenient logging api but it works and shields us from all implementation details! This has been discussed earlier so I won't respond. If we would isolate away all the logging of a plugin (because it contains a diverging slf4j version) then we would loose all this logs, right? Of course
Re: SLF4J integration
On 11.10.2012 10:24, Anders Hammar wrote: Just to get this clear in my head: When you're talking about slf4j dependency in a plugin, are you talking about dependency to slf4j-api or an slf4j impl? A plugin declaring a dependency on slf4j-api without declaring a dependency on an implementation does not makes sense imo. It follows that the term declaring a dependency on slf4j means a dependency on both slf4j-api as well as a binding, aka implementation. /Anders -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
On 11.10.2012 11:18, Mark Struberg wrote: Oh I missed one more constellation a plugin could have slf4j-1.5.x + a logging backend we do not know of. I hope such things dont often exist, but in theory it could happen. For all of those cases we need isolation. A few months before creating the SLF4J project, I had a lengthy conversation on the commons-dev mailing list about logging scenarios. Richard Sitze (from IBM) offered a number of complex scenarios, and that's when the penny finally dropped for me [1]. It is a waste of time catering for all imaginable logging scenarios. The space of possible logging scenarios is truly vast. However, only a very limited number of these scenarios occur in practice. It makes more sense to concentrate on the common scenarios to ensure that they are well supported. More concretely, I propose that we find one or two examples of plugins declaring an slf4j dependency and test these plugins with the upcoming version of maven (the one using slf4j). [1] http://marc.info/?t=11078097261r=1w=2 -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
On 11.10.2012 12:17, Anders Hammar wrote: A plugin declaring a dependency on slf4j-api without declaring a dependency on an implementation does not makes sense imo. It follows that the term declaring a dependency on slf4j means a dependency on both slf4j-api as well as a binding, aka implementation. If the get the slf4j logger injected they would only have a slf4j-api dependency, wouldn't they? I'm asking as I *think* we said we would use slf4j as the logging interface in Maven. Yes, the maven-core dependency is on slf4j-api, not any particular impl. Only classes from the org.slf4j package are imported. What I'm thinking is that the aim is to allow plugins to use the core slf4j logging, right? But we would like to keep any existing behavior where a plugin logs to it's own logging file through slf4j, right? So then we can't check on a slf4j-api dependency, but need to look for an impl. If a plugin declares a dependency on say slf4j-jdk14, and assuming dep declarations in plugins are transitive, than plugin's classloader will also have classes from slf4j-api.jar in addition to those from slf4j-jdk14.jar. Thus, when the plugin imports org.slf4j.LoggerFactory, the instance of LoggerFactory will be bound to JUL. I think it makes sense to study actual plugins declaring a dependency on slf4j, instead of imagining problems which may or may not exist. -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
On 11.10.2012 12:43, Mark Struberg wrote: ceki, really, this is perfect example why no container uses commons-logging anymore. Do you like to repeat these errors? I reiterate: there is a workaround by isolating this in ClassWorlds. It is not yet there, but ff we like to use slf4j then we will need to implement that. How about looking at actual plugins? Do you have examples of plugins declaring a dependency on slf4j? Anyone else? -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
Hello all, I've created a trivial plugin which uses slf4j for logging: https://github.com/ceki/foo-plugin It declares a dependency on slf4j-api and slf4j-jdk14 Here are my observations: 1) when running with maven 3.0.3 the slf4j declaration is honored, i.e. logging goes through jul (slf4j-jdk14) 2) when running with maven 3.1-SNAPSHOT, the foo-plugins dependency declaration on slf4j-api and binding are simply ignored. Everything goes to slf4j-simple (the binding used by Maven) I find this second result quite surprising. Apparently, this is because Maven 3.1-SNAPSHOT exports the slf4j packages overriding the plugin dependency declarations on slf4j. In both scenarios, no exceptions are thrown. You are welcome to conduct your own tests. Best regards, -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J integration
On 10.10.2012 15:42, Mark Struberg wrote: Hi Mark, Hi! Here are a few basic observations about slf4j. slf4j really rocks for end user applications, but when it comes to deep container core stuff you must take care about classloader clashes much more than within an end-user project. We just don't know what a user defined in his plugin sections... If we like to use slf4j as maven logging api and export it in the core classloader then we might probably face the following problematic spots 1.) slf4j-api =1.5 and =1.6 are not fully binary compatible afaik. Ceki, is this correct? Afair there have been a few minor changes between those versions. They do not always cause problems but I've seen those in the wild already. The method signatures of classes in the org.slf4j package such as Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005. Client code which only imports the Logger, LoggerFactory, Marker, MDC classes will run fine with any version of slf4j-api, 1.0.x onwards. SLF4J bindings such as slf4j-simple, slf4j-log4j etc import classes from the org.slf4j.spi and org.slf4j.helpers packages which offer lesser guarantees with respect to stability of method signatures. For instance, as you mentioned, a method signature in the org.slf4j.spi.LocationAwareLogger class changed between 1.5 and 1.6. Assuming a major.minor.maintenance versioning scheme, this means that the minor version of the SLF4J binding must match that of the slf4j-api. The maintenance number is unimportant. As a client only importing from the org.slf4j package, you don't have to worry about the version of the slf4j-api with which some other dependency was compiled with. 2.) if you use slf4j, then ALL the funnels and logging backends must have the very same version number than the slf4j-api. Otherwise you are pretty much doomed. Ceki, is this correct as well? I would not go as far as doomed. For example, the following combination will work fine: slf4j-api-1.7.2.jar, sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar, jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words, you can freely mix artifacts in the 1.6.x and 1.7.x families. 3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a plugin brings his own log4j.jar then we will have class path clashes as well. There is no need for Maven to provide slf4j bridges (or funnels as you say) to plugins, is there? I'm happy if someone tells me the above observations are wrong and I just failed to setup the stuff properly. If not, then we still can use slf4j for maven BUT we need to isolate it really well via classworlds. And of course that would mean that we miss maven logging for those 'isolated' plugins, right? Most plugins should be able to see org.slf4j.* classes exported by maven-core. For the rare few plug-ins which declare their own version of slf4j artifacts, isolating the org.slf4j.* classes makes sense. Such isolation would serve two purposes. 1) it would avoid any version mismatch problem 2) it would isolate the plugin's logging from the logging in Maven core probably as intended by the plugin author. I'll first sum up the problems which will occur if the upper assumptions are correct. ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5, 1.4, etc This might cause class cast exceptions (Cannot cast class Logger to class Logger) by having different versions of the slf4j-api classes in different ClassLoaders This problem is independent of the version of the slf4j-api used. According to Section 4.3.4 of the Java Language Specification, two classes loaded by different class loaders are considered distinct and hence incompatible. ad 2.) we provide slf4j-simple-1.6 and user provides slf4j-xxx-1.4. This will most probably end up in a big *boom*. And we do not know all slf4j-** as any user might easily add his own backend. If I understand correctly, by default maven uses a self-first class loading strategy. Plugin's class loader will load slf4j classes defined in the plugin and everything may/should work seamlessly for legacy plugins. For non legacy plugins requesting slf4j logger injection via annotations and simultaneously declaring dependencies to slf4j classes, class cast exceptions are likely to be thrown. ad 3.) We will face class path clashes since a few slf4j funnels are not fully binary compatible with the original impls. So funneling is hard to do in maven. If others think it is possible, then please point out a way to do this properly, thanks! As mentioned earlier, I don't think Maven should use, declare or export any slf4j bridges. Now for the workaround we could implement: While discussing this topic with Stephen he had the idea to scan whether a plugin uses slf4j by unzipping all plugin dependencies and do some checks. E.g. check whether there is a org.slf4j.impl.StaticLoggerBinder.class If we detect this or any slf4j with a version != the version used in maven
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote: First, I also would recommend moving from plexus logging to SLF4J. Cool. Mark's concerns with incompatibilities only come about with the log4j bridge if you are trying to use APis that the SLF4J bridge hasn't implemented. Something being used in a plugin really shouldn't be using those. Exactly. Although Ceki is generally careful not to break compatibility, it has happened. For example, you cannot mix applications that use SLF4J 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much tied to the SLF4J version. See http://www.slf4j.org/news.html. If core is using SLF4J and an incompatible change is made again it probably won't be that big of a deal. Typically, when compatibility has been broken it really hasn't impacted code that uses the SLF4J API. SLF4J's user facing API, that is classes or interfaces located in the org.slf4j package such as Logger, Marker, MDC and LoggerFactory have been there and remain unchanged since day one (2005). Thus, a user never has to worry about with which version of slf4j-api a dependency was compiled with. A user can pick any version of slf4j-api-api.jar and as long as the version of the binding of her choice matches, slf4j will function correctly. See also [1,2]. The internal interfaces, those in the org.slf4j.spi or org.slf4j.helpers packages, may change incompatibly. One of the most notable occasions was in the 1.6.0 release when the LocationAwareLogger interface was changed. It was done so in response to a bug report [3] filed by... Ralph. The reader will appreciate the irony. More objectively though, Ralph filed a valid bug report and the only way to fix it was by making an incompatible change in an *internal* interface. Unfortunately, given the ubiquity of SLF4J, such incompatible changes somehow manage to leak into user-space and annoy the hell out of many developers. SLF4J is designed so that the problems occurring when deploying SLF4J are obvious with obvious solutions -- SLF4J is stupid by design. (Feel free to quote.) Mark mentioned shading as a way to fix any problems with SLF4J conflicts. I am not sure if shading will work with SLF4J. Implementations must provide a class named org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder and org.slf4j.impl.StaticMDCBinder. Jason made a comment in a previous reply that said Ceki is also a committer, and will help us fix anything when necessary so that, again, we can focus on Maven and not logging. http://people.apache.org/committer-index.html doesn't list him as a committer on Maven and Ceki has said publicly and privately that he is unlikely to contribute to ASF projects. However, while the statement is incorrect I don't understand why what Ceki would or wouldn't do would have any bearing on whether Maven adopts SLF4J. If need be, I'll happily answer questions and guide you through the process of migrating to SLF4J. However, I agree with Ralph, my person should have no bearing to whether Maven adopts SLF4J or not. Finally, I've been working on Log4j 2 for over 3 years now. The reason I started working on it was due to deficiencies in Logback that occur in large scale web applications and probably don't matter in something like Maven. But it would be nice to allow the end user the ability to swap out the logging implementation if they want. Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. In my not so humble opinion, all other questions are moot if you don't have a working policy for swapping-in/swapping-out logging frameworks. Lacking the necessary knowledge about how Maven bootstraps itself or how it manages its classloaders, I am not in a position to formulate such policy. On the other hand, there is more than enough expert knowledge here to address this problem. I intend to follow your future discussions with interest. [1] http://www.slf4j.org/manual.html#compatibility [2] http://www.slf4j.org/codes.html#version_mismatch [3] http://bugzilla.slf4j.org/show_bug.cgi?id=127 -- Ceki http://tinyurl.com/proLogback - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
Mark, I hope I did not convey the wrong message in my previous email. Commit r1380105 provides a backward compatible way for existing Maven plug-ins to continue using org.codehaus.plexus.Logger. The said Plexus logger would delegate to org.slf4j.Logger to perform actual logging. By a policy for swapping out logging back-ends, I meant formulating a policy leveraging SLF4J's own binding mechanism within Maven. For the purposes of this discussion), if slf4j-simple.jar is the default logging back-end in Maven, Maven's logging pluggability policy for switching to j.u.l. could be as straightforward as removing slf4j-simple.jar from $MAVEN_HOME/lib and replacing it with slf4j-jul.jar in $MAVEN_HOME/lib. Switching to log4j would entail replacing slf4j-jul.jar with slf4j-log4j12.jar and log4j.jar in $MAVEN_HOME/lib. Switching logback would mean replacing slf4j-log4j12.jar and log4j.jar with logback-core.jar and logback-classic.jar in $MAVEN_HOME/lib. You get the idea. As mentioned in my previous message, I don't know if the above would work due to my ignorance of exactly how Maven bootstraps. As for exporting SLF4J to Maven plug-ins, you are correct to observe that this would tie Maven to the SLF4J API. In my undeniably biased view, attempts at mitigating such coupling invariably yield poor results. Please see for further discussion. http://www.slf4j.org/faq.html#optional_dependency http://tinyurl.com/soWrapping On 10.09.2012 13:06, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! PS: there is a _huge_ difference whether you like to use a logging framework in a container or in an end-user application. In a container you just don't know what the user will throw into your container. And we did tried SLF4J for containers a few times and did hit those fundamental problems pretty early on. I'm pretty sure you know exactly what I mean. Others can grab the MyFaces, tomcat, OpenWebBeans, OpenJPA, ... lists for more info. Most time we either ended up doing our own logging facade or used JUL (yea it sucks big times, but at least it doesn't create classpath conflicts). -- Ceki http://tinyurl.com/proLogback - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Commented: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
[ http://jira.codehaus.org/browse/MAVENUPLOAD-685?page=comments#action_56078 ] Ceki Gulcu commented on MAVENUPLOAD-685: Hello Carlos, You mean the urls of the various bundle.jar files? We do not make the bundle files available independently of Ibiblio. The slf4j.org web-server does not carry them. Is it absolutely necessary that these links be added? Would it be sufficient to supply the jar files in the request as I have done in the past? Thank you in advance for your response,, Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Assignee: Carlos Sanchez Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar, slf4j-jdk14-1.0-rc5-bundle.jar, slf4j-log4j12-1.0-rc5-bundle.jar, slf4j-log4j13-1.0-rc5-bundle.jar, slf4j-nop-1.0-rc5-bundle.jar, slf4j-simple-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
[ http://jira.codehaus.org/browse/MAVENUPLOAD-685?page=comments#action_56079 ] Ceki Gulcu commented on MAVENUPLOAD-685: Carlos, By the way, I forgot to thank you for kindly uploading the bundle files as requested. Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Assignee: Carlos Sanchez Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar, slf4j-jdk14-1.0-rc5-bundle.jar, slf4j-log4j12-1.0-rc5-bundle.jar, slf4j-log4j13-1.0-rc5-bundle.jar, slf4j-nop-1.0-rc5-bundle.jar, slf4j-simple-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
[ http://jira.codehaus.org/browse/MAVENUPLOAD-685?page=all ] Ceki Gulcu updated MAVENUPLOAD-685: --- Attachment: slf4j-nop-1.0-rc5-bundle.jar slf4j-log4j13-1.0-rc5-bundle.jar slf4j-jdk14-1.0-rc5-bundle.jar Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar, slf4j-jdk14-1.0-rc5-bundle.jar, slf4j-log4j12-1.0-rc5-bundle.jar, slf4j-log4j13-1.0-rc5-bundle.jar, slf4j-nop-1.0-rc5-bundle.jar, slf4j-simple-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
[ http://jira.codehaus.org/browse/MAVENUPLOAD-685?page=all ] Ceki Gulcu updated MAVENUPLOAD-685: --- Attachment: slf4j-simple-1.0-rc5-bundle.jar Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar, slf4j-jdk14-1.0-rc5-bundle.jar, slf4j-log4j12-1.0-rc5-bundle.jar, slf4j-log4j13-1.0-rc5-bundle.jar, slf4j-nop-1.0-rc5-bundle.jar, slf4j-simple-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-685) Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21
[ http://jira.codehaus.org/browse/MAVENUPLOAD-685?page=all ] Ceki Gulcu updated MAVENUPLOAD-685: --- Attachment: slf4j-log4j12-1.0-rc5-bundle.jar Upload request for SLF4J 1.0RC5 and NLOG4J 1.2.21 -- Key: MAVENUPLOAD-685 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-685 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc5-bundle.jar, nlog4j-1.2.21-bundle.jar, slf4j-jcl-1.0-rc5-bundle.jar, slf4j-jdk14-1.0-rc5-bundle.jar, slf4j-log4j12-1.0-rc5-bundle.jar, slf4j-log4j13-1.0-rc5-bundle.jar, slf4j-nop-1.0-rc5-bundle.jar, slf4j-simple-1.0-rc5-bundle.jar The SLF4J project recently released version 1.0RC5 of SLF4J API and NLOG4J 1.2.21. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-622) Update request for NLOG4J 1.2.19
Update request for NLOG4J 1.2.19 Key: MAVENUPLOAD-622 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-622 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.19-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-621) Upload request for SLF4J 1.0-RC3
Upload request for SLF4J 1.0-RC3 Key: MAVENUPLOAD-621 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-621 Project: maven-upload-requests Type: Bug Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc3-bundle.jar, slf4j-jcl-1.0-rc3-bundle.jar, slf4j-jdk14-1.0-rc3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-621) Upload request for SLF4J 1.0-RC3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-621?page=all ] Ceki Gulcu updated MAVENUPLOAD-621: --- Attachment: slf4j-nop-1.0-rc3-bundle.jar slf4j-log4j13-1.0-rc3-bundle.jar slf4j-log4j12-1.0-rc3-bundle.jar Upload request for SLF4J 1.0-RC3 Key: MAVENUPLOAD-621 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-621 Project: maven-upload-requests Type: Bug Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc3-bundle.jar, slf4j-jcl-1.0-rc3-bundle.jar, slf4j-jdk14-1.0-rc3-bundle.jar, slf4j-log4j12-1.0-rc3-bundle.jar, slf4j-log4j13-1.0-rc3-bundle.jar, slf4j-nop-1.0-rc3-bundle.jar, slf4j-simple-1.0-rc3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-621) Upload request for SLF4J 1.0-RC3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-621?page=all ] Ceki Gulcu updated MAVENUPLOAD-621: --- Attachment: slf4j-simple-1.0-rc3-bundle.jar Upload request for SLF4J 1.0-RC3 Key: MAVENUPLOAD-621 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-621 Project: maven-upload-requests Type: Bug Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc3-bundle.jar, slf4j-jcl-1.0-rc3-bundle.jar, slf4j-jdk14-1.0-rc3-bundle.jar, slf4j-log4j12-1.0-rc3-bundle.jar, slf4j-log4j13-1.0-rc3-bundle.jar, slf4j-nop-1.0-rc3-bundle.jar, slf4j-simple-1.0-rc3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-613) Update request for SLF4J 1.0rc2
Update request for SLF4J 1.0rc2 --- Key: MAVENUPLOAD-613 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-613 Project: maven-upload-requests Type: Wish Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc2-bundle.jar, slf4j-jcl-1.0-rc2-bundle.jar, slf4j-jdk14-1.0-rc2-bundle.jar The SLF4J project recently released version 1.0RC2 of SLF4J API. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-597) Update request for SLF4J 1.0rc1
Update request for SLF4J 1.0rc1 --- Key: MAVENUPLOAD-597 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-597 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc1-bundle.jar, slf4j-jdk14-1.0-rc1-bundle.jar, slf4j-log4j12-1.0-rc1-bundle.jar, slf4j-log4j13-1.0-rc1-bundle.jar, slf4j-nop-1.0-rc1-bundle.jar, slf4j-simple-1.0-rc1-bundle.jar The SLF4J project recently released version 1.0RC1 of SLF4J API. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-597) Update request for SLF4J 1.0rc1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-597?page=all ] Ceki Gulcu updated MAVENUPLOAD-597: --- Attachment: slf4j-simple-1.0-rc1-bundle.jar slf4j-nop-1.0-rc1-bundle.jar slf4j-log4j13-1.0-rc1-bundle.jar Update request for SLF4J 1.0rc1 --- Key: MAVENUPLOAD-597 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-597 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-rc1-bundle.jar, slf4j-jdk14-1.0-rc1-bundle.jar, slf4j-log4j12-1.0-rc1-bundle.jar, slf4j-log4j13-1.0-rc1-bundle.jar, slf4j-nop-1.0-rc1-bundle.jar, slf4j-simple-1.0-rc1-bundle.jar The SLF4J project recently released version 1.0RC1 of SLF4J API. Please kindly add the attached files to ibiblio's maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-553) pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8
pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8 --- Key: MAVENUPLOAD-553 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-553 Project: maven-upload-requests Type: Wish Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta8-bundle.jar, slf4j-jdk14-1.0-beta8-bundle.jar, slf4j-log4j-1.0-beta8-bundle.jar, slf4j-nop-1.0-beta8-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-553) pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-553?page=all ] Ceki Gulcu updated MAVENUPLOAD-553: --- Attachment: slf4j-nop-1.0-beta8-bundle.jar pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8 --- Key: MAVENUPLOAD-553 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-553 Project: maven-upload-requests Type: Wish Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta8-bundle.jar, slf4j-jdk14-1.0-beta8-bundle.jar, slf4j-log4j-1.0-beta8-bundle.jar, slf4j-nop-1.0-beta8-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-553) pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-553?page=all ] Ceki Gulcu updated MAVENUPLOAD-553: --- Attachment: nlog4j-1.2.18-bundle.jar slf4j-simple-1.0-beta8-bundle.jar pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8 --- Key: MAVENUPLOAD-553 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-553 Project: maven-upload-requests Type: Wish Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta8-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta8-bundle.jar, slf4j-log4j-1.0-beta8-bundle.jar, slf4j-nop-1.0-beta8-bundle.jar, slf4j-simple-1.0-beta8-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-553) pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-553?page=all ] Ceki Gulcu closed MAVENUPLOAD-553: -- Resolution: Won't Fix SLF4J 1.0beta8 will be replaced in just a few minutes with SLF4J 1.0beta8. There is no need to upload these files to ibiblio. pload request for NLOG4J 1.2.18 and SLF4J 1.0-beta8 --- Key: MAVENUPLOAD-553 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-553 Project: maven-upload-requests Type: Wish Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta8-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta8-bundle.jar, slf4j-log4j-1.0-beta8-bundle.jar, slf4j-nop-1.0-beta8-bundle.jar, slf4j-simple-1.0-beta8-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-554) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-554 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-554 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j-1.0-beta9-bundle.jar, slf4j-nop-1.0-beta9-bundle.jar, slf4j-simple-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-554) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-554?page=all ] Ceki Gulcu updated MAVENUPLOAD-554: --- Attachment: slf4j-simple-1.0-beta9-bundle.jar slf4j-nop-1.0-beta9-bundle.jar slf4j-log4j-1.0-beta9-bundle.jar Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-554 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-554 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j-1.0-beta9-bundle.jar, slf4j-nop-1.0-beta9-bundle.jar, slf4j-simple-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-555) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-555 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-555 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j12-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-554) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-554?page=all ] Ceki Gulcu closed MAVENUPLOAD-554: -- Resolution: Incomplete I mistakenly uploaded a wrong version of one of the files. Please ignore this upload request. Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-554 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-554 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j-1.0-beta9-bundle.jar, slf4j-nop-1.0-beta9-bundle.jar, slf4j-simple-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-555) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-555?page=all ] Ceki Gulcu updated MAVENUPLOAD-555: --- Attachment: slf4j-simple-1.0-beta9-bundle.jar slf4j-nop-1.0-beta9-bundle.jar slf4j-log4j13-1.0-beta9-bundle.jar Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-555 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-555 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j12-1.0-beta9-bundle.jar, slf4j-log4j13-1.0-beta9-bundle.jar, slf4j-nop-1.0-beta9-bundle.jar, slf4j-simple-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-555) Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-555?page=all ] Ceki Gulcu updated MAVENUPLOAD-555: --- Attachment: nlog4j-1.2.18-bundle.jar Upload request for NLOG4J 1.2.18 and SLF4J 1.0-beta9 Key: MAVENUPLOAD-555 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-555 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta9-bundle.jar, nlog4j-1.2.18-bundle.jar, slf4j-jdk14-1.0-beta9-bundle.jar, slf4j-log4j12-1.0-beta9-bundle.jar, slf4j-log4j13-1.0-beta9-bundle.jar, slf4j-nop-1.0-beta9-bundle.jar, slf4j-simple-1.0-beta9-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVENUPLOAD-503) Upload request for jcl104-over-slf4j
[ http://jira.codehaus.org/browse/MAVENUPLOAD-503?page=all ] Ceki Gulcu reopened MAVENUPLOAD-503: Sorry to bug you but I noticed that the issue but the jcl104-over-slf4j files have still not appeared at http://ibiblio.org/maven/org.slf4j/. Is it due to a delay in refreshing the files? Upload request for jcl104-over-slf4j -- Key: MAVENUPLOAD-503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-503 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Assignee: Carlos Sanchez Attachments: jcl104-over-slf4j-1.0-beta7-bundle.jar Please kindly upload the jcl104-over-slf4j-bundle.jar included as an attachment. For details about when to use JCL over SLF4J please refer to http://www.slf4j.org/manual.html#gradual -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-503) Upload request for jcl104-over-slf4j
Upload request for jcl104-over-slf4j -- Key: MAVENUPLOAD-503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-503 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: jcl104-over-slf4j-1.0-beta7-bundle.jar Please kindly upload the jcl104-over-slf4j-bundle.jar included as an attachment. For details about when to use JCL over SLF4J please refer to http://www.slf4j.org/manual.html#gradual -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-493?page=all ] Ceki Gulcu updated MAVENUPLOAD-493: --- Attachment: nlog4j-1.2.17.jar Added mising NLOG4J 1.2.17 jar. Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-492) Nees to upload a slf4j beta7 jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-492?page=comments#action_45367 ] Ceki Gulcu commented on MAVENUPLOAD-492: Duplicate of issue 493, http://jira.codehaus.org/browse/MAVENUPLOAD-493 Nees to upload a slf4j beta7 jar Key: MAVENUPLOAD-492 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-492 Project: maven-upload-requests Type: Task Reporter: Jeff Genender http://people.apache.org/~jgenender/slf4j-simple-1.0-beta7-bundle.jar http://www.slf4j.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-493?page=all ] Ceki Gulcu updated MAVENUPLOAD-493: --- Attachment: slf4j-nop-1.0-beta7-bundle.jar Added slf4j-nop-1.0-beta7-bundle.jar bundle file Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-493?page=all ] Ceki Gulcu updated MAVENUPLOAD-493: --- Attachment: slf4j-simple-1.0-beta7-bundle.jar slf4j-simple-1.0-beta7-bundle.jar Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-493?page=all ] Ceki Gulcu updated MAVENUPLOAD-493: --- Attachment: slf4j-jdk14-1.0-beta7-bundle.jar Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-493) Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-493?page=comments#action_45370 ] Ceki Gulcu commented on MAVENUPLOAD-493: For your convenience I've added bundle files for the various slf4j jars. These bundles include LICENSE.txt, project.xml and the relevant jar file. Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 Key: MAVENUPLOAD-493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-493 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-jdk14-1.0-beta7.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7.jar, slf4j-simple-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7.jar The SLF4J project recently released version 1.0beta7 of the SLF4J API as well as version 1.2.17 of NLOG4J. The POM files for a previous version of SLF4J already exist. Could you please upload the attached jar files to maven? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-494) Another Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 (replaces requests 492 and 493)
Another Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 (replaces requests 492 and 493) Key: MAVENUPLOAD-494 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-494 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17-bundle.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7-bundle.jar This request supercededs requests 492 and 493. In particular, request 493 contains bundle files with erroneous project.xml files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-494) Another Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 (replaces requests 492 and 493)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-494?page=all ] Ceki Gulcu updated MAVENUPLOAD-494: --- Attachment: nlog4j-1.2.17-bundle.jar Another Upload request for NLOG4J 1.2.17 and SLF4J 1.0-beta7 (replaces requests 492 and 493) Key: MAVENUPLOAD-494 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-494 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.17-bundle.jar, slf4j-jdk14-1.0-beta7-bundle.jar, slf4j-nop-1.0-beta7-bundle.jar, slf4j-simple-1.0-beta7-bundle.jar This request supercededs requests 492 and 493. In particular, request 493 contains bundle files with erroneous project.xml files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-431) Upload request for NLOG4J 1.2.14 and SLF4J 1.0-beta4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-431?page=comments#action_43141 ] Ceki Gulcu commented on MAVENUPLOAD-431: I can confirm that the file jmxtools.jar ships with JMX 1.2 Reference Implementation which you can download from Sun's website. Please let me know if you need further information. Ceki Upload request for NLOG4J 1.2.14 and SLF4J 1.0-beta4 Key: MAVENUPLOAD-431 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-431 Project: maven-upload-requests Type: Task Reporter: Alex Karasulu Attachments: nlog4j-wrapper-1.2.14.jar, nlog4j-wrapper-1.2.14.jar, slf4j-wrapper-jdk14-1.0-beta4.jar, slf4j-wrapper-jdk14-1.0-beta4.jar, slf4j-wrapper-nop-1.0-beta4.jar, slf4j-wrapper-nop-1.0-beta4.jar, slf4j-wrapper-simple-1.0-beta4.jar, slf4j-wrapper-simple-1.0-beta4.jar These files have been listed below rather than using a bundle. The bundle path is really a URL to our repo at safehaus where we keep these files. They are not maven based projects so we do not have a project.xml to do this. http://maven.safehaus.org/nlog4j/jars/nlog4j-1.2.14.jar http://maven.safehaus.org/slf4j/jars/slf4j-jdk14-1.0-beta4.jar http://maven.safehaus.org/slf4j/jars/slf4j-nop-1.0-beta4.jar http://maven.safehaus.org/slf4j/jars/slf4j-simple-1.0-beta4.jar Thanks, Alex -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
