On Thu, Nov 1, 2012 at 5:56 PM, Jacob Kjome wrote:
>
> Isn't @since redundant for the first release?
Yes and no. Yes, it the first release under the new package structure for
the 2.0 classes. No, it's 2.0. Note that we will ship 1.2 packaged classes
for compatibility, so not everything would be
On Thu, Nov 1, 2012 at 10:56 PM, Jacob Kjome wrote:
>
> Isn't @since redundant for the first release? That is, it can be assumed
> that any class/method that doesn't have it is presumed to be @since 2.0.
> It's only after you start adding methods/classes in later releases that you
> bother to ex
Isn't @since redundant for the first release? That is, it can be assumed that
any class/method that doesn't have it is presumed to be @since 2.0. It's only
after you start adding methods/classes in later releases that you bother to
explicitly mention @since, referencing the release that the
Right. That's why I suggesting leaving Gump alone ATM.
Gary
On Nov 1, 2012, at 15:57, Ralph Goers wrote:
On Nov 1, 2012, at 12:37 PM, Christian Grobmeier wrote:
On Thu, Nov 1, 2012 at 5:55 PM, Ralph Goers wrote:
> We have a periodic build in Gump that was set up by Curt ages ago. The
> outpu
[
https://issues.apache.org/jira/browse/LOG4J2-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488978#comment-13488978
]
Ralph Goers commented on LOG4J2-106:
I checked in a fix last night but I have some mor
On Nov 1, 2012, at 12:37 PM, Christian Grobmeier wrote:
> On Thu, Nov 1, 2012 at 5:55 PM, Ralph Goers
> wrote:
> We have a periodic build in Gump that was set up by Curt ages ago. The output
> routes to me. It has been failing for at least a week now because it uses the
> maven-pdf-plugin but
On Thu, Nov 1, 2012 at 5:55 PM, Ralph Goers wrote:
> We have a periodic build in Gump that was set up by Curt ages ago. The
> output routes to me. It has been failing for at least a week now because it
> uses the maven-pdf-plugin but has to use a SNAPSHOT version as the latest
> release doesn't wo
[
https://issues.apache.org/jira/browse/LOG4J2-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488944#comment-13488944
]
Anand Awasthi commented on LOG4J2-106:
--
any update on this. BTW, which constructor ar
Done.
On Thu, Nov 1, 2012 at 2:03 PM, Ralph Goers wrote:
> If it is the same as default then yes.
>
> Ralph
>
> On Nov 1, 2012, at 10:52 AM, Gary Gregory wrote:
>
> OK, right now I have 3 styles predefined: Default, Log4J, and Logback.
> Should I get rid of Log4J?
>
> Gary
>
> On Thu, Nov 1, 2012
Works for me. I just wanted to make sure that SLF4j's naming pattern was
considered and explicitly rejected rather than simply overlooked.
Jake
On Thu, 1 Nov 2012 13:07:51 -0400
Gary Gregory wrote:
On Thu, Nov 1, 2012 at 12:41 PM, Ralph Goers
wrote:
I think Gary's point was that naming
If it is the same as default then yes.
Ralph
On Nov 1, 2012, at 10:52 AM, Gary Gregory wrote:
> OK, right now I have 3 styles predefined: Default, Log4J, and Logback. Should
> I get rid of Log4J?
>
> Gary
>
> On Thu, Nov 1, 2012 at 1:20 PM, Ralph Goers
> wrote:
> Default is probably better.
I thought I had documented the Jenkins build but I will double check.
Ralph
On Nov 1, 2012, at 10:51 AM, Gary Gregory wrote:
> I'd leave Gump alone and make a note of it on the site with a pointer to the
> Jenkins build. That should go in a developer section.
>
> Gary
>
> On Thu, Nov 1, 2012
OK, right now I have 3 styles predefined: Default, Log4J, and Logback.
Should I get rid of Log4J?
Gary
On Thu, Nov 1, 2012 at 1:20 PM, Ralph Goers wrote:
> Default is probably better.
>
> Ralph
>
> On Nov 1, 2012, at 10:08 AM, Gary Gregory wrote:
>
> I was going to have "STYLE=Default" but we ca
I'd leave Gump alone and make a note of it on the site with a pointer to
the Jenkins build. That should go in a developer section.
Gary
On Thu, Nov 1, 2012 at 12:55 PM, Ralph Goers wrote:
> We have a periodic build in Gump that was set up by Curt ages ago. The
> output routes to me. It has been
Default is probably better.
Ralph
On Nov 1, 2012, at 10:08 AM, Gary Gregory wrote:
> I was going to have "STYLE=Default" but we can also have "STYLE=Log4J"
>
> Gary
>
> On Thu, Nov 1, 2012 at 12:44 PM, Ralph Goers
> wrote:
> I suppose STYLE=Log4j would be the default.
>
> I'm not sure I kno
I was going to have "STYLE=Default" but we can also have "STYLE=Log4J"
Gary
On Thu, Nov 1, 2012 at 12:44 PM, Ralph Goers wrote:
> I suppose STYLE=Log4j would be the default.
>
> I'm not sure I know of any others but it leaves room for users to request
> them.
>
> Ralph
>
>
>
> On Nov 1, 2012, at
On Thu, Nov 1, 2012 at 12:41 PM, Ralph Goers wrote:
> I think Gary's point was that naming everything as log4j-* is more
> consistent. But yes, SLF4J's scheme is more about being descriptive. SLF4J
> includes slf4j-log4j12.jar (BTW - I really like the picture at
> http://www.slf4j.org/legacy.htm
On Thu, Nov 1, 2012 at 11:41 AM, Ralph Goers wrote:
> I think Gary's point was that naming everything as log4j-* is more
> consistent. But yes, SLF4J's scheme is more about being descriptive. SLF4J
> includes slf4j-log4j12.jar (BTW - I really like the picture at
> http://www.slf4j.org/legacy.htm
We have a periodic build in Gump that was set up by Curt ages ago. The output
routes to me. It has been failing for at least a week now because it uses the
maven-pdf-plugin but has to use a SNAPSHOT version as the latest release
doesn't work with Maven 3. This plugin is used to create a PDF of t
I suppose STYLE=Log4j would be the default.
I'm not sure I know of any others but it leaves room for users to request them.
Ralph
On Nov 1, 2012, at 9:23 AM, Gary Gregory wrote:
> On Thu, Nov 1, 2012 at 12:11 PM, Ralph Goers
> wrote:
> Yes. I also like the idea of STYLE= with a few optio
I think Gary's point was that naming everything as log4j-* is more consistent.
But yes, SLF4J's scheme is more about being descriptive. SLF4J includes
slf4j-log4j12.jar (BTW - I really like the picture at
http://www.slf4j.org/legacy.html - we need to create something like it). I'm
afraid if
On Thu, Nov 1, 2012 at 12:11 PM, Ralph Goers wrote:
> Yes. I also like the idea of STYLE= with a few options just to save
> typing.
>
Options:
- Logback
- What else?
>
> If you haven't done it don't forget to update the web site documentation.
>
Will do...
Gary
>
> Ralph
>
>
>
>
OK, cool. In SVN now. I actually just fixed an NPE and inadvertently
committed the new default colors along with it:
http://picpaste.com/pics/default.1351786814.png
I'll look into STYLE=Logback" next...
Gary
On Thu, Nov 1, 2012 at 11:56 AM, Paul Benedict wrote:
> I think your latest suggestion
"log4j-slf4j" or "slf4j-log4j"? Or, maybe more consistently, "slf4j-log4j2"?
The SLF4j binding for Log4j-1.2.x is "slf4j-log4j12". Seems like the SLF4j
project has defined the naming scheme already. I'm not sure I see a point in
straying from it? Or am I missing something?
Jake
On Thu,
Yes. I also like the idea of STYLE= with a few options just to save typing.
If you haven't done it don't forget to update the web site documentation.
Ralph
On Nov 1, 2012, at 8:56 AM, Paul Benedict wrote:
> I think your latest suggestion is perfectly alright. I would just prefer WARN
> to
After this discussion I think I am inclined to agree. Based on that I think I
will just remove it.
Gary does have a valid point about the jar names, although we could probably
argue about them all day. The only one that really bothers me is slf4j-impl.
I guess I would prefer log4j-slf4j. I
I think your latest suggestion is perfectly alright. I would just prefer
WARN to be yellow to meet the traffic light metaphor. Otherwise, I see
where you're going and agree.
Paul
On Thu, Nov 1, 2012 at 10:51 AM, Gary Gregory wrote:
> On Thu, Nov 1, 2012 at 9:54 AM, Paul Benedict wrote:
>
>> fata
On Thu, Nov 1, 2012 at 9:54 AM, Paul Benedict wrote:
> fatal: magenta (or red)
> error: red (or magenta)
> warning: info
> info: green
> debug: cyan
> trace: black (which is really dark gray)
>
> I think INFO, which is the standard logging level, should just be white.
>
> I also think DEBUG and T
I see your point. I was confused at first, thinking you guys wanted an
everything-in-one jar, but all you were talking about was api + core. My
apologies. I am not in favor of the combined jar. I the name is confusing
and don't see much benefit. I personally would rather keep the 2 artifacts
separa
api and core are still (and would be) separate components in SVN, javadocs and
other documentation on the site. All I proposed doing was also delivering a jar
that merges the two. FWIW, API has no dependencies. Core only has optional
dependencies. So the combined jar isn't much different from
See below.
On Nov 1, 2012, at 8:02 AM, Gary Gregory wrote:
>
>
> On Thu, Nov 1, 2012 at 10:07 AM, Ralph Goers wrote:
> OK. The current combined jar only includes API and core and has no required
> dependencies that are different than core. I am imagining that many will
> prefer to use this s
The nice thing about keeping api divided from core is simply design. There
may be no reason to keep this split unless we can always ensure core will
not require more dependencies. It might be safer to keep them divided.
I am not too fond of the "impl" but would rather see "adapter" since that's
re
Well, actually if you don't have any "real" implementation the API has
something equivalent to the simple logger in Commons Logging. It isn't too
useful. Core provides the "real" Log4j 2 implementation. User's code against
the classes in the API jar but also need the core jar to run. The "com
On Thu, Nov 1, 2012 at 10:07 AM, Ralph Goers wrote:
> OK. The current combined jar only includes API and core and has no
> required dependencies that are different than core. I am imagining that
> many will prefer to use this single jar instead of having to include both
> the API and core jars.
Correct me if wrong, but doesn't "core" provide the default logging
implementation?
On Thu, Nov 1, 2012 at 9:07 AM, Ralph Goers wrote:
> OK. The current combined jar only includes API and core and has no
> required dependencies that are different than core. I am imagining that
> many will prefer
I'm color blind so my opinion doesn't count for much! But I am ok with what
you are proposing. The current colors were chosen to match what Logback does.
Ralph
On Nov 1, 2012, at 6:48 AM, Gary Gregory wrote:
> OK, we/I need to tweak the highlighter's default colors because for me, on
> Wind
OK. The current combined jar only includes API and core and has no required
dependencies that are different than core. I am imagining that many will prefer
to use this single jar instead of having to include both the API and core jars.
What is your opinion on that and if positive, what would yo
fatal: magenta (or red)
error: red (or magenta)
warning: info
info: green
debug: cyan
trace: black (which is really dark gray)
I think INFO, which is the standard logging level, should just be white.
I also think DEBUG and TRACE should share the same color. Perhaps like a
pale light purple that d
I may have misunderstood, but I'll give it another shot!
I don't like combined jars. It's because there's too many dependencies
associated with them. It makes the POM kind of worthless because any
extensions are all true ... so you have to go manually
add those to your Maven project anyway to get
OK, we/I need to tweak the highlighter's default colors because for me, on
Windows 7, the default colors are not good (bold does not seem to do
anything):
fatal: red
error: red
warning: red
info: dark blue
debug: default
trace: default
I propose that each level have its own color.
How about:
fa
I prefer all.jar or ApiAndCore.jar
Even if OSes accept special characters there will always be closed
systems that do not. Exampple hyphen is okay in a domain name but one of
the visa test pit's don't like them
-
To unsubscrib
Am 01.11.2012 um 13:03 schrieb Gary Gregory:
> On Nov 1, 2012, at 2:13, Ralph Goers wrote:
>
>> ...
>>
>> I'n not crazy about log4j-api+core.jar just because the + seems odd,
>> although it does make sense. Is the "+" allowed in a file name on all
>> relevant platforms?
>
> It's OK on Windo
Am 01.11.2012 um 13:03 schrieb Gary Gregory:
> On Nov 1, 2012, at 2:13, Ralph Goers wrote:
>
>> ...
>>
>> I'n not crazy about log4j-api+core.jar just because the + seems odd,
>> although it does make sense. Is the "+" allowed in a file name on all
>> relevant platforms?
>
> It's OK on Windo
Great. Thanks for the pointers.
Gary
On Nov 1, 2012, at 2:23, Ralph Goers wrote:
The coloring isn't done by the layout but by the StylePatternConverter and
the HighlightPatternConverter. Rather than creating a new converter you can
simply enhance the HighlightPatternConverter to accept the styl
On Nov 1, 2012, at 2:13, Ralph Goers wrote:
So you guys want all these jars in a -all jar? I created the -combined jar
because of a couple of emails I got where it was clear the users wanted to
use the api and core together and didn't want the flexibility to separate
them. Including all the bri
45 matches
Mail list logo