On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY wrote:
> trying to be concise and neutral
>
> 1. because slf4j-api is well known, it has lots of back-ends, that will
> provide powerfull configuration techniques for filtering, display, recording
> and
> so on Maven output: precise use case still n
On Dec 10, 2012, at 2:05 AM, Hervé BOUTEMY wrote:
> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>> for the embedding problem, but we're likely to run into issues concurrency
>> with parallel builds and
trying to be concise and neutral
1. because slf4j-api is well known, it has lots of back-ends, that will
provide powerfull configuration techniques for filtering, display, recording
and
so on Maven output: precise use case still need to be described
2. the discussion is not much about the api
Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
> for the embedding problem, but we're likely to run into issues concurrency
> with parallel builds and who knows what else. This will patch/change #5 and
> many
I am leaving for a tropical Island this friday and was hoping to get
the release process started before I left, so I could count votes
while wiggeling my toes in the hot sand.
Looks like it's going to be a 3-pack release of m-s-u, verifier and surefire...
Kristian
Den 10. des. 2012 kl. 02:36 skr
I got lost (in other work) and this thread a long time ago.
Can someone please remind me just why we are changing the logging at all?
-Chris
On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> 2012/12/9 Olivier Lamy :
> > Perso I'm fine using log4j2.
> >
I think it's time to stop patching SLF4J Simple. I have an inefficient fix for
the embedding problem, but we're likely to run into issues concurrency with
parallel builds and who knows what else. This will patch/change #5 and many
hours of trying to get SLF4J Simple to work but I think we're pus
Any idea when this will get released?
11 issues fixed.
--jason
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On Sun, Dec 9, 2012 at 6:51 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>
> > 2012/12/9 Olivier Lamy >:
> > > Perso I'm fine using log4j2.
> > > I use the branch I pushed for some weeks now and I'm happy.
> > > Log4j2 has q
I'm a little bit lost too.
Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
many - good - reasons) but the last bug discovered by Kristian can be
solved only
* by having a fix from slf4j (but it isn't sure that the patch makes sense
- to be validated by Ceki)
* or by usin
Anders,
My take is that this will be the 5th change that I've asked for to get the
SLF4J Simple implementation to work. Initially I had your position and I tried
to keep it as simple as possible the provide the same behaviour, but for
embedded environments and concurrent operations I think we'r
On Dec 9, 2012, at 5:06 PM, Hervé BOUTEMY wrote:
> I just committed a starting point for MNG-5406: "don't expose core's
> slf4j-api
> by default, add a plugin-descriptor option to expose"
>
> this is a new field in plugin descriptor.
>
> I still don't know how to effectively use it in
> Def
Fwiw, once maven anoints a logging framework, it will be near
impossible to switch. IMO that is.
Gary
On Dec 9, 2012, at 16:54, Anders Hammar wrote:
> Not sure where to get into this thread, but I'd just like to add my
> perspective on this topic.
>
> For this first release I would prefer it to
GitHub user agudian opened a pull request:
https://github.com/apache/maven-surefire/pull/14
[SUREFIRE-934] remove getLocatedClasses() and size() from TestsToRun
.. to avoid potential programming errors with forkMode=onceperthread
You can merge this pull request into a Git repositor
Mirko;
Most of the time the core IT's fail, it seems to be related to stuff
in your local settings.xml. Maybe try to just rename it and see how
that works.
Sometimes the artifact resolution gets stuck
less core-it-suite/target/test-classes/mng-5135/log.txt
will show you what happened to the buil
I just committed a starting point for MNG-5406: "don't expose core's slf4j-api
by default, add a plugin-descriptor option to expose"
this is a new field in plugin descriptor.
I still don't know how to effectively use it in
DefaultClassRealmManager.createPluginRealm() to avoid importing slf4j-ap
Am 12/09/12 22:58, schrieb Kristian Rosenvold:
>
> Anyone else have any ideas about eviction strategies ?
>
Without having looked at the code. GC driven by using soft references.
--
Christian
-
To unsubscribe, e-mail: dev-un
Now that 3.1 works with embedded mode again I have found an
/interesting/ performance regression;
In this commit
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=451c43152b8939a699dfa5db4fc4ca8676182462
the plugin realm cache is purged after each embedded build. While this
obviously
Not sure where to get into this thread, but I'd just like to add my
perspective on this topic.
For this first release I would prefer it to not include any of the more
advanced slf4j implementations, like a few others have already also stated.
Using simple would give us a good start on this new pat
yes we discussed about it.
That one reason why we should not activate it by default.
We'll never find a solution that will satisfy everybody
On Sun, Dec 9, 2012 at 2:25 PM, Robert Scholte wrote:
> I've tested this on Windows, there's only one small issue: the info-text
> is probably black, whic
Just tested it.
It's working fine
Thx a lot.
On Sun, Dec 9, 2012 at 4:38 AM, Jason van Zyl wrote:
> Arnaud,
>
> It's all in there now. While I was fixing the logging in embedded mode for
> SLF4J Simple, I updated the Logback branch to do the same.
>
> I had to patch SLF4J Simple to get around s
Yet another example of why overriding the default finalName is a bad idea.
/Anders
On Sun, Dec 9, 2012 at 7:56 PM, Robert Scholte wrote:
> sounds good enough for me.
> this is a clear example why you can generate a release-pom.xml
> I'll see if I will add a check when generating this file.
>
>
sounds good enough for me.
this is a clear example why you can generate a release-pom.xml
I'll see if I will add a check when generating this file.
I don't have the rights to change maven-3x-compatibility-notes page.
Could someone give me the required rights for editing or could somebody
descr
On Dec 9, 2012, at 10:37 AM, Olivier Lamy wrote:
> It looks others don't want modern stuff.
> So not a problem. During my life I have used ed, vi then vim or emacs
> now an IDE.
> Those last ones make me see "la vie en rose" with some colors.
> BTW I still like vi maybe Keep It So Simple pattern
I don't think it was intentional, i don't remember anyone specifically
mentioning it and probably is an inadvertent side affect of another change. I
imagine if we went digging we would fine more behavioural inconsistencies. This
is the behaviour that's present now in 3.0 so I would say it's prob
I've tried it with Maven-3.0, and this version also let finalName to be
inherited.
In JIRA I can't find an issue related to the change of this behavior.
The compatibility-notes for M3[1] doesn't mention it either.
Robert
[1] https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html
O
Color != modern logging API :p...
Le 9 déc. 2012 16:37, "Olivier Lamy" a écrit :
> It looks others don't want modern stuff.
> So not a problem. During my life I have used ed, vi then vim or emacs
> now an IDE.
> Those last ones make me see "la vie en rose" with some colors.
> BTW I still like vi
It looks others don't want modern stuff.
So not a problem. During my life I have used ed, vi then vim or emacs
now an IDE.
Those last ones make me see "la vie en rose" with some colors.
BTW I still like vi maybe Keep It So Simple pattern or I'm too old for
too much modern stuff :-)
Regarding "imma
Hi guys,
Simple, log4j, logback...nobody cares about jdk? It is far better than
simple and enough by default avoiding log4j/logback issue...then the
question would rather be why slf4j since JUL is enough and can be the API
as in cxf, owb etc...
Le 9 déc. 2012 16:18, "Jason van Zyl" a écrit :
> I
Are you referring to the Simple SLF4J fix or the Logback branch?
I have only run it locally as the CI instance looks borked at the moment?
On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold
wrote:
> 2012/12/9 Olivier Lamy :
>> Perso I'm fine using log4j2.
>> I use the branch I pushed for some week
I agree. I don't believe it's reasonable path to pick an immature library for
the core given the existence of Logback.
Arnaud, I believe you felt the same way?
I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it do
more than originally intended but I don't think it makes
I haven't looked at concurrency per se, but I see the IT for the event spy in
parallel mode so if that doesn't account for it then it's not something I
specifically checked. This is probably where the simple implementation would
likely not be adequate.
If you know off hand the ITs that are conc
Can you easily tell in which version of Maven the behaviour changed?
I don't think inheriting this value is a bad per se, and if it's been like this
in all versions of Maven 3.x I think it's probably ok. If the behaviour
changed somewhere along the path of 3.x then that's probably not great.
O
and MRELEASE-719 too.
ATM I don't have time to work on that.
2012/12/9 Olivier Lamy :
> Great.
> You can move MRELEASE-682 to an other fixversion.
>
> 2012/12/9 Robert Scholte :
>> Hi,
>>
>> I'd like to prepare a release of the maven-release-plugin 2.4 soon.
>> Most important changes have to do wi
Great.
You can move MRELEASE-682 to an other fixversion.
2012/12/9 Robert Scholte :
> Hi,
>
> I'd like to prepare a release of the maven-release-plugin 2.4 soon.
> Most important changes have to do with profiles.
> For Maven2 there's no change, but for Maven3 we can use the
> MavenExecutionRequest
ANSI can set the BG color...
Gary
On Dec 9, 2012, at 8:25, Robert Scholte wrote:
> I've tested this on Windows, there's only one small issue: the info-text is
> probably black, which makes it unreadable on the default background-color,
> which is black as well.
> The rest looks great!
>
> Op
I've tested this on Windows, there's only one small issue: the info-text
is probably black, which makes it unreadable on the default
background-color, which is black as well.
The rest looks great!
Op Mon, 03 Dec 2012 14:47:24 +0100 schreef Olivier Lamy :
2012/12/3 Marc Pasteur :
hi,
For
On Sunday, 9 December 2012, Kristian Rosenvold wrote:
> 2012/12/9 Olivier Lamy >:
> > Perso I'm fine using log4j2.
> > I use the branch I pushed for some weeks now and I'm happy.
> > Log4j2 has quickly added a feature I needed and release it.
> > Furthermore I'm fine working with an Apache communi
Github user agudian closed the pull request at:
https://github.com/apache/maven-surefire/pull/13
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Hi,
it looks like the behavior of the project.build.finalName has changed in a
multimodule-project.
With Maven-2.2.1 it is always ${project.artifactId}-${project.version} if
you don't specify it.
In Maven-3.0.4 its value is inherited from the parent.
I'd expect that the old behavior is th
I'm testing the fix now. BY reading code it would seem like this fix
does eradicate any options for running parallel invocations with
embedded instances ?
Kristian
2012/12/9 Jason van Zyl :
> Hi,
>
> I sorted out the ITs running in embedded mode and here's what I came up with.
>
> I patched SLF4
Hi,
I'd like to prepare a release of the maven-release-plugin 2.4 soon.
Most important changes have to do with profiles.
For Maven2 there's no change, but for Maven3 we can use the
MavenExecutionRequest to get the active profiles.
There are still unsolved issues bound to this release, which
2012/12/9 Jason van Zyl :
> Hi,
>
> I sorted out the ITs running in embedded mode and here's what I came up with.
>
> I patched SLF4J Simple to work around some static initialization that locked
> in the log level and the output stream. So the problem in the ITs is not that
> the output doesn't a
43 matches
Mail list logo
