Re: [VOTE] Maven 3.1.0

[Mark Derricutt]

My bad - looks like IntelliJ 12 turns on its new "compiler mode" by 
default which runs a separate VM for compilation - with a default heap 
size of 700mb - my machine found itself dying in a mess of 4gb swap 
which was messing with things.


On a fresh reboot things seem much more like what I expect.

Jason van Zyl wrote:

Did anything change in your build as Aether didn't change between now and the 
last release.

The version of plexus-utils did change, maybe try swapping the version of 
plexus-utils and see if that helps.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Did anything change in your build as Aether didn't change between now and the 
last release. 

The version of plexus-utils did change, maybe try swapping the version of 
plexus-utils and see if that helps.

On Dec 4, 2012, at 3:24 PM, Mark Derricutt  wrote:

> Has anyone tried 3.1.0 with heavy use of version ranges? I'm noticing my 
> integration tests seem to now be taking a LONG time to resolve deps - 
> about 15  elements all using ranges, of which the repository has 
> something like 100+ versions of each.
> 
> A thread dump of the process when its just sitting there is below - is Aether 
> just reallly slow here?
> 
> 1022 ± jstack 7124 ✹ ✭
> 2012-12-05 12:22:29
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode):
> 
> "Attach Listener" daemon prio=5 tid=0x7fad8e33c800 nid=0x3e0b waiting on 
> condition [0x]
> java.lang.Thread.State: RUNNABLE
> 
> "Service Thread" daemon prio=5 tid=0x7fad8b050800 nid=0x4c03 runnable 
> [0x]
> java.lang.Thread.State: RUNNABLE
> 
> "C2 CompilerThread1" daemon prio=5 tid=0x7fad8b05 nid=0x4b03 waiting 
> on condition [0x]
> java.lang.Thread.State: RUNNABLE
> 
> "C2 CompilerThread0" daemon prio=5 tid=0x7fad8b04b000 nid=0x4a03 waiting 
> on condition [0x]
> java.lang.Thread.State: RUNNABLE
> 
> "Signal Dispatcher" daemon prio=5 tid=0x7fad8b044000 nid=0x4903 runnable 
> [0x]
> java.lang.Thread.State: RUNNABLE
> 
> "Finalizer" daemon prio=5 tid=0x7fad8c020800 nid=0x3703 in Object.wait() 
> [0x0001606b2000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0001251e0d30> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0x0001251e0d30> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
> 
> "Reference Handler" daemon prio=5 tid=0x7fad8c01f800 nid=0x3603 in 
> Object.wait() [0x0001605af000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0001251e0dc8> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:503)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
> - locked <0x0001251e0dc8> (a java.lang.ref.Reference$Lock)
> 
> "main" prio=5 tid=0x7fad8c000800 nid=0x1703 runnable [0x00010cae7000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:242)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
> - locked <0x000114311100> (a java.io.BufferedInputStream)
> at org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:635)
> at org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:459)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:180)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:143)
> at 
> org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:86)
> at org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:104)
> at 
> org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:827)
> at 
> org.apache.maven.repository.internal.DefaultVersionResolver.readVersions(DefaultVersionResolver.java:330)
> at 
> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:240)
> at 
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:250)
> at 
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186)
> at 
> org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412)
> at 
> org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
> at 
> org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308)
> at 
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:150)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ex

Re: [VOTE] Maven 3.1.0

[Mark Derricutt]

Has anyone tried 3.1.0 with heavy use of version ranges? I'm noticing my 
integration tests seem to now be taking a LONG time to resolve 
deps - about 15  elements all using ranges, of which the 
repository has something like 100+ versions of each.


A thread dump of the process when its just sitting there is below - is 
Aether just reallly slow here?


1022 ± jstack 7124 ✹ ✭
2012-12-05 12:22:29
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode):

"Attach Listener" daemon prio=5 tid=0x7fad8e33c800 nid=0x3e0b 
waiting on condition [0x]

java.lang.Thread.State: RUNNABLE

"Service Thread" daemon prio=5 tid=0x7fad8b050800 nid=0x4c03 
runnable [0x]

java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=5 tid=0x7fad8b05 nid=0x4b03 
waiting on condition [0x]

java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=5 tid=0x7fad8b04b000 nid=0x4a03 
waiting on condition [0x]

java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=5 tid=0x7fad8b044000 nid=0x4903 
runnable [0x]

java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=5 tid=0x7fad8c020800 nid=0x3703 in 
Object.wait() [0x0001606b2000]

java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0001251e0d30> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked <0x0001251e0d30> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)

"Reference Handler" daemon prio=5 tid=0x7fad8c01f800 nid=0x3603 in 
Object.wait() [0x0001605af000]

java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0001251e0dc8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked <0x0001251e0dc8> (a java.lang.ref.Reference$Lock)

"main" prio=5 tid=0x7fad8c000800 nid=0x1703 runnable 
[0x00010cae7000]

java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:242)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
- locked <0x000114311100> (a java.io.BufferedInputStream)
at org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:635)
at org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:459)
at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:180)
at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:143)
at 
org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:86)
at 
org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:104)
at 
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:827)
at 
org.apache.maven.repository.internal.DefaultVersionResolver.readVersions(DefaultVersionResolver.java:330)
at 
org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:240)
at 
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:250)
at 
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186)
at 
org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412)
at 
org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
at 
org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308)
at 
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:150)
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

I don't think it will be hard to fix, it's just the use of a BOAS, setting 
stdout/err repeatedly and then using stdout for logging in SLF4J. Just need to 
track down the interactions and fix it.

On Dec 4, 2012, at 11:13 AM, Kristian Rosenvold  
wrote:

> Obviously if it doesnt affect m2e (and this is known ?) its less of a problem.
> 
> In that case it means it'll just be a PITA for those 10-or so projects
> that use verifier here at asf
> and any others. I am no fan of releasing a version I wouldn't want to
> use myself, so I think
> this needs to be fixed - it's *our* time that will be wasted in the
> future if we let this through.
> 
> So changing verifier to use a better approach may come, but I'm not
> sure it should come for /this/ reason?
> 
> Is this for some reason a hard issue to fix ?
> 
> Kristian
> 
> 
> 
> 2012/12/4 Kristian Rosenvold :
>> The severity of the issue is less
>> 
>> 2012/12/4 Jason van Zyl :
>>> Our build server appears out, and I wanted to get off my machine so I spun 
>>> up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears 
>>> to be the problem.
>>> 
>>> Obviously this affects people who embed, but won't affect CLI users. The 
>>> major use case is m2e and it already uses SLF4J with logback so I don't see 
>>> any issues there, but if others are concerned I'll track it down.
>>> 
>>> On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold 
>>>  wrote:
>>> 
 The core it's were running against 1.4-SNAPSHOT of the verifier and I
 had introduced a minor compatibility problem when adding generics
 which caused them to not compile. That is fixed on verifier trunk now.
 
 I just ran the following core it's, and they run lightning fast & razor 
 sharp:
 
 mvn304  -Pembedded,run-its clean install  # success, 5min 11 sec
 mvn31  -Pembedded,run-its clean install  #  At
 22df629f9707e46cfabddd3d657757701bd64a76  (2 failing IT's that were
 fixed in later 3.1 versions - as expected)
 mvn31  -Pembedded,run-its clean install  #  At
 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures
 for instance mng4829
 
 So the problem was introduced with slf4j; case closed.
 
 Kristian
 
 
 
 2012/12/4 Jason van Zyl :
> M
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>> 
>>> believe nothing, no matter where you read it,
>>> or who has said it,
>>> not even if i have said it,
>>> unless it agrees with your own reason
>>> and your own common sense.
>>> 
>>> -- Buddha
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

Obviously if it doesnt affect m2e (and this is known ?) its less of a problem.

In that case it means it'll just be a PITA for those 10-or so projects
that use verifier here at asf
and any others. I am no fan of releasing a version I wouldn't want to
use myself, so I think
this needs to be fixed - it's *our* time that will be wasted in the
future if we let this through.

So changing verifier to use a better approach may come, but I'm not
sure it should come for /this/ reason?

Is this for some reason a hard issue to fix ?

Kristian



2012/12/4 Kristian Rosenvold :
> The severity of the issue is less
>
> 2012/12/4 Jason van Zyl :
>> Our build server appears out, and I wanted to get off my machine so I spun 
>> up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears 
>> to be the problem.
>>
>> Obviously this affects people who embed, but won't affect CLI users. The 
>> major use case is m2e and it already uses SLF4J with logback so I don't see 
>> any issues there, but if others are concerned I'll track it down.
>>
>> On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold 
>>  wrote:
>>
>>> The core it's were running against 1.4-SNAPSHOT of the verifier and I
>>> had introduced a minor compatibility problem when adding generics
>>> which caused them to not compile. That is fixed on verifier trunk now.
>>>
>>> I just ran the following core it's, and they run lightning fast & razor 
>>> sharp:
>>>
>>> mvn304  -Pembedded,run-its clean install  # success, 5min 11 sec
>>> mvn31  -Pembedded,run-its clean install  #  At
>>> 22df629f9707e46cfabddd3d657757701bd64a76  (2 failing IT's that were
>>> fixed in later 3.1 versions - as expected)
>>> mvn31  -Pembedded,run-its clean install  #  At
>>> 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures
>>> for instance mng4829
>>>
>>> So the problem was introduced with slf4j; case closed.
>>>
>>> Kristian
>>>
>>>
>>>
>>> 2012/12/4 Jason van Zyl :
 M
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>>  -- Buddha
>>
>>
>>
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

The severity of the issue is less

2012/12/4 Jason van Zyl :
> Our build server appears out, and I wanted to get off my machine so I spun up 
> an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to 
> be the problem.
>
> Obviously this affects people who embed, but won't affect CLI users. The 
> major use case is m2e and it already uses SLF4J with logback so I don't see 
> any issues there, but if others are concerned I'll track it down.
>
> On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold  
> wrote:
>
>> The core it's were running against 1.4-SNAPSHOT of the verifier and I
>> had introduced a minor compatibility problem when adding generics
>> which caused them to not compile. That is fixed on verifier trunk now.
>>
>> I just ran the following core it's, and they run lightning fast & razor 
>> sharp:
>>
>> mvn304  -Pembedded,run-its clean install  # success, 5min 11 sec
>> mvn31  -Pembedded,run-its clean install  #  At
>> 22df629f9707e46cfabddd3d657757701bd64a76  (2 failing IT's that were
>> fixed in later 3.1 versions - as expected)
>> mvn31  -Pembedded,run-its clean install  #  At
>> 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures
>> for instance mng4829
>>
>> So the problem was introduced with slf4j; case closed.
>>
>> Kristian
>>
>>
>>
>> 2012/12/4 Jason van Zyl :
>>> M
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
>  -- Buddha
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0

[ceki]

On 04.12.2012 19:18, Jason van Zyl wrote:

> I've been talking to Ceki about configuration in SLF4J as there is
> really no way to change the log level without assuming an
> implementation. If that's the way then for embedding the user can
> change the SLF4J implementation but for the CLI this will not be
> possible. What I would effectively have to do is what the Sonar folks
> did which is to grab hold of the implementation and programmatically
> change the log level.
>
> So if the default log level is INFO I don't think it's possible to
> ship all implementations and be able to flip to debug mode easily. So
> I think if we pick one implementation then for the CLI we can make
> that assumption. Again this should not affect folks who embed like m2e
> as we just use the components and do our own SLF4J integration.

It would be possible to set the level of a logger by invoking
framework-specific directives. Here is some pseudo-code:

// pseudo code
public void setLevel(Logger logger, int level) {
  if(logger instanceof org.apache.log4j.Logger) {
log4jSetLevel(logger, level);
  } else if(logger instanceof ch.qos.logback.classic.Logger) {
logbackSetLevel(logger, level);
  } else if (logger instanceof java.util.logging.Logger) {
julSetLevel(logger, level);
  } else if (you get the idea...) {
...
  }
}

Historically, SLF4J has shied away from providing abstractions for
logging configuration for two reasons:

1) logging configuration can have quite a large scope.
2) insufficient demand

If the scope of "configuration" is limited to logger level
configuration, the problem becomes much easier to tackle as
illustrated by the pseudo code above. Would Maven's logging
configuration requirements be satisfied by logger level configuration
or are there requirements beyond logger level configuration?

By the way, the is no reason why Maven could not implement similar
level configuration code on its own without depending on a slf4j
configuration module which currently does not exist.

--
Ceki
http://twitter.com/#!/ceki

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0

[Olivier Lamy]

I did that in the branches using sys props

  
 INFO
  


  


When starting and before any slf4j access, MavenCli check -q or -X or
none of both and correctly set the value to the level
(INFO,ERROR,DEBUG)
Works fine for all slf4j impls using this naming convention.


2012/12/4 Jason van Zyl :
>
> On Dec 4, 2012, at 9:44 AM, Arnaud Héritier  wrote:
>
>> Jason,
>>
>>  I'll test more later but FYI it seems that your logback branch doesn't
>> support options -X/--debug
>>
>
> I've been talking to Ceki about configuration in SLF4J as there is really no 
> way to change the log level without assuming an implementation. If that's the 
> way then for embedding the user can change the SLF4J implementation but for 
> the CLI this will not be possible. What I would effectively have to do is 
> what the Sonar folks did which is to grab hold of the implementation and 
> programmatically change the log level.
>
> So if the default log level is INFO I don't think it's possible to ship all 
> implementations and be able to flip to debug mode easily. So I think if we 
> pick one implementation then for the CLI we can make that assumption. Again 
> this should not affect folks who embed like m2e as we just use the components 
> and do our own SLF4J integration.
>
>> cheers
>>
>> Arnaud
>>
>>
>> On Sat, Dec 1, 2012 at 6:47 PM, Jason van Zyl  wrote:
>>
>>> I already have started a logback version, but I don't think this should
>>> affect rolling the 3.1.0.
>>>
>>> On Dec 1, 2012, at 6:57 AM, Arnaud Héritier  wrote:
>>>
 I pushed the prototype developed by olivier using log4j2 in the
 branch feature/colorized-console/log4j2
 I updated with latest master changes
 You can test the distro of this code : http://cl.ly/1B1z051O0T10

 Tonight I'll try to do a logback version

 cheers

 Arnaud


 On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier >>> wrote:

>
>
>
> On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY >>> wrote:
>
>> I just created and fixed MNG-5395 and MNG-5396, which are logger names
>> enhancements from the actual values that will give value even with
>>> slf4j-
>> simple
>>
>> These should be a starting point for more global discussion about our
>> logging
>> conventions then fixed in our global codebase, since IMHO, these issues
>> show
>> how we didn't use the logger names until now then we have a lot of
>>> place
>> where
>> our logging pratice is not good
>>
>> Of course, I'm interested in colorized output, but since it has impact
>>> on
>> logging implementation choice, which will require a strong discussion,
>> this
>> can't be done for the moment :|
>>
>
>
> A strong discussion ? seriously ?
> We have 3 choices from my point of view :
> * We do nothing, we keep the slf4j-simple
> * We choose logback which is mature and used by a lot of people.
>>> Nowadays
> from my point of view it is the reference implementation
> * We choose log4j2 which is really promising but always in beta. But we
> may do this "political" to support this project which is rising from the
> ashes (http://logging.apache.org/log4j/2.x/manual/index.html)
>
> In any case doing a choice nowadays for 3.1.0 won't prevent us to change
> it in the future. I really hope that the ability to switch from a logger
> implementation to another won't require several days of developments or
>>> I
> really missed something about it.
>
> Cheers
>
>
> Arnaud
>
>
>
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit :
>>> Hi Jason,
>>>
>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>> sanitize / merge it to propose at least one change for the end user
>>> and demonstrate the interest of the change about logs : a colorized
>>> console.
>>>
>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>> extension ?) and perhaps it could be easy to add properly this feature
>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>
>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>> satisfied (it's so good to quickly see highlighted warning and errors
>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>
>>> Wdyt?
>>>
>>> -
>>> Arnaud
>>>
>>> Le 1 déc. 2012 à 00:20, Jason van Zyl  a écrit :
 I'm done with the issues that cropped up so I'm ready to re-spin
>> 3.1.0.

 Anyone want to add anything or discuss anything before I spin this?
>> I'm
 not in any rush so if folks want to talk about logging we can. But
>> given
 the fact once SLF4J initializes it can't change the implementation
 plugins integrating with Maven need to use the implemen

Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0

[Jason van Zyl]

On Dec 4, 2012, at 9:44 AM, Arnaud Héritier  wrote:

> Jason,
> 
>  I'll test more later but FYI it seems that your logback branch doesn't
> support options -X/--debug
> 

I've been talking to Ceki about configuration in SLF4J as there is really no 
way to change the log level without assuming an implementation. If that's the 
way then for embedding the user can change the SLF4J implementation but for the 
CLI this will not be possible. What I would effectively have to do is what the 
Sonar folks did which is to grab hold of the implementation and 
programmatically change the log level.

So if the default log level is INFO I don't think it's possible to ship all 
implementations and be able to flip to debug mode easily. So I think if we pick 
one implementation then for the CLI we can make that assumption. Again this 
should not affect folks who embed like m2e as we just use the components and do 
our own SLF4J integration.

> cheers
> 
> Arnaud
> 
> 
> On Sat, Dec 1, 2012 at 6:47 PM, Jason van Zyl  wrote:
> 
>> I already have started a logback version, but I don't think this should
>> affect rolling the 3.1.0.
>> 
>> On Dec 1, 2012, at 6:57 AM, Arnaud Héritier  wrote:
>> 
>>> I pushed the prototype developed by olivier using log4j2 in the
>>> branch feature/colorized-console/log4j2
>>> I updated with latest master changes
>>> You can test the distro of this code : http://cl.ly/1B1z051O0T10
>>> 
>>> Tonight I'll try to do a logback version
>>> 
>>> cheers
>>> 
>>> Arnaud
>>> 
>>> 
>>> On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier >> wrote:
>>> 
 
 
 
 On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY >> wrote:
 
> I just created and fixed MNG-5395 and MNG-5396, which are logger names
> enhancements from the actual values that will give value even with
>> slf4j-
> simple
> 
> These should be a starting point for more global discussion about our
> logging
> conventions then fixed in our global codebase, since IMHO, these issues
> show
> how we didn't use the logger names until now then we have a lot of
>> place
> where
> our logging pratice is not good
> 
> Of course, I'm interested in colorized output, but since it has impact
>> on
> logging implementation choice, which will require a strong discussion,
> this
> can't be done for the moment :|
> 
 
 
 A strong discussion ? seriously ?
 We have 3 choices from my point of view :
 * We do nothing, we keep the slf4j-simple
 * We choose logback which is mature and used by a lot of people.
>> Nowadays
 from my point of view it is the reference implementation
 * We choose log4j2 which is really promising but always in beta. But we
 may do this "political" to support this project which is rising from the
 ashes (http://logging.apache.org/log4j/2.x/manual/index.html)
 
 In any case doing a choice nowadays for 3.1.0 won't prevent us to change
 it in the future. I really hope that the ability to switch from a logger
 implementation to another won't require several days of developments or
>> I
 really missed something about it.
 
 Cheers
 
 
 Arnaud
 
 
 
> 
> Regards,
> 
> Hervé
> 
> Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit :
>> Hi Jason,
>> 
>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>> 
>> I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>> 
>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>> 
>> Wdyt?
>> 
>> -
>> Arnaud
>> 
>> Le 1 déc. 2012 à 00:20, Jason van Zyl  a écrit :
>>> I'm done with the issues that cropped up so I'm ready to re-spin
> 3.1.0.
>>> 
>>> Anyone want to add anything or discuss anything before I spin this?
> I'm
>>> not in any rush so if folks want to talk about logging we can. But
> given
>>> the fact once SLF4J initializes it can't change the implementation
>>> plugins integrating with Maven need to use the implementation we
> choose.
>>> This is how everything else in the world that integrates SLF4J has to
>>> operate so I don't really see us being any different.
>>> 
>>> I'll wait until tomorrow to re-spin.
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apach

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Our build server appears out, and I wanted to get off my machine so I spun up 
an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to be 
the problem.

Obviously this affects people who embed, but won't affect CLI users. The major 
use case is m2e and it already uses SLF4J with logback so I don't see any 
issues there, but if others are concerned I'll track it down. 

On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold  
wrote:

> The core it's were running against 1.4-SNAPSHOT of the verifier and I
> had introduced a minor compatibility problem when adding generics
> which caused them to not compile. That is fixed on verifier trunk now.
> 
> I just ran the following core it's, and they run lightning fast & razor sharp:
> 
> mvn304  -Pembedded,run-its clean install  # success, 5min 11 sec
> mvn31  -Pembedded,run-its clean install  #  At
> 22df629f9707e46cfabddd3d657757701bd64a76  (2 failing IT's that were
> fixed in later 3.1 versions - as expected)
> mvn31  -Pembedded,run-its clean install  #  At
> 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures
> for instance mng4829
> 
> So the problem was introduced with slf4j; case closed.
> 
> Kristian
> 
> 
> 
> 2012/12/4 Jason van Zyl :
>> M
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

The core it's were running against 1.4-SNAPSHOT of the verifier and I
had introduced a minor compatibility problem when adding generics
which caused them to not compile. That is fixed on verifier trunk now.

I just ran the following core it's, and they run lightning fast & razor sharp:

mvn304  -Pembedded,run-its clean install  # success, 5min 11 sec
mvn31  -Pembedded,run-its clean install  #  At
22df629f9707e46cfabddd3d657757701bd64a76  (2 failing IT's that were
fixed in later 3.1 versions - as expected)
mvn31  -Pembedded,run-its clean install  #  At
22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures
for instance mng4829

So the problem was introduced with slf4j; case closed.

Kristian



2012/12/4 Jason van Zyl :
> M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0

[Arnaud Héritier]

Jason,

  I'll test more later but FYI it seems that your logback branch doesn't
support options -X/--debug

cheers

Arnaud


On Sat, Dec 1, 2012 at 6:47 PM, Jason van Zyl  wrote:

> I already have started a logback version, but I don't think this should
> affect rolling the 3.1.0.
>
> On Dec 1, 2012, at 6:57 AM, Arnaud Héritier  wrote:
>
> > I pushed the prototype developed by olivier using log4j2 in the
> > branch feature/colorized-console/log4j2
> > I updated with latest master changes
> > You can test the distro of this code : http://cl.ly/1B1z051O0T10
> >
> > Tonight I'll try to do a logback version
> >
> > cheers
> >
> > Arnaud
> >
> >
> > On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier  >wrote:
> >
> >>
> >>
> >>
> >> On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY  >wrote:
> >>
> >>> I just created and fixed MNG-5395 and MNG-5396, which are logger names
> >>> enhancements from the actual values that will give value even with
> slf4j-
> >>> simple
> >>>
> >>> These should be a starting point for more global discussion about our
> >>> logging
> >>> conventions then fixed in our global codebase, since IMHO, these issues
> >>> show
> >>> how we didn't use the logger names until now then we have a lot of
> place
> >>> where
> >>> our logging pratice is not good
> >>>
> >>> Of course, I'm interested in colorized output, but since it has impact
> on
> >>> logging implementation choice, which will require a strong discussion,
> >>> this
> >>> can't be done for the moment :|
> >>>
> >>
> >>
> >> A strong discussion ? seriously ?
> >> We have 3 choices from my point of view :
> >> * We do nothing, we keep the slf4j-simple
> >> * We choose logback which is mature and used by a lot of people.
> Nowadays
> >> from my point of view it is the reference implementation
> >> * We choose log4j2 which is really promising but always in beta. But we
> >> may do this "political" to support this project which is rising from the
> >> ashes (http://logging.apache.org/log4j/2.x/manual/index.html)
> >>
> >> In any case doing a choice nowadays for 3.1.0 won't prevent us to change
> >> it in the future. I really hope that the ability to switch from a logger
> >> implementation to another won't require several days of developments or
> I
> >> really missed something about it.
> >>
> >> Cheers
> >>
> >>
> >> Arnaud
> >>
> >>
> >>
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit :
>  Hi Jason,
> 
>   Couldn't we have a look at olamy's log4j2 branch to see if we could
>  sanitize / merge it to propose at least one change for the end user
>  and demonstrate the interest of the change about logs : a colorized
>  console.
> 
>   I remember you did that in mvnsh/teslashell a long time ago (as an
>  extension ?) and perhaps it could be easy to add properly this feature
>  in 3.1.0 (otherwise it won't be before a 3.2.0).
> 
>   Myself I'm using a 3.1.0 fork with this patch and I' m really
>  satisfied (it's so good to quickly see highlighted warning and errors
>  ). I merged it back in the last 3.1.0 tag you did without issue
> 
>   Wdyt?
> 
>  -
>  Arnaud
> 
>  Le 1 déc. 2012 à 00:20, Jason van Zyl  a écrit :
> > I'm done with the issues that cropped up so I'm ready to re-spin
> >>> 3.1.0.
> >
> > Anyone want to add anything or discuss anything before I spin this?
> >>> I'm
> > not in any rush so if folks want to talk about logging we can. But
> >>> given
> > the fact once SLF4J initializes it can't change the implementation
> > plugins integrating with Maven need to use the implementation we
> >>> choose.
> > This is how everything else in the world that integrates SLF4J has to
> > operate so I don't really see us being any different.
> >
> > I'll wait until tomorrow to re-spin.
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> -
> >> Arnaud Héritier
> >> http://aheritier.net
> >> Mail/GTalk: aheritier AT gmail DOT com
> >> Twitter/Skype : aheritier
> >>
> >>
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> 

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

I'll do the same for the core ITs when I ran them against 3.0.3, 3.0.4 and 
master they all failed in embedded mode with the same problem.

So your surefire ITs fork once using the embedder and use the special method in 
MavenCli that has this signature:

public int doMain( String[] args, String workingDirectory, PrintStream 
stdout, PrintStream stderr )

If so then we're looking at the same problem.

On Dec 4, 2012, at 8:54 AM, Kristian Rosenvold  
wrote:

> If I build m3 core at 22df629f9707e46cfabddd3d657757701bd64a76 the
> supplied testcase works.
> 
> When I do git reset --hard 25669cfe131e19f152c87c1b250ffec0b30f8d26 to
> move 2 commits later in history,
> it stops working.
> 
> git log  
> 22df629f9707e46cfabddd3d657757701bd64a76..25669cfe131e19f152c87c1b250ffec0b30f8d26
> 
> Shows that the introduction of slf4j broke this.
> 
> As for the core it's in embedded mode, I have never really had much
> success with those. But this break will
> most definitely torpedo the core its in embedded mode right out of the water.
> 
> Kristian
> 
> 
> 
> 
> 
> 2012/12/4 Kristian Rosenvold :
>> The failing test in question keeps the verifier at a fixed 1.3
>> version. But with 3.0.4 it is fully capable of producing the "log.txt"
>> file in embedded mode. The only thing that changes in the supplied
>> demonstration is the maven version.
>> 
>> Embedded tests work *fine* in general but I think a lot of verifier
>> tests rely on asserting things in the log. Hence a lot of them dont
>> work when the log.txt goes missing.
>> 
>> Kristian
>> 
>> 2012/12/4 Jason van Zyl :
>>> I believe this is the verifier that changed. The embedded tests don't work 
>>> in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is 
>>> not captured to a file which is what causes the test failures. For the 
>>> tests that are looking specifically for things in the log.txt.
>>> 
>>> On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold 
>>>  wrote:
>>> 
 To reproduce:
 
 https://git-wip-us.apache.org/repos/asf/maven-surefire.git
 cd maven-surefire
 mvn -DskipTests install
 cd surefire-integration-tests
 
 # ready to rock
 mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
 clean install # works
 less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
 # Shows log content
 mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
 clean install # fails
 less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
 # empty file
 
 This would seem to be the Embedded3xLauncher in verifier that does not
 work with 3.1
 
 I assume this might be an issue for other scenarios too
 
 Kristian
 
 
 
 2012/12/4 Kristian Rosenvold :
> There is something wrong with logging in embedded mode; when runnin
> surefire tests with verifier
> I am no longer able to pick up log output from the running maven process:
> 
> 
> 
> 
> 2012/12/4 Anders Hammar :
>> Is the site updated? It says it was published Nov 15 and some info 
>> doesn't
>> seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).
>> 
>> /Anders
>> 
>> 
>> On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:
>> 
>>> Hi,
>>> 
>>> Here is a link to Jira with 42 issues resolved:
>>> 
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-110/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> 
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
>>> 
>>> Specifically the zip, tarball, and source archives can be found here:
>>> 
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
>>> 
>>> Staging site:
>>> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
>>> 
>>> The documentation specifically for this release pertains to JSR330 and
>>> SLF4J-based logging:
>>> http://maven.apache.org/maven-jsr330.html
>>> http://maven.apache.org/maven-logging.html
>>> 
>>> Vote open for 72 hours.
>>> 
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> -

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

If I build m3 core at 22df629f9707e46cfabddd3d657757701bd64a76 the
supplied testcase works.

When I do git reset --hard 25669cfe131e19f152c87c1b250ffec0b30f8d26 to
move 2 commits later in history,
it stops working.

git log  
22df629f9707e46cfabddd3d657757701bd64a76..25669cfe131e19f152c87c1b250ffec0b30f8d26

Shows that the introduction of slf4j broke this.

As for the core it's in embedded mode, I have never really had much
success with those. But this break will
most definitely torpedo the core its in embedded mode right out of the water.

Kristian





2012/12/4 Kristian Rosenvold :
> The failing test in question keeps the verifier at a fixed 1.3
> version. But with 3.0.4 it is fully capable of producing the "log.txt"
> file in embedded mode. The only thing that changes in the supplied
> demonstration is the maven version.
>
> Embedded tests work *fine* in general but I think a lot of verifier
> tests rely on asserting things in the log. Hence a lot of them dont
> work when the log.txt goes missing.
>
> Kristian
>
> 2012/12/4 Jason van Zyl :
>> I believe this is the verifier that changed. The embedded tests don't work 
>> in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is 
>> not captured to a file which is what causes the test failures. For the tests 
>> that are looking specifically for things in the log.txt.
>>
>> On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold 
>>  wrote:
>>
>>> To reproduce:
>>>
>>> https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>>> cd maven-surefire
>>> mvn -DskipTests install
>>> cd surefire-integration-tests
>>>
>>> # ready to rock
>>> mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
>>> clean install # works
>>> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
>>> # Shows log content
>>> mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
>>> clean install # fails
>>> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
>>> # empty file
>>>
>>> This would seem to be the Embedded3xLauncher in verifier that does not
>>> work with 3.1
>>>
>>> I assume this might be an issue for other scenarios too
>>>
>>> Kristian
>>>
>>>
>>>
>>> 2012/12/4 Kristian Rosenvold :
 There is something wrong with logging in embedded mode; when runnin
 surefire tests with verifier
 I am no longer able to pick up log output from the running maven process:




 2012/12/4 Anders Hammar :
> Is the site updated? It says it was published Nov 15 and some info doesn't
> seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).
>
> /Anders
>
>
> On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:
>
>> Hi,
>>
>> Here is a link to Jira with 42 issues resolved:
>>
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-110/
>>
>> The distributable binaries and sources for testing can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
>>
>> Specifically the zip, tarball, and source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
>>
>> Staging site:
>> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
>>
>> The documentation specifically for this release pertains to JSR330 and
>> SLF4J-based logging:
>> http://maven.apache.org/maven-jsr330.html
>> http://maven.apache.org/maven-logging.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more examples
>> you look at, the more general your framework will be.
>>
>> -- Ralph 

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

The failing test in question keeps the verifier at a fixed 1.3
version. But with 3.0.4 it is fully capable of producing the "log.txt"
file in embedded mode. The only thing that changes in the supplied
demonstration is the maven version.

Embedded tests work *fine* in general but I think a lot of verifier
tests rely on asserting things in the log. Hence a lot of them dont
work when the log.txt goes missing.

Kristian

2012/12/4 Jason van Zyl :
> I believe this is the verifier that changed. The embedded tests don't work in 
> general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not 
> captured to a file which is what causes the test failures. For the tests that 
> are looking specifically for things in the log.txt.
>
> On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold  
> wrote:
>
>> To reproduce:
>>
>> https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>> cd maven-surefire
>> mvn -DskipTests install
>> cd surefire-integration-tests
>>
>> # ready to rock
>> mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
>> clean install # works
>> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
>> # Shows log content
>> mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
>> clean install # fails
>> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
>> # empty file
>>
>> This would seem to be the Embedded3xLauncher in verifier that does not
>> work with 3.1
>>
>> I assume this might be an issue for other scenarios too
>>
>> Kristian
>>
>>
>>
>> 2012/12/4 Kristian Rosenvold :
>>> There is something wrong with logging in embedded mode; when runnin
>>> surefire tests with verifier
>>> I am no longer able to pick up log output from the running maven process:
>>>
>>>
>>>
>>>
>>> 2012/12/4 Anders Hammar :
 Is the site updated? It says it was published Nov 15 and some info doesn't
 seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).

 /Anders


 On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:

> Hi,
>
> Here is a link to Jira with 42 issues resolved:
>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-110/
>
> The distributable binaries and sources for testing can be found here:
>
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
>
> Specifically the zip, tarball, and source archives can be found here:
>
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
>
> Staging site:
> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
>
> The documentation specifically for this release pertains to JSR330 and
> SLF4J-based logging:
> http://maven.apache.org/maven-jsr330.html
> http://maven.apache.org/maven-logging.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jas

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

I believe this is the verifier that changed. The embedded tests don't work in 
general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not 
captured to a file which is what causes the test failures. For the tests that 
are looking specifically for things in the log.txt.

On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold  
wrote:

> To reproduce:
> 
> https://git-wip-us.apache.org/repos/asf/maven-surefire.git
> cd maven-surefire
> mvn -DskipTests install
> cd surefire-integration-tests
> 
> # ready to rock
> mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
> clean install # works
> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
> # Shows log content
> mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
> clean install # fails
> less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
> # empty file
> 
> This would seem to be the Embedded3xLauncher in verifier that does not
> work with 3.1
> 
> I assume this might be an issue for other scenarios too
> 
> Kristian
> 
> 
> 
> 2012/12/4 Kristian Rosenvold :
>> There is something wrong with logging in embedded mode; when runnin
>> surefire tests with verifier
>> I am no longer able to pick up log output from the running maven process:
>> 
>> 
>> 
>> 
>> 2012/12/4 Anders Hammar :
>>> Is the site updated? It says it was published Nov 15 and some info doesn't
>>> seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).
>>> 
>>> /Anders
>>> 
>>> 
>>> On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:
>>> 
 Hi,
 
 Here is a link to Jira with 42 issues resolved:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-110/
 
 The distributable binaries and sources for testing can be found here:
 
 https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
 
 Specifically the zip, tarball, and source archives can be found here:
 
 https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
 
 https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
 
 https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
 
 https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
 
 Staging site:
 http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
 
 The documentation specifically for this release pertains to JSR330 and
 SLF4J-based logging:
 http://maven.apache.org/maven-jsr330.html
 http://maven.apache.org/maven-logging.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder & CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 People develop abstractions by generalizing from concrete examples.
 Every attempt to determine the correct abstraction on paper without
 actually developing a running system is doomed to failure. No one
 is that smart. A framework is a resuable design, so you develop it by
 looking at the things it is supposed to be a design of. The more examples
 you look at, the more general your framework will be.
 
 -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and

Re: [VOTE] Maven 3.1.0

[Christian Schulte]

Please do not update the site plugin to 3.2. See
.

-- 
Christian


Am 12/04/12 05:10, schrieb Jason van Zyl:
> Hi,
> 
> Here is a link to Jira with 42 issues resolved:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-110/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
> 
> Staging site:
> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
> 
> The documentation specifically for this release pertains to JSR330 and 
> SLF4J-based logging:
> http://maven.apache.org/maven-jsr330.html
> http://maven.apache.org/maven-logging.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
> 
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Jesse Farinacci]

Greetings,

On Mon, Dec 3, 2012 at 11:10 PM, Jason van Zyl  wrote:
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/

Created https://jira.codehaus.org/browse/MNG-5403

Continuing to test.

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Anders Hammar]

> When displaying mvn -version I got :
>
> Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04
> 05:03:32+0100)
> Maven home: /opt/maven
>
> I don't understand the revision, Any clue about it ?
>

MNG-5402

Working on it. Not a show stopper though in my opinion.

/Anders


>
> thanks,
>
> tony.
>
>
> > Hi,
> >
> > Here is a link to Jira with 42 issues resolved:
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-110/
> >
> > The distributable binaries and sources for testing can be found here:
> >
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
> >
> > Specifically the zip, tarball, and source archives can be found here:
> >
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> >
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> >
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> >
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
> >
> > Staging site:
> > http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
> >
> > The documentation specifically for this release pertains to JSR330 and
> SLF4J-based logging:
> > http://maven.apache.org/maven-jsr330.html
> > http://maven.apache.org/maven-logging.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> >
> > People develop abstractions by generalizing from concrete examples.
> > Every attempt to determine the correct abstraction on paper without
> > actually developing a running system is doomed to failure. No one
> > is that smart. A framework is a resuable design, so you develop it by
> > looking at the things it is supposed to be a design of. The more examples
> > you look at, the more general your framework will be.
> >
> > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> email: che...@codelutin.com
> http://www.codelutin.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven 3.1.0

[Tony Chemit]

On Mon, 3 Dec 2012 20:10:41 -0800
Jason van Zyl  wrote:

When displaying mvn -version I got : 

Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04 
05:03:32+0100)
Maven home: /opt/maven

I don't understand the revision, Any clue about it ?

thanks,

tony.


> Hi,
> 
> Here is a link to Jira with 42 issues resolved:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-110/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
> 
> Staging site:
> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
> 
> The documentation specifically for this release pertains to JSR330 and 
> SLF4J-based logging:
> http://maven.apache.org/maven-jsr330.html
> http://maven.apache.org/maven-logging.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
> 
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Mark Derricutt]

+1 non binding so far from
 my own tests.

I suspect Kristian's comment is a -1 tho...


   	   
   	Jason van Zyl  
  4 December 2012 
5:10 PM
  Hi,Here is a link 
to Jira with 42 issues resolved:https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967Staging
 repo:https://repository.apache.org/content/repositories/maven-110/The
 distributable binaries and sources for testing can be found here:https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/Specifically
 the zip, tarball, and source archives can be found here:https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.ziphttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gzhttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.ziphttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gzStaging
 site:http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0The
 documentation specifically for this release pertains to JSR330 and 
SLF4J-based logging:http://maven.apache.org/maven-jsr330.htmlhttp://maven.apache.org/maven-logging.htmlVote
 open for 72 hours.[ ] +1[ ] +0[ ] -1Thanks,Jason--Jason
 van ZylFounder & CTO, SonatypeFounder,  Apache Mavenhttp://twitter.com/jvanzyl-People
 develop abstractions by generalizing from concrete examples.Every 
attempt to determine the correct abstraction on paper withoutactually
 developing a running system is doomed to failure. No oneis that 
smart. A framework is a resuable design, so you develop it bylooking
 at the things it is supposed to be a design of. The more examplesyou
 look at, the more general your framework will be.-- Ralph 
Johnson & Don Roberts, Patterns for Evolving Frameworks -To
 unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgFor additional
 commands, e-mail: dev-h...@maven.apache.org-To
 unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgFor additional
 commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

To reproduce:

https://git-wip-us.apache.org/repos/asf/maven-surefire.git
cd maven-surefire
mvn -DskipTests install
cd surefire-integration-tests

# ready to rock
mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
clean install # works
less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
# Shows log content
mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto
clean install # fails
less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt
# empty file

This would seem to be the Embedded3xLauncher in verifier that does not
work with 3.1

I assume this might be an issue for other scenarios too

Kristian



2012/12/4 Kristian Rosenvold :
> There is something wrong with logging in embedded mode; when runnin
> surefire tests with verifier
> I am no longer able to pick up log output from the running maven process:
>
>
>
>
> 2012/12/4 Anders Hammar :
>> Is the site updated? It says it was published Nov 15 and some info doesn't
>> seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).
>>
>> /Anders
>>
>>
>> On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:
>>
>>> Hi,
>>>
>>> Here is a link to Jira with 42 issues resolved:
>>>
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-110/
>>>
>>> The distributable binaries and sources for testing can be found here:
>>>
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
>>>
>>> Specifically the zip, tarball, and source archives can be found here:
>>>
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>>
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>>
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>>
>>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
>>>
>>> Staging site:
>>> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
>>>
>>> The documentation specifically for this release pertains to JSR330 and
>>> SLF4J-based logging:
>>> http://maven.apache.org/maven-jsr330.html
>>> http://maven.apache.org/maven-logging.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>>
>>> People develop abstractions by generalizing from concrete examples.
>>> Every attempt to determine the correct abstraction on paper without
>>> actually developing a running system is doomed to failure. No one
>>> is that smart. A framework is a resuable design, so you develop it by
>>> looking at the things it is supposed to be a design of. The more examples
>>> you look at, the more general your framework will be.
>>>
>>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

There is something wrong with logging in embedded mode; when runnin
surefire tests with verifier
I am no longer able to pick up log output from the running maven process:




2012/12/4 Anders Hammar :
> Is the site updated? It says it was published Nov 15 and some info doesn't
> seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings).
>
> /Anders
>
>
> On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl  wrote:
>
>> Hi,
>>
>> Here is a link to Jira with 42 issues resolved:
>>
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-110/
>>
>> The distributable binaries and sources for testing can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/
>>
>> Specifically the zip, tarball, and source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>
>> https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz
>>
>> Staging site:
>> http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0
>>
>> The documentation specifically for this release pertains to JSR330 and
>> SLF4J-based logging:
>> http://maven.apache.org/maven-jsr330.html
>> http://maven.apache.org/maven-logging.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more examples
>> you look at, the more general your framework will be.
>>
>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: apache/maven-3 at Github

[Olivier Lamy]

I created https://issues.apache.org/jira/browse/INFRA-5579

I wait as I cannot do it myself.

2012/12/4 Anders Hammar :
> This git repo at Github mirrors the old Git repo. Is it possible to change
> that to the new git repo, or should it be removed all together?
>
> /Anders



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org