On Nov 29, 2012, at 5:56 PM, Benson Margulies 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 i
>
> 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
On Nov 29, 2012, at 4:47 PM, Benson Margulies wrote:
> I can hypothecate a use case, but I can't point to an example.
>
> Consider a plugin that sits on top of something large and complex, and
> which logs, and which takes complete responsibility for its logging.
Sure, I consider those endpoin
I can hypothecate a use case, but I can't point to an example.
Consider a plugin that sits on top of something large and complex, and
which logs, and which takes complete responsibility for its logging.
It might, for example, have plugin parameters that control the logging
and the destination.
Th
they are now rw mode.
2012/11/29 Brett Porter :
> Looks good. Compared the current state of these to SVN and confirmed they
> match. We have a lot of $Id$ to kill in maven-integration-testing.
>
> Some empty directories removed in maven-3 - hopefully they don't affect
> anything. Particular odd
On Nov 29, 2012, at 11:50 AM, Olivier Lamy wrote:
> Le 29 nov. 2012 19:09, "Jason van Zyl" a écrit :
>>
>> That's a good example. It's SLF4J and Logback in the wild which is what I
>> expected. Good find.
> Ar easy and fast conclusion !
Based on empirical observation. Download counts for
2012/11/29 Mark Derricutt :
> Really? We want to allow different mojos to use different loggers?
>
> That just sounds like an invitation to confusion where the output of maven
> logging may appear in multiple places, files.
>
> Just with normal logging - it's not what the developer wants to use/pre
Hi
Jörg Schaible wrote:
>
> Sorry guys, but I have massive internet problems this evening. It took me
> minutes to commit a little patch for this problem. So, if anyone want to
> give it a try, simply checkout XStream trunk and build on your own, my
> wire is nearly dead.
>
> Jörg Schaible wrot
Really? We want to allow different mojos to use different loggers?
That just sounds like an invitation to confusion where the output of
maven logging may appear in multiple places, files.
Just with normal logging - it's not what the developer wants to
use/prefer, its what the USER prefers.
On Wed, 28 Nov 2012 18:26:13 -0600
Paul Gier wrote:
+1 (nb)
works fine to me
thanks,
tony.
> Hi,
>
> We solved 10 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=18491
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/secure
+1
Regards
Hervé
Le mercredi 28 novembre 2012 18:26:13 Paul Gier a écrit :
> Hi,
>
> We solved 10 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=18
> 491
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/secure/IssueNavigator.
+1
2012/11/29 Paul Gier :
> Hi,
>
> We solved 10 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=18491
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MENFORCER+AND+statu
Le 29 nov. 2012 19:09, "Jason van Zyl" a écrit :
>
> That's a good example. It's SLF4J and Logback in the wild which is what I
> expected. Good find.
Ar easy and fast conclusion !
The issue can happend with any other plugin using any other slf4j impl.
My point is: we must first try to find a
Alright, PMD 5.0.1 is available :)
I created a new issue in Jira with a small patch - as it turned out,
that we changed the PMD Renderer classes slightly
-> https://jira.codehaus.org/browse/MPMD-160
Let me know if I can help with something.
Thanks,
Andreas
On 26.11.2012 23:02, schrieb Oliv
Alright, PMD 5.0.1 is available :)
I created a new issue in Jira with a small patch - as it turned out,
that we changed the PMD Renderer classes slightly
-> https://jira.codehaus.org/browse/MPMD-160
Let me know if I can help with something.
Thanks,
Andreas
On 26.11.2012 23:02, schrieb Oliv
Sorry guys, but I have massive internet problems this evening. It took me
minutes to commit a little patch for this problem. So, if anyone want to
give it a try, simply checkout XStream trunk and build on your own, my wire
is nearly dead.
Jörg Schaible wrote:
> Hi Arnaud and Dan,
>
> Arnaud
That's a good example. It's SLF4J and Logback in the wild which is what I
expected. Good find.
https://jira.codehaus.org/browse/MNG-5393
On Nov 29, 2012, at 9:38 AM, Olivier Lamy wrote:
> fyi I just raised http://jira.codehaus.org/browse/SONAR-3983
> But we must have a look if we can fix that
Interesting question ;) I did the change in classworlds because I
tested m3 trunk with java 7 and the classloaders weren't really
unloading, even after MNG-5386. What makes it interesting is that I
suppose they actually may unload on previous jdks but stopped doing so
on java7 due to classloader no
fyi I just raised http://jira.codehaus.org/browse/SONAR-3983
But we must have a look if we can fix that on our side as it's
probably not the only case.
2012/11/29 Jörg Schaible :
> Hi Arnaud and Dan,
>
> Arnaud Héritier wrote:
>
>> On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp wrote:
>>
>>>
>>> O
Is this change expected to reduce or increase permgen use? Anything
particular we should be looking for?
FWIW, m2e embeds maven 3.0.4 and we don't have any problems (I know of)
with with permgen. There are also no major permgen problems when running
maven ITs in embedded mode. There are few threa
Hi Arnaud and Dan,
Arnaud Héritier wrote:
> On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp wrote:
>
>>
>> On Nov 29, 2012, at 1:22 AM, Stephane Nicoll
>> wrote:
>> > I would go for 2.2. Releasing something and then include it as the
>> default
>> > version the same day seems a bit too much for m
Hi,
Reminder it's mandatory for the end of the year to move that.
So I will start to ask infra for that (one volunteer to help me ?
hervé as you start the poc ? )
POC is here: http://maventest.apache.org
You can edit pages using bookmarklet see: https://cms.apache.org/maventest/
Other documenta
On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp wrote:
>
> On Nov 29, 2012, at 1:22 AM, Stephane Nicoll
> wrote:
> > I would go for 2.2. Releasing something and then include it as the
> default
> > version the same day seems a bit too much for me.
>
> I would agree with this. The fact that I was t
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll wrote:
> I would go for 2.2. Releasing something and then include it as the default
> version the same day seems a bit too much for me.
I would agree with this. The fact that I was the first one to even notice that
2.3 has issues on the Mac suggests
+1.
Tests:
* Source bundle builds [PASS]
* Integration tests pass [PASS]
* RAT check [PASS with comments]
The RAT check revealed two minor issues:
* .gitignore is neither ignored by rat nor includes the Apache header.
(Probably this just needs to be fixed in RAT)
* DEPENDENCIES does not include t
probably only if one uses the embedding to actually build the project.
Which I don't do in netbeans, only use it to load the MavenProject
instance and resolve dependencies, effectively using the extensions
only to resolve ArtifactHandlers I think.
haven't yet observed a problem with extensions clas
26 matches
Mail list logo
