Ron, Mirko, Kevin,
Thanks for your feedback : you're right with Slf4j implementation.
Unfortunately, it is not. It is a home made logger interface implemented by
Log4j.
Benoît
> Le 12 févr. 2014 à 23:25, Ron Wheeler a
> écrit :
>
>
>
> Not really a Maven issue but if you do your logging l
On 13 February 2014 02:24, Ron Wheeler wrote:
> I did a debug run and I think that the log shows where the includes get
> webapps
>
> tar
>
>false
>
>
> /target
> false
> false
> runtime
>
>
> com.artifact-software.taw:taw-localized-ium
Not really a Maven issue but if you do your logging like this:
package com.myco.testapp;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass{
private Logger
_logger=LoggerFactory.getLogger(this.getClass());
logger.debug(“blah {} in the loop that c
Hi,
What do you mean by "it cannot find" ?
You can't see it in the list of archetype when you create a new maven
project (via m2e) ? On my desktop it require few seconds to retrieve the
list of archetypes from "Default Catalogs"
m2e - Maven Integration for Eclipse1.4.0.20130601-0317
org.ecl
Hello Benoit,
Kevin is right, using slf4j[0] one would use sth. like:
logger.debug(“blah {} in the loop that contains {}”, i, max);
No need for iffing :-).
[0] http://www.slf4j.org/manual.html
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://
With the pictures attached
De : Benoît Berthonneau [mailto:ben...@berthonneau.com]
Envoyé : mercredi 12 février 2014 21:57
À : 'Maven Users List'
Objet : RE: Code coverage with debug logs: 100% branch coverage not
possible?...
Hi Paul,
Don't think that I could play with exclusions.
It does matter which implementation. The main reason it was recommended to
check the logging level was because string concatenation can be expensive,
and you want to avoid doing it for a message that won't be logged. But if
you're using a logging API like slf4j that uses parameter replacement
tok
Hi Reto,
I understood your point of view but to me the problem I'm talking about
could be "easily" solved for a better branch coverage and know what is the
real missed branches report.
Benoît.
-Message d'origine-
De : Reto Hablützel [mailto:ret...@rethab.ch]
Envoyé : mercredi 12 févrie
Hi Paul,
Don't think that I could play with exclusions. Here is an example :
A Unit Test :
The tested class with ALL traces activated:
And the same tested class with INFO traces activated:
-Message d'origine-
De : paulus.benedic...@gmail.com [mailto:paulus.bened
To follow up on Paul's answer, I would go as far as to say that I test my
code in order to feel comfortable that it actually does what it should do.
Thus, I can very well live with 90% coverage if I know what the missing 10%
are rather than testing for the sake of making a good impression with a
10
IIRC, there should be an option in Emma/Cobertura that allows you to
exclude coverage on certain classes. So if you can exclude your log4j
classes (you don't really want to test your logging, do you?), then you
should be able to raise your percentage.
On Wed, Feb 12, 2014 at 2:30 PM, Benoît Berth
Hi all,
I need your opinion/way to tackle the following problem:
In many projects we use a Logger (doesnt matter which implementation). It
is often recommend to test if the debug level is activated before logging a
debug trace like the following:
if (logger.isDebugEnabled()) {
logger.de
Thanks for the help.
Here are more details from the pom and assembly.
I did a debug run and I think that the log shows where the includes get
excluded
[DEBUG] com.artifact_software.taw:taw-localized-uimessage-ws:war:1.0.2
was removed by one or more filters.
[DEBUG] com.artifact_software.taw:t
On 12 February 2014 20:12, Adrien Rivard wrote:
> Hi,
>
> DependencyManagement is declaring dependencies(mostly for versions) and
> dependencies is using them,
> So in general you should have only dependencyManagement in the parent poms
> and only dependencies in the childs.
>
> Now there are exce
On 13 February 2014 00:20, Mark H. Wood wrote:
> On Wed, Feb 12, 2014 at 08:11:29AM +1030, Barrie Treloar wrote:
> [snip]
>> I think Maven is missing a scope, it needs to break up test into two
>> phases; testCompile and testRuntime instead of having one scope which
>> means both.
[del]
> Picky te
>> >From
>> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
>> I think the shortened form assumes a "jar" classifier.
>> I'm guessing from your assembly name "webapps-tar.xml" that these might be
>> wars?
>> Have you tried using the long
On Wed, Feb 12, 2014 at 08:11:29AM +1030, Barrie Treloar wrote:
[snip]
> I think Maven is missing a scope, it needs to break up test into two
> phases; testCompile and testRuntime instead of having one scope which
> means both.
> This means that the analyze code can't tell what stuff is needed for
Hi,
DependencyManagement is declaring dependencies(mostly for versions) and
dependencies is using them,
So in general you should have only dependencyManagement in the parent poms
and only dependencies in the childs.
Now there are exceptions, for example junit is generally used in all child
projec
Laird, Barrie
Thanks for taking the time with some useful explanations
I'd like to put more detail into my problem in the hope that you may be able
to spot something I am doing wrong:
I started off with parent and child poms with no dependency management -
along the lines of:
Parent pom (without
On 11/02/2014 9:06 PM, Barrie Treloar wrote:
On 12 February 2014 11:43, Ron Wheeler wrote:
I am trying to build a timesaving module that will build tar files to be
installed on a server
I have defined a bunch of dependencies in the pom and want to build 2 tar
files by invoking 2 instances of th
20 matches
Mail list logo
