Re: Get thee to the Core...
We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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
Re: [VOTE] Release Maven Plugin Tools Version 2.8
+1 2011/6/9 Stephen Connolly stephen.alan.conno...@gmail.com: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=17146 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=1 Staging repo: https://repository.apache.org/content/repositories/maven-059/ Staging sites: http://maven.apache.org/plugin-tools-2.8/ http://maven.apache.org/plugins/plugins/maven-plugin-plugin/ (staging of that one is a tad borked!) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Plugin Tools Version 2.8
+1 -Lukas Stephen Connolly wrote: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=17146 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=1 Staging repo: https://repository.apache.org/content/repositories/maven-059/ Staging sites: http://maven.apache.org/plugin-tools-2.8/ http://maven.apache.org/plugins/plugins/maven-plugin-plugin/ (staging of that one is a tad borked!) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
Re: [VOTE] Release Maven Indexer version 4.1.1
+1 (non-binding) On Thu, Jun 9, 2011 at 5:49 PM, Jesse Glick jesse.gl...@oracle.com wrote: Non-binding +1; no apparent problems in NetBeans integration during basic interactive tests. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.1.1
+1 (binding) LieGrue, strub --- On Fri, 6/10/11, Brian Demers brian.dem...@gmail.com wrote: From: Brian Demers brian.dem...@gmail.com Subject: Re: [VOTE] Release Maven Indexer version 4.1.1 To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 1:44 PM +1 (non-binding) On Thu, Jun 9, 2011 at 5:49 PM, Jesse Glick jesse.gl...@oracle.com wrote: Non-binding +1; no apparent problems in NetBeans integration during basic interactive tests. - 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
Re: Get thee to the Core...
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests, etc.
But moving the whole Logger mess over to slf4j would be really great. There are
lots of tests (I sadly also found productive code too) still using
System.out.println.
The question is if we (internally) drop org.codehaus.plexus.logging.Logger
completely and use slf4j directly, or if we pimp up the plexus Logger and add
various stuff.
I've been thinking about this for some time now, actually. If you look
at the MAE stuff in the sandbox, I'm pretty sure that's using log4j
directly.
Personally, I don't understand what value the Plexus
logger/loggermanager has, especially given the configurability of these
other logging frameworks.
I'd be in favor of providing a default logging configuration file in
either the Maven app directory or in ~/.m2, and then letting people
customize from the command line to highlight specific components/packages.
Although, having said that, one of my pet peeves about the logging
frameworks is they haven't shifted to using String.format,
MessageFormat.format, or whatever under-the-covers as a way of limiting
string concatenation in cases where a particular log level has been
disabled.
Even something as simple as the attached code would be a nice facade for
logging, IMO...but it's more of a wish-list item than anything else.
In short, yes, let's think about switching to a better logging
framework. We can deprecate the plexus logger, and eventually get rid of it!
We would need to do some compat code anyway, but I'm not sure if it pays off to
restrict ourself. At least not after I saw that even the LoggerManager uses
System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' + key + ' + hashCode() +
. );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the
difficulty of
understanding, in some cases, why it does what it
does.
This suggests to me three efforts that might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component (indeed
class) by component
log control as an alternative to the giant -X spew.
Now that is an interesting idea. For the past year I have
been working on creating Log4j 2.0 pretty much by
myself. This would be a great way to integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
/*
* Copyright 2011 Red Hat, Inc.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.commonjava.util.logging;
import org.slf4j.LoggerFactory;
import java.text.MessageFormat;
import java.util.IllegalFormatException;
public final class Logger
{
private final org.slf4j.Logger logger;
public Logger( Class? clazz )
{
logger = LoggerFactory.getLogger( clazz );
}
public Logger( String name )
{
logger = LoggerFactory.getLogger( name );
}
public Logger( org.slf4j.Logger logger )
{
this.logger = logger;
}
public org.slf4j.Logger getLogger()
{
return logger;
}
public Logger debug( String format, Object...params )
{
if ( logger.isDebugEnabled() )
{
logger.debug( format( format, params ) );
}
return this;
}
public Logger debug( String format, Throwable error, Object...params )
{
if ( logger.isDebugEnabled() )
{
logger.debug( format( format, params ), error );
}
return this;
}
public Logger error( String format, Object...params )
{
if ( logger.isErrorEnabled() )
{
Re: Get thee to the Core...
personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: Get thee to the Core...
lest anyone think I'm doing NIH, the logging frameworks I have implemented myself (they were under commercial license for previous employer) were less than perfect, but having seen my mistakes I think I have a better handle on the right path to take! On 10 June 2011 16:42, Stephen Connolly stephen.alan.conno...@gmail.com wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: Get thee to the Core...
On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
the problem is: logging gets tricky once you have OSGIi or ThreadContextClassLoaders in place... So I'd favour slf4j. We don't need a 'perfect' solution - we just need something better than we had in place ;) LieGrue, strub --- On Fri, 6/10/11, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 3:46 PM On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - 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
Re: [VOTE] Release Maven Indexer version 4.1.1
+1 2011/6/9 Tamás Cservenák ta...@cservenak.net: Hi, Current 4.1.1 version is mostly bugfix release for latest 4.0.1 improving indexer robustness, lessen unnecessary IO burden and smaller POM fixes regarding site publishing. no staged one ? you will publish it after the release ? We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17410 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MINDEXER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-060/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.1.1
+1 Damian
Julia Antonova/Tumlare is out of office.
I will be out of the office starting 10.06.2011 and will not return until 14.06.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you!
Re: Julia Antonova/Tumlare is out of office.
can somebody update the wiki, I'm only on a phone - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jun 2011 20:44, Julia Antonova juli...@jtbrussia.com wrote: I will be out of the office starting 10.06.2011 and will not return until 14.06.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you!
Re: Julia Antonova/Tumlare is out of office.
God I love this meme. On Fri, Jun 10, 2011 at 4:56 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: can somebody update the wiki, I'm only on a phone - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jun 2011 20:44, Julia Antonova juli...@jtbrussia.com wrote: I will be out of the office starting 10.06.2011 and will not return until 14.06.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you!
Re: Get thee to the Core...
HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was All good things to discuss on the dev list :). -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Best regards, Evgeny Mandrikov aka Godin http://godin.net.ru http://twitter.com/_godin_ http://www.SonarSource.com http://www.sonarsource.com/
Re: Get thee to the Core...
On 2011-06-09 23:45, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. I'm game for working on changing the logging implementation. Having spent some time patching commons-logging, and releasing version 1.1.1, I know my way around logging code. 2: get the dependency plugin caught up with the core. 3: think of more help: goals that answers questions that people have. One really useful exercise would be to mine the user list for recurring themes. On Thu, Jun 9, 2011 at 5:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven
Re: Julia Antonova/Tumlare is out of office.
On Sat, Jun 11, 2011 at 6:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: can somebody update the wiki, I'm only on a phone Updated. One day I will calculate the proper holidays instead of elapsed calendars days. It's a bit unfair to be jealous of inflated numbers because they included weekends. But I'm still jealous. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
I'm not sure what you are after John. Logback provides a formatter where you
can do
logger.debug(Hello, {}, John) and it will replace the curly braces with
John. My Log4J 2.0 will do the same thing. MessageFormat is fairly slow,
but if you wanted to use that instead my Log4J 2.0 implementation will allow
you to create a new Class that implements the Message interface and use that if
you want.
Ralph
On Jun 10, 2011, at 8:28 AM, John Casey wrote:
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests, etc.
But moving the whole Logger mess over to slf4j would be really great. There
are lots of tests (I sadly also found productive code too) still using
System.out.println.
The question is if we (internally) drop org.codehaus.plexus.logging.Logger
completely and use slf4j directly, or if we pimp up the plexus Logger and
add various stuff.
I've been thinking about this for some time now, actually. If you look at the
MAE stuff in the sandbox, I'm pretty sure that's using log4j directly.
Personally, I don't understand what value the Plexus logger/loggermanager
has, especially given the configurability of these other logging frameworks.
I'd be in favor of providing a default logging configuration file in either
the Maven app directory or in ~/.m2, and then letting people customize from
the command line to highlight specific components/packages.
Although, having said that, one of my pet peeves about the logging frameworks
is they haven't shifted to using String.format, MessageFormat.format, or
whatever under-the-covers as a way of limiting string concatenation in cases
where a particular log level has been disabled.
Even something as simple as the attached code would be a nice facade for
logging, IMO...but it's more of a wish-list item than anything else.
In short, yes, let's think about switching to a better logging framework. We
can deprecate the plexus logger, and eventually get rid of it!
We would need to do some compat code anyway, but I'm not sure if it pays off
to restrict ourself. At least not after I saw that even the LoggerManager
uses System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' + key + ' + hashCode() +
. );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the
difficulty of
understanding, in some cases, why it does what it
does.
This suggests to me three efforts that might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component (indeed
class) by component
log control as an alternative to the giant -X spew.
Now that is an interesting idea. For the past year I have
been working on creating Log4j 2.0 pretty much by
myself. This would be a great way to integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
Logger.java
-
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
Re: Get thee to the Core...
Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: Get thee to the Core...
SLF4J isn't a logging framework. It is an API. While Logback is much better than Log4J 1.x it still has significant architectural problems. Ralph On Jun 10, 2011, at 9:20 AM, Mark Struberg wrote: the problem is: logging gets tricky once you have OSGIi or ThreadContextClassLoaders in place... So I'd favour slf4j. We don't need a 'perfect' solution - we just need something better than we had in place ;) LieGrue, strub --- On Fri, 6/10/11, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 3:46 PM On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - 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
Re: Get thee to the Core...
Well, I could use feedback on https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jun 10, 2011, at 8:43 AM, Stephen Connolly wrote: lest anyone think I'm doing NIH, the logging frameworks I have implemented myself (they were under commercial license for previous employer) were less than perfect, but having seen my mistakes I think I have a better handle on the right path to take! On 10 June 2011 16:42, Stephen Connolly stephen.alan.conno...@gmail.com wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
