Github user kobikis closed the pull request at:
https://github.com/apache/maven-surefire/pull/9
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I would not over simplify it.
Application tracing is an implicitly complex or verbose means of generating
application execution trace output.
If you're talking about turning on/off specific mojo tracing it is implicitly
technical and a nitty gritty fine tuning operation.
I think it would be a
Not that I'd ever ever do this, as the performance would be horrid, but:
In the existing logger impl throw and catch an exception and get the *calling*
class from the stack back trace.
Utterly horrid but it is doable. But is works with all existing plugins and
code with out any refactoring (ie
Github user agudian closed the pull request at:
https://github.com/apache/maven-surefire/pull/8
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
GitHub user agudian opened a pull request:
https://github.com/apache/maven-surefire/pull/10
forkMode onceperthread (SUREFIRE-751) (licence headers included)
In relation to http://jira.codehaus.org/browse/SUREFIRE-751
Adds a new forkMode option "onceperthread", that creat
Github user khmarbaise closed the pull request at:
https://github.com/apache/maven-3/pull/5
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
2012/11/16 Stuart McCulloch :
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instrumented markers across artif
I'm confused here. org.apache.maven.plugins:maven-ejb3-plugin doesn't
exist! I didn't even know there was an ejb3 packaging type.
/Anders
On Fri, Nov 16, 2012 at 9:29 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> now coming up with an other question (related to MNG-5245):
>
> I'm checking the defaul
GitHub user khmarbaise opened a pull request:
https://github.com/apache/maven-3/pull/5
[MNG-5245] Update maven plugin versions
- components.xml
- maven-clean-plugin up to 2.5
- maven-site-plugin up to 3.1
- default-bindings.xml
- maven-install-plugin up to 2.4
Hi,
now coming up with an other question (related to MNG-5245):
I'm checking the default-bindings.xml file in maven-core and found that
in the ejb packaging type the maven-ejb-plugin is pinned to 2.3 whereas
in the ejb3 packaging type the maven-ejb-plugin is not pinned to any
version.
Snippe
Hi,
> Can someone give me a hint what the "par" packaging is
> and in particular
where to find the "maven-par-plugin" ...cause i can't find a
maven-par-plugin except from springsource ...
ah i was to fast...now i found that is related to android development ...
Kind regards
Karl-Heinz
--
Softw
Hi there,
i have cloned the Maven-3 repo from github and started to dive into the
following task.
http://jira.codehaus.org/browse/MNG-5245
I have checked the default-bindings.xml in maven-core and found
something interesting.
Can someone give me a hint what the "par" packaging is and in pa
+1 (non-binding) tested with two single and one multi-module project.
Regards Mirko
On Fri, Nov 16, 2012 at 7:15 PM, Mark Struberg wrote:
> +1
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>> From: Stephane Nicoll
>> To: Maven Developers List
>> Cc:
>> Sent: Friday, November 16,
+1
LieGrue,
strub
- Original Message -
> From: Stephane Nicoll
> To: Maven Developers List
> Cc:
> Sent: Friday, November 16, 2012 5:58 PM
> Subject: Re: [VOTE] Maven Compiler Plugin 3.0 and maven-shared-incremental 1.0
>
> +1
>
> S.
>
>
> On Fri, Nov 16, 2012 at 12:36 AM, Olivi
+1
S.
On Fri, Nov 16, 2012 at 12:36 AM, Olivier Lamy wrote:
> Hi,
> I'd like to release Maven Compiler 3.0
> We fixed 9 issues.
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18537&styleName=Text&projectId=11130&Create=Create
>
> Staging repository:
> https://repository.apache.or
On Nov 16, 2012, at 10:03 AM, Stuart McCulloch wrote:
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instr
On Nov 16, 2012, at 10:25 AM, Olivier Lamy wrote:
> 2012/11/16 Jason van Zyl :
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
I prefer classname based, as it is, by definition, definative.
If you're conce
2012/11/16 Jason van Zyl :
>
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>>
>>> If you're concerned about details getting lost, then might I suggest that
>>> yo
+1
Emmanuel
On Thu, Nov 15, 2012 at 12:11 AM, Dennis Lundberg wrote:
> Hi,
>
> We solved 29 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=18308
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNav
+1
Emmanuel
On Fri, Nov 16, 2012 at 12:36 AM, Olivier Lamy wrote:
> Hi,
> I'd like to release Maven Compiler 3.0
> We fixed 9 issues.
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18537&styleName=Text&projectId=11130&Create=Create
>
> Staging repository:
> https://repository.apa
On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
> And additionally figure what markers might be necessary. So the class name
> takes care of any hierarchical filtering, and then you get into domain
> specific filtering. Say you instrumented markers across artifact resolution,
> or plugin resolut
And additionally figure what markers might be necessary. So the class name
takes care of any hierarchical filtering, and then you get into domain specific
filtering. Say you instrumented markers across artifact resolution, or plugin
resolution, local repository operations. Many of the markers co
On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>> I prefer classname based, as it is, by definition, definative.
>>
>> If you're concerned about details getting lost, then might I suggest that
>> you route that logging output to a se
My bad I missed that.
After compiler plugin I will release it.
2012/11/16 Chris Graham :
> I would like to ask that the 2.3-SNAPSHOT version of the RAR plugin is
> released. I've tested it and I'm happy with it.
>
> Thanks,
>
> -Chris
>
>
> On Mon, Oct 15, 2012 at 11:35 AM, Chris Graham wrote:
>
On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
> I prefer classname based, as it is, by definition, definative.
>
> If you're concerned about details getting lost, then might I suggest that
> you route that logging output to a separate file? trace.log works for me
> (and give a -D to allow u
I would like to ask that the 2.3-SNAPSHOT version of the RAR plugin is
released. I've tested it and I'm happy with it.
Thanks,
-Chris
On Mon, Oct 15, 2012 at 11:35 AM, Chris Graham wrote:
> Hi All.
>
> I've managed to download, build and successfully test the new 2.3-SNAPSHOT
> of the maven-r
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
-Chris
On Fri, Nov 16, 2012 at
+1
Arnaud
On Fri, Nov 16, 2012 at 12:36 AM, Olivier Lamy wrote:
> Hi,
> I'd like to release Maven Compiler 3.0
> We fixed 9 issues.
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18537&styleName=Text&projectId=11130&Create=Create
>
> Staging repository:
> https://repository.apach
2012/11/16 Adrien Rivard :
> Hi,
>
> " [MCOMPILER-159] - generatedSourcesDirectory should be included in list
> provided by
> org.apache.maven.project.MavenProject.getCompileClasspathElements()"
>
> is closed as duplicate of MCOMPILER-157 which is unresolved (in JIRA at
> least). So what is the sta
Hi,
" [MCOMPILER-159] - generatedSourcesDirectory should be included in list
provided by
org.apache.maven.project.MavenProject.getCompileClasspathElements()"
is closed as duplicate of MCOMPILER-157 which is unresolved (in JIRA at
least). So what is the status here ?
On Fri, Nov 16, 2012 at 12:3
30 matches
Mail list logo
