It's not about rush, it is about touching the Logging Framework while for
the majority of the end-users it won't make that much of a difference.
I'm thinking what would make it interesting for me as an end-user to use
this next release (apart from the bugfixes). We could already log and
control the logging-level. Now colors would make it more interesting, even
if we could provide it as an extension (not part of core), as long as it
works.
Sure, for the specialists these changes offer new opportunities, but
that's a small group.
Robert
Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl <ja...@tesla.io>:
On Dec 7, 2012, at 12:15 PM, Robert Scholte <rfscho...@apache.org> wrote:
If 3.1.0 is going to be the "New Logger"-release, I'd prefer to include
the colored logger as well.
I'm not putting it in the release because I'm not, without discussion
1) Putting 3 logging implementations into the distribution
or
2) Putting an immature logging implementation as the default
Not something to be taken lightly and it's been 11 months at this point
so what's the rush?
That would make it more complete. Also, if coloring would require extra
adjustments to the logging framework then now is the time. (it seems to
work out of the box, but we have to be sure.)
Robert
Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies
<bimargul...@gmail.com>:
As I see it, the vote bogged down because Kristian found problems, and
I haven't seen clear evidence that those problems are sorted out. I'd
be happy to vote +1 with respect to all the design questions for the
release 'as is'.
On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg <strub...@yahoo.de>
wrote:
good idea, Benson.
Btw, this VOTE did not get enough +1 in more than a week. And this is
not because not enough people took care if you look at the plenty of
comments in the thread.
1.) Do people have any technical comment on my proposal to introduce
a new plugin-plugin flag for exposing slf4j? Is there any technical
problem with that?
Are there other proposals which might help increasing backward
compatibility?
2.) what about the coloured logger with log4j2? I tried it locally
and it worked great. What is the status? (Sorry if I missed something)
LieGrue,
strub
----- Original Message -----
From: Benson Margulies <bimargul...@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Cc:
Sent: Friday, December 7, 2012 2:28 PM
Subject: Re: [VOTE] Maven 3.1.0
Could we please find an appropriate subject line for this debate,
unless you all are really discussing this design question as part of
the (still?) outstanding vote on 3.1.0?
On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
Another way of looking at this is whether this kind of behavior
change in
appropriate for a minor release, instead of a major release.
On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg <strub...@yahoo.de>
wrote:
Daniel, please think through these old project scenarios. Those old
projects did ship their own slf4j impl + config and parsed their
own
logs
and extracted information. They will now just fall on their knees
because
the logs are no longer available for them. Instead they will be
somewhere
in the maven logs which could be anywhere from a plugin point of
view.
This is not fixed, this is broken imo.
LieGrue,
strub
----- Original Message -----
> From: Daniel Kulp <dk...@apache.org>
> To: Maven Developers List <dev@maven.apache.org>
> Cc:
> Sent: Friday, December 7, 2012 1:49 PM
> Subject: Re: [VOTE] Maven 3.1.0
>
>
>>
>> Again the state of affairs of 3.1.0 today: old projects and
plugins
which
> didnt use slf4j so far don't get any benefit from forcing
slf4j on them.
And
> old projects and plugins which _did_ use slf4j already are now
broken
with the
> current trunk. I cannot see how we can seriously release this to
users
right
> now.
>
>
>
> I don't consider them broken. I consider them fixed. Old
plugins
that
> use SLF4J now get there information properly integrated with the
rest of
the
> maven information.
>
>
> Dan
>
>
>
> On Dec 7, 2012, at 7:32 AM, Mark Struberg
<strub...@yahoo.de> wrote:
>
>>> The final proposal that I see is where we give a metadata
flag
>> (defaults to false)
>>> which if true sets up an isolated classloader for
>> the plugin allowing the plugin to use its own slf4j
>>
>> Stephen, this is _almost_ the same as I proposed a month ago.
But I'd
> do it the other way around as this would be perfectly backward
compatible.
>>
>> I'll try to explain again what I propose:
>>
>> Any plugin could e.g. use a @Slf4JLogger in it's mojo.
The
> plugin-plugin would transfer this to a
<useSlf4j>true</useSlf4j>
> inside the plugin.xml.
>> In this case, and _only_ in this case we would expose our
internal
SLF4J to
> the plugin.
>>
>>
>> Older plugins do not need it anyway as they do not use the
maven-provided
> slf4j yet!
>>
>>
>> This is a win-win solution imo:
>> * old integration and plugins will still work
>> * new plugins can use slf4j for logging via maven
>>
>>
>> Again the state of affairs of 3.1.0 today: old projects and
plugins
which
> didnt use slf4j so far don't get any benefit from forcing
slf4j on them.
And
> old projects and plugins which _did_ use slf4j already are now
broken
with the
> current trunk. I cannot see how we can seriously release this to
users
right
> now.
>>
>> LieGrue,
>> strub
>>
>>
>>> ________________________________
>>> From: Stephen Connolly
<stephen.alan.conno...@gmail.com>
>>> To: Maven Developers List <dev@maven.apache.org>;
Mark Struberg
> <strub...@yahoo.de>
>>> Sent: Friday, December 7, 2012 12:48 PM
>>> Subject: Re: [VOTE] Maven 3.1.0
>>>
>>>
>>> But not all of those *need to*. At least until now they
have needed
to,
> but going forward they may not need to if we are giving them an
slf4j
impl to
> hang their hat off.
>>>
>>>
>>> There will always be some special case plugins that have
a legitimate
> need to do funky logging stuff. We need a strategy for those
plugins.
>>>
>>>
>>> Jason's proposal for those cases was that they should
fork a JVM.
> That works if you don't need to channel objects back and
forth. For some
of
> the plugins wanting to do 'live development' style work (I
am thinking
> my jszip.org experiments - I have some plans and experiments that
I
haven't
> even pushed to there yet ;-) ) forking a JVM is a bad plan, as
you
then
have to
> basically resort to RMI to control the forked JVM... More ports
and more
sockets
> and more complexity.
>>>
>>>
>>> The next step I could see is building a fresh classloader
up from
> scratch within the plugin. That *should* work as long as we load
a
fresh
set of
> slf4j-api classes (ceki?) then we are initialising slf4j a second
time
in the
> fresh classloader and we can do as we need. Again complex though
one
could argue
> less complex than the RMI route. Plugin developers following this
route
will
> have to watch out for the dreaded CCE but at least you are not
having to
deal
> with object serialisation and RMI
>>>
>>>
>>> The final proposal that I see is where we give a metadata
flag
> (defaults to false) which if true sets up an isolated classloader
for
the plugin
> allowing the plugin to use its own slf4j
>>>
>>>
>>> Note that each proposal above retains the option for
plugin developers
> to use the previous proposal.
>>>
>>>
>>> My vote is that we need to provide a utility library that
makes the
> first and second proposals facile for plugin developers and we
should
probably
> enable the third option also.
>>>
>>>
>>> The correct respecting of tool chains support requires
plugin
> developers to follow the first route if a tool chain JVM is
applied to
their
> plugin and to use the second when no tool chain JVM is in play...
At
least for
> the jetty:run and tomcat:run style plugins.
>>>
>>>
>>> For the sonar style plugins, and my gut says the vast
majority of
these
> use cases the most they will need is the third proposal. Without
seeing a
> maven-fork-utils api I cannot say that we don't need the third
proposal,
so
> I am forced to conclude that we should support it... IOW I think
we need
a
> metadata flag.
>>>
>>>
>>> -Stephen
>>>
>>> On Friday, 7 December 2012, Mark Struberg wrote:
>>>
>>> basically all stuff which integrates maven does *funky
logging
> stuff*...
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Anders Hammar <and...@hammar.net>
>>>>> To: Maven Developers List
<dev@maven.apache.org>
>>>>> Cc:
>>>>> Sent: Friday, December 7, 2012 7:25 AM
>>>>> Subject: Re: [VOTE] Maven 3.1.0
>>>>>
>>>>>> I'm interested to help working on adding
a metadata to
> enable slf4j
>>>>>> visibility
>>>>>> from a plugin: by default, slf4j is not
visible, plugins
> are expected to
>>>>>> use
>>>>>> plugin-api's Log. But if the plugin
wants to use
> core's slf4j, he
>>>>> would be
>>>>>> able to add an annotation in the goal
requiring shared
> core slf4j, then the
>>>>>> plugin descriptor would enable slf4j api
import from core.
>>>>>>
>>>>>
>>>>> *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.
>>>>>
>>>>> /Anders
>>>>>
>>>>>
>>>>>>
>>>>>> Stephen: is this what you have in mind?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>> Le vendredi 30 novembre 2012 12:20:35
Stephen Connolly a
> écrit :
>>>>>> > I tend to agree. There are two
use-cases I see that a
> plugin has for
>>>>>> > bundling a logging implementation:
>>>>>> >
>>>>>> > 1. They are wanting to shunt the logs
from the build
> tool they are
>>>>>> invoking
>>>>>> > on to the user. Typically if they are
being good
> plugins they just
>>>>> take
>>>>>> the
>>>>>> > logging output and shunt it onto
> org.apache.maven.plugin.Log.info()
>>>>>> >
>>>>>> > 2. They are wanting to shunt the logs
from the build
> tool (or more
>>>>> likely
>>>>>> > app server) to a separate file, or
tweak the level of
> logs higher than
>>>>>> INFO
>>>>>> > for that app server/mojo execution as
it will just
> drown the user.
>>>>>> >
>>>>>> > In the first use case, Jason's
point is correct.
> They
>>>>> shouldn't need to
>>>>>> > bundle a logging implementation any
more.
>>>>>> >
>>>>>> > The second case, Jason is arguing that
they
> shouldn't be using the
>>>>> Maven
>>>>>> > JVM for running that tool, they should
be running it
> in a forked JVM
>>>>> and
>>>>>> > then they can configure the logging in
that JVM. I
> disagree. Forking a
>>>>>> JVM
>>>>>> > for every little build tool just to
control its
> logging is going to
>>>>> kill
>>>>>> > the build time.
>>>>>> >
>>>>>> > My preference is for a metadata flag
that says: Oy! I
> know what
>>>>> I'm doing
>>>>>> > with logging, so don't pass logging
on to me.
>>>>>> >
>>>>>> > While it feels like a "special
case" the
> truth is logging is
>>>>> always, and
>>>>>> > always will be, a special case!
>>>>>> >
>>>>>> > -Stephen
>>>>>> >
>>>>>> > On 30 November 2012 12:09, Benson
Margulies
>>>>> <bimargul...@gmail.com>
>>>>>> wrote:
>>>>>> > > On Thu, Nov 29, 2012 at 11:05 PM,
Jason van Zyl
>>>>> <ja...@tesla.io>
>>>>>> wrote:
>>>>>> > > > On Nov 29, 2012, at 5:56 PM,
Benson
> Margulies
>>>>> <bimargul...@gmail.com
>>>>>> >
>>>>>> > >
>>>>>> > > wrote:
>>>>>> > > >>> Currently I'm of
the mind that
> if you make a
>>>>> Maven plugin that uses
>>>>>> > >
>>>>>> > > something that employs SLF4J then
the best
> practice is to only
>>>>> use the
>>>>>> API
>>>>>> > > and let the host choose the
implementation, in
> our case Maven.
>>>>> Relying
>>>>>> on
>>>>>> > > SLF4J implementation specifics in
a system
> you're embedded in
>>>>> is not
>>>>>> good
>>>>>> > > e.g. Logback in Sonar running in
Maven using
> SLF4J Simple. If y
>>>
>>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
---------------------------------------------------------------------
> 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
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action:
<http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
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
