On Sep 9, 2012, at 11:08 PM, Ralph Goers wrote:
> 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
First, I also would recommend moving from plexus logging to SLF4J.
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.
Although C
On Sep 9, 2012, at 4:19 PM, Mark Struberg wrote:
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> At least I do not see it yet
>
With what I've done you can use plexus.Logger if you like until the end of
time, as can any
On Sun, Sep 9, 2012 at 4:19 PM, Mark Struberg wrote:
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> At least I do not see it yet
>
> It would make sense if plugins could add a logging bridge which is used by
> 'their' fram
If a plugin creates a custom classloader inheriting from the tccl you can
get issues with slf4j (because of their singleton)
Le 9 sept. 2012 22:20, "Mark Struberg" a écrit :
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> A
nope, no problem with just slf4j api and logback.
But that wont give us much benefit over just using plexus.Logger.
At least I do not see it yet
It would make sense if plugins could add a logging bridge which is used by
'their' framework. But otoh we have already kind of a bridge by grabbing the
Mark,
Here's how SLF4J attempts to make all the framework happy living under the same
roof:
http://www.slf4j.org/legacy.html
On Sep 9, 2012, at 3:34 PM, Mark Struberg wrote:
>
>> No client code changes unless the client wants to change it to take
>> advantage of
>> SLF4J.
>
> It's not the
So this situation is present irrespective of your logging facade unless you
just completely isolate yourself. I'm not in favour of trying to completely
isolate ourselves and not use existing frameworks, and SLF4J has likely
encountered most of the troubling obstacles. You're never going to be a
I join too ;)
IMO mvn doesnt need logback or slf4j at all. If you want to get rid of your
log facade use juli to create a new one (as cxf or owb does). Dont mess the
classpath with slf4j which has its drawbacks too
Le 9 sept. 2012 21:44, "Benson Margulies" a écrit :
> On Sun, Sep 9, 2012 at 3:34
On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg wrote:
>
>> No client code changes unless the client wants to change it to take
>> advantage of
>> SLF4J.
>
> It's not the classes which change but the classpath does. It might then
> contain clashing classes. That is what I'm afraid of to be honest.
> No client code changes unless the client wants to change it to take advantage
> of
> SLF4J.
It's not the classes which change but the classpath does. It might then contain
clashing classes. That is what I'm afraid of to be honest. Because we do not
have the 'other side' (random plugins and
On Sep 9, 2012, at 3:14 PM, Anders Hammar wrote:
> I'll join. :-)
>
>> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
>> favor, because it's much more common and popular than plexus.
>
> Me too. And I'm even arguing we should try to switch to slf4j in core.
> Sure, no re
I'll join. :-)
> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
> favor, because it's much more common and popular than plexus.
Me too. And I'm even arguing we should try to switch to slf4j in core.
Sure, no real technical advantage, but I believe it's easier for other
peo
Minds are, like rules, meant to be broken. :-) That could go into 3.2
just as well.
But, being the newest boy in town I won't push this too much.
/Anders
On Sun, Sep 9, 2012 at 1:12 PM, Robert Scholte wrote:
> It looks to me the changes fit more a 3.0.5
>
> I always had in mind, that with the 3
On Sep 9, 2012, at 2:24 PM, Benson Margulies wrote:
> Again, let's deal with this one thing at a time:
>
> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
> favor, because it's much more common and popular than plexus.
>
> 2. Picking an slf4j-X to deliver logging to somew
Again, let's deal with this one thing at a time:
1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
favor, because it's much more common and popular than plexus.
2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in
favor of java.util.logging for this, because
I think you're trying to preemptively solve for an issue that we may not have.
I believe that if the right JARs are in the classpath first we will easily be
able to tell running the integration tests for Maven and the integration tests
for all the plugins if there's going to be an issue. I belie
On Sep 9, 2012, at 12:57 PM, Mark Struberg wrote:
> +1
>
> maybe we should first try to clarify what to use slf4j for.
>
> slf4j has 2 'adaptors'
>
> 1.) you can use the slf4j-api as logging facede to log to any logging backend
> you like. Be it log4j, logback, etc. In that case you use the s
> Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
> components use what logging framework.
Yes, only that this sometimes causes really unfriendly classcast exceptions :/
How can we deal with those? Is there a retry possible? Imo not easily.
Could we scan the plugin cla
Boils down to 1) pick a logging facade and 2) pick a default implementation.
SLF4J is really the de facto standard, used everywhere including 15 projects
here at Apache.
It's unlikely to be surprising to anyone with the changes I've made as it will
appear just like it does now. A bunch of log s
I am completely +1 to introducing slf4j as the official API and
allowing plexus logging to slide, however slowly, into the sunset.
Everyone and his or her cat knows the SLF4J API. That, to me, is a
more than sufficient reason to supplement and eventually replace the
existing logging facade. That mi
On Sep 9, 2012, at 12:38 PM, Mark Struberg wrote:
> sorry, didn't catch this reply earlier.
>
> I see, but then we are back to my original problem. Once you add e.g.
> log4j-slf4j binding then you will get nasty class cast exceptions because
> they are not fully binary compatible. If there is
+1
maybe we should first try to clarify what to use slf4j for.
slf4j has 2 'adaptors'
1.) you can use the slf4j-api as logging facede to log to any logging backend
you like. Be it log4j, logback, etc. In that case you use the slf4j API in your
project
2.) you can use slf4j as 'bridge' to othe
On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg wrote:
> sorry, didn't catch this reply earlier.
>
> I see, but then we are back to my original problem. Once you add e.g.
> log4j-slf4j binding then you will get nasty class cast exceptions because
> they are not fully binary compatible. If there i
sorry, didn't catch this reply earlier.
I see, but then we are back to my original problem. Once you add e.g.
log4j-slf4j binding then you will get nasty class cast exceptions because they
are not fully binary compatible. If there is a log4j.jar in the classpath of
the plugin already then it m
Sorry for brevity
> slf4j
and my response is still the same: those are no technical arguments. I asked
the specific question why we shall wrap one logging facade with another logging
facade. And I still got no answer to this one.
>No client code has to use anything from Guice if they wish not t
On Sep 9, 2012, at 4:17 AM, Mark Struberg wrote:
> Can you again please explain me what the benefit of the SLF4J abstraction
> over the already used plexus.Logger is? Both are just logging facades.
>
But really I think the biggest benefit is that, as far as I know, SLF4J
integrates with every
On Sep 9, 2012, at 8:26 AM, Olivier Lamy wrote:
> 2012/9/9 Mark Struberg :
>> Btw, what do you think about moving the core-classrealm config to a
>> properties file and have them detect dynamically?
>>
>> META-INF/maven/core/core-realm.properties
>>
>> with a list of all packages which shall g
On Sep 9, 2012, at 4:17 AM, Mark Struberg wrote:
> Can you again please explain me what the benefit of the SLF4J abstraction
> over the already used plexus.Logger is? Both are just logging facades.
>
Sure, I can repost the list of benefits I posted a couple days ago:
- Ubiquity. SLF4J may not
You guys pick, it's easy enough to switch. The extensions directory only picks
up new components and binds them first. If you want to flip out the
implementation you need to remove the implementation JAR and swap in the other.
Still not terribly hard, and it would likely be integrators flipping
I noted in the issue where the tool is and there's a standard Maven plugin page
there. Probably as well documented as how to do it with Plexus :-)
I have a series of posts I'm writing which can be the basis of documentation.
Code here[1], and the documentation is here[2].
[1]: https://github.co
Hi,
The Apache Maven team is pleased to announce the release of the Apache
Maven Scm 1.8
http://maven.apache.org/scm
Release Notes - Maven SCM - Version 1.8
** New Feature
* [SCM-679] - enhance scm api to support limited number of
returned changesets by changelog command
** Bug
* [SCM-
2012/9/3 :
> Author: jvanzyl
> Date: Mon Sep 3 01:07:31 2012
> New Revision: 1380105
>
> URL: http://svn.apache.org/viewvc?rev=1380105&view=rev
> Log:
> o Enabled support and discovery of JSR-330 components
>
> o Added Slf4j logger factory to support generic JSR-330 logging
>
> o Exported Guice p
2012/9/9 Mark Struberg :
> Btw, what do you think about moving the core-classrealm config to a
> properties file and have them detect dynamically?
>
> META-INF/maven/core/core-realm.properties
>
> with a list of all packages which shall get exported as core realm.
> That would allow sonatype and o
It looks to me the changes fit more a 3.0.5
I always had in mind, that with the 3.1 we would make the pom-parser more
strict meaning:
- don't warn but fail for plugins without versions
- don't warn but fail for duplicate dependency entries
(there are probably more...)
Robert
Op Sun, 09 Sep
Anyone -1 of bumping to v3.1 for core?
/Anders
On Sat, Sep 8, 2012 at 9:39 AM, Stephen Connolly
wrote:
> +1 on bump to 3.1
>
> On Friday, 7 September 2012, Anders Hammar wrote:
>
>> I know. But there wasn't much visible change in v3.0 either. And I'm
>> thinking that it would be easier to commun
Btw, what do you think about moving the core-classrealm config to a properties
file and have them detect dynamically?
META-INF/maven/core/core-realm.properties
with a list of all packages which shall get exported as core realm.
That would allow sonatype and others to just place their stuff into
On 2012-09-09 10:41, Dennis Lundberg wrote:
> On 2012-09-08 23:37, Hervé BOUTEMY wrote:
>> Le samedi 8 septembre 2012 21:14:21 Olivier Lamy a écrit :
>>> I have removed use of .repository.
>>> Looks better
>> great!
>> Thank you: ITs are now ok with M2!!!
>
> Great work!
>
>>> except this one
>>>
On 2012-09-08 23:37, Hervé BOUTEMY wrote:
> Le samedi 8 septembre 2012 21:14:21 Olivier Lamy a écrit :
>> I have removed use of .repository.
>> Looks better
> great!
> Thank you: ITs are now ok with M2!!!
Great work!
>> except this one
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-pl
Can you again please explain me what the benefit of the SLF4J abstraction over
the already used plexus.Logger is? Both are just logging facades.
I mean you can still use whatever bridge underneath plexus.Logger. And
plexus.Logger is exclusively used by Maven, so we have a guarantee to not
intro
40 matches
Mail list logo
