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
+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
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com 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
On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp dk...@apache.org wrote:
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com
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
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
Hi Arnaud and Dan,
Arnaud Héritier wrote:
On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp dk...@apache.org wrote:
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com
wrote:
I would go for 2.2. Releasing something and then include it as the
default
version the same day
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
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 joerg.schai...@scalaris.com:
Hi Arnaud and Dan,
Arnaud Héritier wrote:
On Thu, Nov 29, 2012 at 3:41 PM, Daniel
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
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 ol...@apache.org wrote:
fyi I just raised http://jira.codehaus.org/browse/SONAR-3983
But we must have a look if
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
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
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
Le 29 nov. 2012 19:09, Jason van Zyl ja...@tesla.io 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
+1
2012/11/29 Paul Gier pg...@apache.org:
Hi,
We solved 10 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=18491
There are still a couple of issues left in JIRA:
+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=11530version=18
491
There are still a couple of issues left in JIRA:
On Wed, 28 Nov 2012 18:26:13 -0600
Paul Gier pg...@apache.org wrote:
+1 (nb)
works fine to me
thanks,
tony.
Hi,
We solved 10 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=18491
There are still a couple of issues left in JIRA:
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.
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 wrote:
2012/11/29 Mark Derricutt m...@talios.com:
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
On Nov 29, 2012, at 11:50 AM, Olivier Lamy ol...@apache.org wrote:
Le 29 nov. 2012 19:09, Jason van Zyl ja...@tesla.io 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
they are now rw mode.
2012/11/29 Brett Porter br...@apache.org:
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.
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.
On Nov 29, 2012, at 4:47 PM, Benson Margulies bimargul...@gmail.com 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
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 good
On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com 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
26 matches
Mail list logo
