Re: [VOTE] Maven 3.1.0

[Kristian Rosenvold]

Mirko;

Most of the time the core IT's fail, it seems to be related to stuff
in your local settings.xml. Maybe try to just rename it and see how
that works.

Sometimes the artifact resolution gets stuck
less core-it-suite/target/test-classes/mng-5135/log.txt

will show you what happened to the build of "mng-5135"

Theyt are a bit moody at times.

Kristian



2012/12/7 Mirko Friedenhagen :
> Hello Kristian,
>
> I ran d2fc26066b3e5ceb7912b69ce360fa75a8d9a2bb of the
> maven-integration-testing project using the profiles and:
> a) did not see a big difference in runtime (mvn304 ~ 9:50, mvn310 ~10:29)
> b) had failing tests with 310 *and* 304.
>
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl;
> 2012-12-04 05:03:32+0100)
> Java version: 1.7.0_09, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
>
> Regards Mirko
>
> On Tue, Dec 4, 2012 at 6:52 PM, 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
>>
>
> -
> 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

[Mirko Friedenhagen]

Hello Kristian,

I ran d2fc26066b3e5ceb7912b69ce360fa75a8d9a2bb of the
maven-integration-testing project using the profiles and:
a) did not see a big difference in runtime (mvn304 ~ 9:50, mvn310 ~10:29)
b) had failing tests with 310 *and* 304.

Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl;
2012-12-04 05:03:32+0100)
Java version: 1.7.0_09, vendor: Oracle Corporation
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"

Regards Mirko

On Tue, Dec 4, 2012 at 6:52 PM, 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
>

-
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

[Benson Margulies]

So, it sounds to me like this VOTE is withdrawn, since the RM thinks
that there's a respin needed. It would be nice to see a formal email
communicating this.


On Fri, Dec 7, 2012 at 12:41 PM, ceki  wrote:
> On 07.12.2012 02:34, Jason van Zyl wrote:
>
>
>> One benefit is that it would hopefully fix the Sonar problem. But I'm
>> not sure what the exact behaviour of SLF4J is. Even if a plugin
>> blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar
>> case, I think SLF4J is already loaded. Ceki might want to comment on
>> how that works. If two SLF4J "systems" can run in the same JVM it may
>> work. For the non-SLF4J case it's not using SLF4J, obviously, so there
>> is no need to block it.
>
> SLF4J uses an extremely simple/primitive binding (aka plugin)
> mechanism. When the LoggerFactory class is loaded into memory by a
> given class loader, the first call to the getILoggerFactory() will
> perform initialization. The getILoggerFactory() method is called by
> the getLogger(String) method.
>
> Thus, if LoggerFactory class is loaded into memory N times but various
> class loaders, then LoggerFactory class will be initialized N times,
> under the very likely assumption that the getLogger() method is called
> at least once for each LoggerFactory instance.
>
> HTH,
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> -
> 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

[ceki]

On 07.12.2012 02:34, Jason van Zyl wrote:


> One benefit is that it would hopefully fix the Sonar problem. But I'm
> not sure what the exact behaviour of SLF4J is. Even if a plugin
> blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar
> case, I think SLF4J is already loaded. Ceki might want to comment on
> how that works. If two SLF4J "systems" can run in the same JVM it may
> work. For the non-SLF4J case it's not using SLF4J, obviously, so there
> is no need to block it.

SLF4J uses an extremely simple/primitive binding (aka plugin)
mechanism. When the LoggerFactory class is loaded into memory by a
given class loader, the first call to the getILoggerFactory() will
perform initialization. The getILoggerFactory() method is called by
the getLogger(String) method.

Thus, if LoggerFactory class is loaded into memory N times but various
class loaders, then LoggerFactory class will be initialized N times,
under the very likely assumption that the getLogger() method is called
at least once for each LoggerFactory instance.

HTH,

--
Ceki
65% of statistics are made up on the spot

-
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

[Benson Margulies]

Could we please find an appropriate subject line for this debate,
unless you all are really discussing this design question as part of
the (still?) outstanding vote on 3.1.0?


On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory  wrote:
> Another way of looking at this is whether this kind of behavior change in
> appropriate for a minor release, instead of a major release.
>
>
> On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg  wrote:
>
>> Daniel, please think through these old project scenarios. Those old
>> projects did ship their own slf4j impl + config and parsed their own logs
>> and extracted information. They will now just fall on their knees because
>> the logs are no longer available for them. Instead they will be somewhere
>> in the maven logs which could be anywhere from a plugin point of view.
>>
>>
>> This is not fixed, this is broken imo.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> - Original Message -
>> > From: Daniel Kulp 
>> > To: Maven Developers List 
>> > Cc:
>> > Sent: Friday, December 7, 2012 1:49 PM
>> > Subject: Re: [VOTE] Maven 3.1.0
>> >
>> >
>> >>
>> >>  Again the state of affairs of 3.1.0 today: old projects and plugins
>> which
>> > didnt use slf4j so far don't get any benefit from forcing slf4j on them.
>> And
>> > old projects and plugins which _did_ use slf4j already are now broken
>> with the
>> > current trunk. I cannot see how we can seriously release this to users
>> right
>> > now.
>> >
>> >
>> >
>> > I don't consider them broken.   I consider them fixed.Old plugins
>> that
>> > use SLF4J now get there information properly integrated with the rest of
>> the
>> > maven information.
>> >
>> >
>> > Dan
>> >
>> >
>> >
>> > On Dec 7, 2012, at 7:32 AM, Mark Struberg  wrote:
>> >
>> >>>  The final proposal that I see is where we give a metadata flag
>> >>  (defaults to false)
>> >>>  which if true sets up an isolated classloader for
>> >>  the plugin allowing the plugin to use its own slf4j
>> >>
>> >>  Stephen, this is _almost_ the same as I proposed a month ago. But I'd
>> > do it the other way around as this would be perfectly backward
>> compatible.
>> >>
>> >>  I'll try to explain again what I propose:
>> >>
>> >>  Any plugin could e.g. use a @Slf4JLogger in it's mojo. The
>> > plugin-plugin would transfer this to a true
>> > inside the plugin.xml.
>> >>  In this case, and _only_ in this case we would expose our internal
>> SLF4J to
>> > the plugin.
>> >>
>> >>
>> >>  Older plugins do not need it anyway as they do not use the
>> maven-provided
>> > slf4j yet!
>> >>
>> >>
>> >>  This is a win-win solution imo:
>> >>  * old integration and plugins will still work
>> >>  * new plugins can use slf4j for logging via maven
>> >>
>> >>
>> >>  Again the state of affairs of 3.1.0 today: old projects and plugins
>> which
>> > didnt use slf4j so far don't get any benefit from forcing slf4j on them.
>> And
>> > old projects and plugins which _did_ use slf4j already are now broken
>> with the
>> > current trunk. I cannot see how we can seriously release this to users
>> right
>> > now.
>> >>
>> >>  LieGrue,
>> >>  strub
>> >>
>> >>
>> >>>  
>> >>>  From: Stephen Connolly 
>> >>>  To: Maven Developers List ; Mark Struberg
>> > 
>> >>>  Sent: Friday, December 7, 2012 12:48 PM
>> >>>  Subject: Re: [VOTE] Maven 3.1.0
>> >>>
>> >>>
>> >>>  But not all of those *need to*. At least until now they have needed
>> to,
>> > but going forward they may not need to if we are giving them an slf4j
>> impl to
>> > hang their hat off.
>> >>>
>> >>>
>> >>>  There will always be some special case plugins that have a legitimate
>> > need to do funky logging stuff. We need a strategy for those plugins.
>> >>>
>> >>>
>> >>>  Jason's proposal for those cases was that they should fork a JVM.
>> > That works if you don't need to channel objects back an

Re: [VOTE] Maven 3.1.0

[Gary Gregory]

Another way of looking at this is whether this kind of behavior change in
appropriate for a minor release, instead of a major release.


On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg  wrote:

> Daniel, please think through these old project scenarios. Those old
> projects did ship their own slf4j impl + config and parsed their own logs
> and extracted information. They will now just fall on their knees because
> the logs are no longer available for them. Instead they will be somewhere
> in the maven logs which could be anywhere from a plugin point of view.
>
>
> This is not fixed, this is broken imo.
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Daniel Kulp 
> > To: Maven Developers List 
> > Cc:
> > Sent: Friday, December 7, 2012 1:49 PM
> > Subject: Re: [VOTE] Maven 3.1.0
> >
> >
> >>
> >>  Again the state of affairs of 3.1.0 today: old projects and plugins
> which
> > didnt use slf4j so far don't get any benefit from forcing slf4j on them.
> And
> > old projects and plugins which _did_ use slf4j already are now broken
> with the
> > current trunk. I cannot see how we can seriously release this to users
> right
> > now.
> >
> >
> >
> > I don't consider them broken.   I consider them fixed.Old plugins
> that
> > use SLF4J now get there information properly integrated with the rest of
> the
> > maven information.
> >
> >
> > Dan
> >
> >
> >
> > On Dec 7, 2012, at 7:32 AM, Mark Struberg  wrote:
> >
> >>>  The final proposal that I see is where we give a metadata flag
> >>  (defaults to false)
> >>>  which if true sets up an isolated classloader for
> >>  the plugin allowing the plugin to use its own slf4j
> >>
> >>  Stephen, this is _almost_ the same as I proposed a month ago. But I'd
> > do it the other way around as this would be perfectly backward
> compatible.
> >>
> >>  I'll try to explain again what I propose:
> >>
> >>  Any plugin could e.g. use a @Slf4JLogger in it's mojo. The
> > plugin-plugin would transfer this to a true
> > inside the plugin.xml.
> >>  In this case, and _only_ in this case we would expose our internal
> SLF4J to
> > the plugin.
> >>
> >>
> >>  Older plugins do not need it anyway as they do not use the
> maven-provided
> > slf4j yet!
> >>
> >>
> >>  This is a win-win solution imo:
> >>  * old integration and plugins will still work
> >>  * new plugins can use slf4j for logging via maven
> >>
> >>
> >>  Again the state of affairs of 3.1.0 today: old projects and plugins
> which
> > didnt use slf4j so far don't get any benefit from forcing slf4j on them.
> And
> > old projects and plugins which _did_ use slf4j already are now broken
> with the
> > current trunk. I cannot see how we can seriously release this to users
> right
> > now.
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>>  
> >>>  From: Stephen Connolly 
> >>>  To: Maven Developers List ; Mark Struberg
> > 
> >>>  Sent: Friday, December 7, 2012 12:48 PM
> >>>  Subject: Re: [VOTE] Maven 3.1.0
> >>>
> >>>
> >>>  But not all of those *need to*. At least until now they have needed
> to,
> > but going forward they may not need to if we are giving them an slf4j
> impl to
> > hang their hat off.
> >>>
> >>>
> >>>  There will always be some special case plugins that have a legitimate
> > need to do funky logging stuff. We need a strategy for those plugins.
> >>>
> >>>
> >>>  Jason's proposal for those cases was that they should fork a JVM.
> > That works if you don't need to channel objects back and forth. For some
> of
> > the plugins wanting to do 'live development' style work (I am thinking
> > my jszip.org experiments - I have some plans and experiments that I
> haven't
> > even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then
> have to
> > basically resort to RMI to control the forked JVM... More ports and more
> sockets
> > and more complexity.
> >>>
> >>>
> >>>  The next step I could see is building a fresh classloader up from
> > scratch within the plugin. That *should* work as long as we load a fresh
> set of
> > slf4j-api classes (ceki?) then we are i

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

Daniel, please think through these old project scenarios. Those old projects 
did ship their own slf4j impl + config and parsed their own logs and extracted 
information. They will now just fall on their knees because the logs are no 
longer available for them. Instead they will be somewhere in the maven logs 
which could be anywhere from a plugin point of view. 


This is not fixed, this is broken imo.

LieGrue,
strub



- Original Message -
> From: Daniel Kulp 
> To: Maven Developers List 
> Cc: 
> Sent: Friday, December 7, 2012 1:49 PM
> Subject: Re: [VOTE] Maven 3.1.0
> 
> 
>> 
>>  Again the state of affairs of 3.1.0 today: old projects and plugins which 
> didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
> old projects and plugins which _did_ use slf4j already are now broken with 
> the 
> current trunk. I cannot see how we can seriously release this to users right 
> now.
> 
> 
> 
> I don't consider them broken.   I consider them fixed.    Old plugins that 
> use SLF4J now get there information properly integrated with the rest of the 
> maven information.  
> 
> 
> Dan
> 
> 
> 
> On Dec 7, 2012, at 7:32 AM, Mark Struberg  wrote:
> 
>>>  The final proposal that I see is where we give a metadata flag 
>>  (defaults to false) 
>>>  which if true sets up an isolated classloader for 
>>  the plugin allowing the plugin to use its own slf4j
>> 
>>  Stephen, this is _almost_ the same as I proposed a month ago. But I'd 
> do it the other way around as this would be perfectly backward compatible.
>> 
>>  I'll try to explain again what I propose:
>> 
>>  Any plugin could e.g. use a @Slf4JLogger in it's mojo. The 
> plugin-plugin would transfer this to a true 
> inside the plugin.xml.
>>  In this case, and _only_ in this case we would expose our internal SLF4J to 
> the plugin. 
>> 
>> 
>>  Older plugins do not need it anyway as they do not use the maven-provided 
> slf4j yet!
>> 
>> 
>>  This is a win-win solution imo:
>>  * old integration and plugins will still work
>>  * new plugins can use slf4j for logging via maven
>> 
>> 
>>  Again the state of affairs of 3.1.0 today: old projects and plugins which 
> didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
> old projects and plugins which _did_ use slf4j already are now broken with 
> the 
> current trunk. I cannot see how we can seriously release this to users right 
> now.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>>>  
>>>  From: Stephen Connolly 
>>>  To: Maven Developers List ; Mark Struberg 
>  
>>>  Sent: Friday, December 7, 2012 12:48 PM
>>>  Subject: Re: [VOTE] Maven 3.1.0
>>> 
>>> 
>>>  But not all of those *need to*. At least until now they have needed to, 
> but going forward they may not need to if we are giving them an slf4j impl to 
> hang their hat off.
>>> 
>>> 
>>>  There will always be some special case plugins that have a legitimate 
> need to do funky logging stuff. We need a strategy for those plugins.
>>> 
>>> 
>>>  Jason's proposal for those cases was that they should fork a JVM. 
> That works if you don't need to channel objects back and forth. For some of 
> the plugins wanting to do 'live development' style work (I am thinking 
> my jszip.org experiments - I have some plans and experiments that I haven't 
> even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then have 
> to 
> basically resort to RMI to control the forked JVM... More ports and more 
> sockets 
> and more complexity.
>>> 
>>> 
>>>  The next step I could see is building a fresh classloader up from 
> scratch within the plugin. That *should* work as long as we load a fresh set 
> of 
> slf4j-api classes (ceki?) then we are initialising slf4j a second time in the 
> fresh classloader and we can do as we need. Again complex though one could 
> argue 
> less complex than the RMI route. Plugin developers following this route will 
> have to watch out for the dreaded CCE but at least you are not having to deal 
> with object serialisation and RMI
>>> 
>>> 
>>>  The final proposal that I see is where we give a metadata flag 
> (defaults to false) which if true sets up an isolated classloader for the 
> plugin 
> allowing the plugin to use its own slf4j
>>> 
>>> 
>>>  Note that each proposal above retains the option for plugin developers 
> to use the previous p

Re: [VOTE] Maven 3.1.0

[Daniel Kulp]

> 
> Again the state of affairs of 3.1.0 today: old projects and plugins which 
> didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
> old projects and plugins which _did_ use slf4j already are now broken with 
> the current trunk. I cannot see how we can seriously release this to users 
> right now.



I don't consider them broken.   I consider them fixed.Old plugins that use 
SLF4J now get there information properly integrated with the rest of the maven 
information.  


Dan



On Dec 7, 2012, at 7:32 AM, Mark Struberg  wrote:

>> The final proposal that I see is where we give a metadata flag 
> (defaults to false) 
>> which if true sets up an isolated classloader for 
> the plugin allowing the plugin to use its own slf4j
> 
> Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it 
> the other way around as this would be perfectly backward compatible.
> 
> I'll try to explain again what I propose:
> 
> Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin 
> would transfer this to a true inside the plugin.xml.
> In this case, and _only_ in this case we would expose our internal SLF4J to 
> the plugin. 
> 
> 
> Older plugins do not need it anyway as they do not use the maven-provided 
> slf4j yet!
> 
> 
> This is a win-win solution imo:
> * old integration and plugins will still work
> * new plugins can use slf4j for logging via maven
> 
> 
> Again the state of affairs of 3.1.0 today: old projects and plugins which 
> didnt use slf4j so far don't get any benefit from forcing slf4j on them. And 
> old projects and plugins which _did_ use slf4j already are now broken with 
> the current trunk. I cannot see how we can seriously release this to users 
> right now.
> 
> LieGrue,
> strub
> 
> 
>> ____________
>> From: Stephen Connolly 
>> To: Maven Developers List ; Mark Struberg 
>>  
>> Sent: Friday, December 7, 2012 12:48 PM
>> Subject: Re: [VOTE] Maven 3.1.0
>> 
>> 
>> But not all of those *need to*. At least until now they have needed to, but 
>> going forward they may not need to if we are giving them an slf4j impl to 
>> hang their hat off.
>> 
>> 
>> There will always be some special case plugins that have a legitimate need 
>> to do funky logging stuff. We need a strategy for those plugins.
>> 
>> 
>> Jason's proposal for those cases was that they should fork a JVM. That works 
>> if you don't need to channel objects back and forth. For some of the plugins 
>> wanting to do 'live development' style work (I am thinking my jszip.org 
>> experiments - I have some plans and experiments that I haven't even pushed 
>> to there yet ;-) ) forking a JVM is a bad plan, as you then have to 
>> basically resort to RMI to control the forked JVM... More ports and more 
>> sockets and more complexity.
>> 
>> 
>> The next step I could see is building a fresh classloader up from scratch 
>> within the plugin. That *should* work as long as we load a fresh set of 
>> slf4j-api classes (ceki?) then we are initialising slf4j a second time in 
>> the fresh classloader and we can do as we need. Again complex though one 
>> could argue less complex than the RMI route. Plugin developers following 
>> this route will have to watch out for the dreaded CCE but at least you are 
>> not having to deal with object serialisation and RMI
>> 
>> 
>> The final proposal that I see is where we give a metadata flag (defaults to 
>> false) which if true sets up an isolated classloader for the plugin allowing 
>> the plugin to use its own slf4j
>> 
>> 
>> Note that each proposal above retains the option for plugin developers to 
>> use the previous proposal.
>> 
>> 
>> My vote is that we need to provide a utility library that makes the first 
>> and second proposals facile for plugin developers and we should probably 
>> enable the third option also.
>> 
>> 
>> The correct respecting of tool chains support requires plugin developers to 
>> follow the first route if a tool chain JVM is applied to their plugin and to 
>> use the second when no tool chain JVM is in play... At least for the 
>> jetty:run and tomcat:run style plugins.
>> 
>> 
>> For the sonar style plugins, and my gut says the vast majority of these use 
>> cases the most they will need is the third proposal. Without seeing a 
>> maven-fork-utils api I cannot say that we don't need the third proposal, so 
>> I am forced to conclude that we should support 

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

>The final proposal that I see is where we give a metadata flag 
(defaults to false) 
> which if true sets up an isolated classloader for 
the plugin allowing the plugin to use its own slf4j

Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the 
other way around as this would be perfectly backward compatible.

I'll try to explain again what I propose:

Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would 
transfer this to a true inside the plugin.xml.
In this case, and _only_ in this case we would expose our internal SLF4J to the 
plugin. 


Older plugins do not need it anyway as they do not use the maven-provided slf4j 
yet!


This is a win-win solution imo:
* old integration and plugins will still work
* new plugins can use slf4j for logging via maven


Again the state of affairs of 3.1.0 today: old projects and plugins which didnt 
use slf4j so far don't get any benefit from forcing slf4j on them. And old 
projects and plugins which _did_ use slf4j already are now broken with the 
current trunk. I cannot see how we can seriously release this to users right 
now.

LieGrue,
strub


>
> From: Stephen Connolly 
>To: Maven Developers List ; Mark Struberg 
> 
>Sent: Friday, December 7, 2012 12:48 PM
>Subject: Re: [VOTE] Maven 3.1.0
> 
>
>But not all of those *need to*. At least until now they have needed to, but 
>going forward they may not need to if we are giving them an slf4j impl to hang 
>their hat off.
>
>
>There will always be some special case plugins that have a legitimate need to 
>do funky logging stuff. We need a strategy for those plugins.
>
>
>Jason's proposal for those cases was that they should fork a JVM. That works 
>if you don't need to channel objects back and forth. For some of the plugins 
>wanting to do 'live development' style work (I am thinking my jszip.org 
>experiments - I have some plans and experiments that I haven't even pushed to 
>there yet ;-) ) forking a JVM is a bad plan, as you then have to basically 
>resort to RMI to control the forked JVM... More ports and more sockets and 
>more complexity.
>
>
>The next step I could see is building a fresh classloader up from scratch 
>within the plugin. That *should* work as long as we load a fresh set of 
>slf4j-api classes (ceki?) then we are initialising slf4j a second time in the 
>fresh classloader and we can do as we need. Again complex though one could 
>argue less complex than the RMI route. Plugin developers following this route 
>will have to watch out for the dreaded CCE but at least you are not having to 
>deal with object serialisation and RMI
>
>
>The final proposal that I see is where we give a metadata flag (defaults to 
>false) which if true sets up an isolated classloader for the plugin allowing 
>the plugin to use its own slf4j
>
>
>Note that each proposal above retains the option for plugin developers to use 
>the previous proposal.
>
>
>My vote is that we need to provide a utility library that makes the first and 
>second proposals facile for plugin developers and we should probably enable 
>the third option also.
>
>
>The correct respecting of tool chains support requires plugin developers to 
>follow the first route if a tool chain JVM is applied to their plugin and to 
>use the second when no tool chain JVM is in play... At least for the jetty:run 
>and tomcat:run style plugins.
>
>
>For the sonar style plugins, and my gut says the vast majority of these use 
>cases the most they will need is the third proposal. Without seeing a 
>maven-fork-utils api I cannot say that we don't need the third proposal, so I 
>am forced to conclude that we should support it... IOW I think we need a 
>metadata flag.
>
>
>-Stephen
>
>On Friday, 7 December 2012, Mark Struberg  wrote:
>
>basically all stuff which integrates maven does *funky logging stuff*...
>>
>>
>>
>>
>>- Original Message -
>>> From: Anders Hammar 
>>> To: Maven Developers List 
>>> Cc:
>>> Sent: Friday, December 7, 2012 7:25 AM
>>> Subject: Re: [VOTE] Maven 3.1.0
>>>
>>>>  I'm interested to help working on adding a metadata to enable slf4j
>>>>  visibility
>>>>  from a plugin: by default, slf4j is not visible, plugins are expected to
>>>>  use
>>>>  plugin-api's Log. But if the plugin wants to use core's slf4j, he
>>> would be
>>>>  able to add an annotation in the goal requiring shared core slf4j, then 
>>>> the
>>>>  plugin descriptor would enable slf4j api import from core.
>>>>
>>>
>

Re: [VOTE] Maven 3.1.0

[Stephen Connolly]

But not all of those *need to*. At least until now they have needed to, but
going forward they may not need to if we are giving them an slf4j impl to
hang their hat off.

There will always be some special case plugins that have a legitimate need
to do funky logging stuff. We need a strategy for those plugins.

Jason's proposal for those cases was that they should fork a JVM. That
works if you don't need to channel objects back and forth. For some of the
plugins wanting to do 'live development' style work (I am thinking my
jszip.org experiments - I have some plans and experiments that I haven't
even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then
have to basically resort to RMI to control the forked JVM... More ports and
more sockets and more complexity.

The next step I could see is building a fresh classloader up from scratch
within the plugin. That *should* work as long as we load a fresh set of
slf4j-api classes (ceki?) then we are initialising slf4j a second time in
the fresh classloader and we can do as we need. Again complex though one
could argue less complex than the RMI route. Plugin developers following
this route will have to watch out for the dreaded CCE but at least you are
not having to deal with object serialisation and RMI

The final proposal that I see is where we give a metadata flag (defaults to
false) which if true sets up an isolated classloader for the plugin
allowing the plugin to use its own slf4j

Note that each proposal above retains the option for plugin developers to
use the previous proposal.

My vote is that we need to provide a utility library that makes the first
and second proposals facile for plugin developers and we should probably
enable the third option also.

The correct respecting of tool chains support requires plugin developers to
follow the first route if a tool chain JVM is applied to their plugin and
to use the second when no tool chain JVM is in play... At least for the
jetty:run and tomcat:run style plugins.

For the sonar style plugins, and my gut says the vast majority of these use
cases the most they will need is the third proposal. Without seeing a
maven-fork-utils api I cannot say that we don't need the third proposal, so
I am forced to conclude that we should support it... IOW I think we need a
metadata flag.

-Stephen

On Friday, 7 December 2012, Mark Struberg wrote:

> basically all stuff which integrates maven does *funky logging stuff*...
>
>
>
>
> - Original Message -
> > From: Anders Hammar >
> > To: Maven Developers List >
> > Cc:
> > Sent: Friday, December 7, 2012 7:25 AM
> > Subject: Re: [VOTE] Maven 3.1.0
> >
> >>  I'm interested to help working on adding a metadata to enable slf4j
> >>  visibility
> >>  from a plugin: by default, slf4j is not visible, plugins are expected
> to
> >>  use
> >>  plugin-api's Log. But if the plugin wants to use core's slf4j, he
> > would be
> >>  able to add an annotation in the goal requiring shared core slf4j,
> then the
> >>  plugin descriptor would enable slf4j api import from core.
> >>
> >
> > *If* we go this path, I think the default should be the other way around.
> > I.e., the default would be to use core's slf4j and it's impl. So the
> > plugin
> > developer needs to do an active choice to go outside Maven's logging.
> Sure,
> > this could imply problems with existing plugins doing funky logging stuff
> > (like the Sonar plugin), but I don't really see a problem with those
> > plugins having to release a new version. I think it's more important that
> > we get good defaults than trying to make every existing plugin work as
> they
> > are implemented right now.
> >
> > /Anders
> >
> >
> >>
> >>  Stephen: is this what you have in mind?
> >>
> >>  Regards,
> >>
> >>  Hervé
> >>
> >>  Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
> >>  > I tend to agree. There are two use-cases I see that a plugin has for
> >>  > bundling a logging implementation:
> >>  >
> >>  > 1. They are wanting to shunt the logs from the build tool they are
> >>  invoking
> >>  > on to the user. Typically if they are being good plugins they just
> > take
> >>  the
> >>  > logging output and shunt it onto org.apache.maven.plugin.Log.info()
> >>  >
> >>  > 2. They are wanting to shunt the logs from the build tool (or more
> > likely
> >>  > app server) to a separate file, or tweak the level of logs higher
> than
> >>  INFO
> >>  > for that app server/mojo

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

basically all stuff which integrates maven does *funky logging stuff*...




- Original Message -
> From: Anders Hammar 
> To: Maven Developers List 
> Cc: 
> Sent: Friday, December 7, 2012 7:25 AM
> Subject: Re: [VOTE] Maven 3.1.0
> 
>>  I'm interested to help working on adding a metadata to enable slf4j
>>  visibility
>>  from a plugin: by default, slf4j is not visible, plugins are expected to
>>  use
>>  plugin-api's Log. But if the plugin wants to use core's slf4j, he 
> would be
>>  able to add an annotation in the goal requiring shared core slf4j, then the
>>  plugin descriptor would enable slf4j api import from core.
>> 
> 
> *If* we go this path, I think the default should be the other way around.
> I.e., the default would be to use core's slf4j and it's impl. So the 
> plugin
> developer needs to do an active choice to go outside Maven's logging. Sure,
> this could imply problems with existing plugins doing funky logging stuff
> (like the Sonar plugin), but I don't really see a problem with those
> plugins having to release a new version. I think it's more important that
> we get good defaults than trying to make every existing plugin work as they
> are implemented right now.
> 
> /Anders
> 
> 
>> 
>>  Stephen: is this what you have in mind?
>> 
>>  Regards,
>> 
>>  Hervé
>> 
>>  Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
>>  > I tend to agree. There are two use-cases I see that a plugin has for
>>  > bundling a logging implementation:
>>  >
>>  > 1. They are wanting to shunt the logs from the build tool they are
>>  invoking
>>  > on to the user. Typically if they are being good plugins they just 
> take
>>  the
>>  > logging output and shunt it onto org.apache.maven.plugin.Log.info()
>>  >
>>  > 2. They are wanting to shunt the logs from the build tool (or more 
> likely
>>  > app server) to a separate file, or tweak the level of logs higher than
>>  INFO
>>  > for that app server/mojo execution as it will just drown the user.
>>  >
>>  > In the first use case, Jason's point is correct. They 
> shouldn't need to
>>  > bundle a logging implementation any more.
>>  >
>>  > The second case, Jason is arguing that they shouldn't be using the 
> Maven
>>  > JVM for running that tool, they should be running it in a forked JVM 
> and
>>  > then they can configure the logging in that JVM. I disagree. Forking a
>>  JVM
>>  > for every little build tool just to control its logging is going to 
> kill
>>  > the build time.
>>  >
>>  > My preference is for a metadata flag that says: Oy! I know what 
> I'm doing
>>  > with logging, so don't pass logging on to me.
>>  >
>>  > While it feels like a "special case" the truth is logging is 
> always, and
>>  > always will be, a special case!
>>  >
>>  > -Stephen
>>  >
>>  > On 30 November 2012 12:09, Benson Margulies 
> 
>>  wrote:
>>  > > On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
> 
>>  wrote:
>>  > > > 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 implementation specifics in a system you're embedded in 
> is not
>>  good
>>  > > e.g. Logback in Sonar running in Maven using SLF4J Simple. If you 
> want
>>  to
>>  > > your own logging thing while being invoked by Maven then you fork 
> the
>>  JVM
>>  > > and then you can do whatever you want.
>>  > >
>>  > > >> I read Olivier's point to be this: it would be cool 
> if we could
>>  think
>>  > > >> of a way for a plugin to use the slf4j API and remain 
> independent of
>>  > > >> the logging workings of the maven core.
>>  > > >
>>  > > > I think you mean remain independent of the SLF4J implemented 
> used by
>>  > >
>>  > > Maven's core.
>>  > >
>>  > > > Sure, but my counter line of argument would be is that 
>

Re: [VOTE] Maven 3.1.0

[ceki]

On 07.12.2012 07:25, Anders Hammar wrote:


*If* we go this path, I think the default should be the other way around.
I.e., the default would be to use core's slf4j and it's impl. So the plugin
developer needs to do an active choice to go outside Maven's logging. Sure,
this could imply problems with existing plugins doing funky logging stuff
(like the Sonar plugin), but I don't really see a problem with those
plugins having to release a new version. I think it's more important that
we get good defaults than trying to make every existing plugin work as they
are implemented right now.


Very nicely put.


/Anders


--
Ceki
65% of statistics are made up on the spot

-
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

[Stephen Connolly]

On Friday, 7 December 2012, Anders Hammar wrote:

> > I'm interested to help working on adding a metadata to enable slf4j
> > visibility
> > from a plugin: by default, slf4j is not visible, plugins are expected to
> > use
> > plugin-api's Log. But if the plugin wants to use core's slf4j, he would
> be
> > able to add an annotation in the goal requiring shared core slf4j, then
> the
> > plugin descriptor would enable slf4j api import from core.
> >
>
> *If* we go this path, I think the default should be the other way around.
> I.e., the default would be to use core's slf4j and it's impl. So the plugin
> developer needs to do an active choice to go outside Maven's logging.


+1


> Sure,
> this could imply problems with existing plugins doing funky logging stuff
> (like the Sonar plugin), but I don't really see a problem with those
> plugins having to release a new version. I think it's more important that
> we get good defaults than trying to make every existing plugin work as they
> are implemented right now.
>
> /Anders
>
>
> >
> > Stephen: is this what you have in mind?
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
> > > I tend to agree. There are two use-cases I see that a plugin has for
> > > bundling a logging implementation:
> > >
> > > 1. They are wanting to shunt the logs from the build tool they are
> > invoking
> > > on to the user. Typically if they are being good plugins they just take
> > the
> > > logging output and shunt it onto org.apache.maven.plugin.Log.info()
> > >
> > > 2. They are wanting to shunt the logs from the build tool (or more
> likely
> > > app server) to a separate file, or tweak the level of logs higher than
> > INFO
> > > for that app server/mojo execution as it will just drown the user.
> > >
> > > In the first use case, Jason's point is correct. They shouldn't need to
> > > bundle a logging implementation any more.
> > >
> > > The second case, Jason is arguing that they shouldn't be using the
> Maven
> > > JVM for running that tool, they should be running it in a forked JVM
> and
> > > then they can configure the logging in that JVM. I disagree. Forking a
> > JVM
> > > for every little build tool just to control its logging is going to
> kill
> > > the build time.
> > >
> > > My preference is for a metadata flag that says: Oy! I know what I'm
> doing
> > > with logging, so don't pass logging on to me.
> > >
> > > While it feels like a "special case" the truth is logging is always,
> and
> > > always will be, a special case!
> > >
> > > -Stephen
> > >
> > > On 30 November 2012 12:09, Benson Margulies 
> > wrote:
> > > > On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
> > wrote:
> > > > > 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
> > on
> > > > SLF4J implementation specifics in a system you're embedded in is not
> > good
> > > > e.g. Logback in Sonar running in Maven using SLF4J Simple. If you
> want
> > to
> > > > your own logging thing while being invoked by Maven then you fork the
> > JVM
> > > > and then you can do whatever you want.
> > > >
> > > > >> I read Olivier's point to be this: it would be cool if we could
> > think
> > > > >> of a way for a plugin to use the slf4j API and remain independent
> of
> > > > >> the logging workings of the maven core.
> > > > >
> > > > > I think you mean remain independent of the SLF4J implemented used
> by
> > > >
> > > > Maven's core.
> > > >
> > > > > Sure, but my counter line of argument would be is that really
> valid?
> > If
> > > >
> > > > you are running in the context of Maven and you're using SLF4J I
> think
> > you
> > > > should defer to what Maven has setup.
> > > >
> > > > >> As things are, that could be
> > > > >> done only, I think, by using shade to  rename a copy of slf4j for
> > the
> > > > >> guts of the plugin.
> > > > >
> > > > > We have the capability in the core, that is OSGi-esque, that allows
> > us
> > > >
> > > > to block classes from being accessible to plugins. We can block/allow
> > any
> > > > classes we choose: we can effectively make anything invisible to
> > plugins
>

Re: [VOTE] Maven 3.1.0

[Anders Hammar]

> I'm interested to help working on adding a metadata to enable slf4j
> visibility
> from a plugin: by default, slf4j is not visible, plugins are expected to
> use
> plugin-api's Log. But if the plugin wants to use core's slf4j, he would be
> able to add an annotation in the goal requiring shared core slf4j, then the
> plugin descriptor would enable slf4j api import from core.
>

*If* we go this path, I think the default should be the other way around.
I.e., the default would be to use core's slf4j and it's impl. So the plugin
developer needs to do an active choice to go outside Maven's logging. Sure,
this could imply problems with existing plugins doing funky logging stuff
(like the Sonar plugin), but I don't really see a problem with those
plugins having to release a new version. I think it's more important that
we get good defaults than trying to make every existing plugin work as they
are implemented right now.

/Anders


>
> Stephen: is this what you have in mind?
>
> Regards,
>
> Hervé
>
> Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
> > I tend to agree. There are two use-cases I see that a plugin has for
> > bundling a logging implementation:
> >
> > 1. They are wanting to shunt the logs from the build tool they are
> invoking
> > on to the user. Typically if they are being good plugins they just take
> the
> > logging output and shunt it onto org.apache.maven.plugin.Log.info()
> >
> > 2. They are wanting to shunt the logs from the build tool (or more likely
> > app server) to a separate file, or tweak the level of logs higher than
> INFO
> > for that app server/mojo execution as it will just drown the user.
> >
> > In the first use case, Jason's point is correct. They shouldn't need to
> > bundle a logging implementation any more.
> >
> > The second case, Jason is arguing that they shouldn't be using the Maven
> > JVM for running that tool, they should be running it in a forked JVM and
> > then they can configure the logging in that JVM. I disagree. Forking a
> JVM
> > for every little build tool just to control its logging is going to kill
> > the build time.
> >
> > My preference is for a metadata flag that says: Oy! I know what I'm doing
> > with logging, so don't pass logging on to me.
> >
> > While it feels like a "special case" the truth is logging is always, and
> > always will be, a special case!
> >
> > -Stephen
> >
> > On 30 November 2012 12:09, Benson Margulies 
> wrote:
> > > On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
> wrote:
> > > > 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 implementation specifics in a system you're embedded in is not
> good
> > > e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want
> to
> > > your own logging thing while being invoked by Maven then you fork the
> JVM
> > > and then you can do whatever you want.
> > >
> > > >> I read Olivier's point to be this: it would be cool if we could
> think
> > > >> of a way for a plugin to use the slf4j API and remain independent of
> > > >> the logging workings of the maven core.
> > > >
> > > > I think you mean remain independent of the SLF4J implemented used by
> > >
> > > Maven's core.
> > >
> > > > Sure, but my counter line of argument would be is that really valid?
> If
> > >
> > > you are running in the context of Maven and you're using SLF4J I think
> you
> > > should defer to what Maven has setup.
> > >
> > > >> As things are, that could be
> > > >> done only, I think, by using shade to  rename a copy of slf4j for
> the
> > > >> guts of the plugin.
> > > >
> > > > We have the capability in the core, that is OSGi-esque, that allows
> us
> > >
> > > to block classes from being accessible to plugins. We can block/allow
> any
> > > classes we choose: we can effectively make anything invisible to
> plugins
> > > if
> > > we choose. This capability was added to Classworlds some time ago.
> > >
> > > >> If I were less sleep-deprived, I might be able to
> > > >> put forth an idea about how an enhancement to slf4j could allow
> > > >> everyone to be happy here, but I don't see a way to make everyone
> > > >> happy as things are.
> > > >>
> > > >> My personal view is that 'giant subsystem' plugins are rarities at
> > > >> most, and the attraction of saying 'the Maven logging API *is*
> slf4j'
> > > >> outweighs for me the problems.
> > > >
> > > > I think everyone agrees there, it's really now a matter would we let
> > >
> > > plugins pick and use a different implementation than the core.
> > >
> > > >> However, another possibility that occurs to me is this:
> > > >>
> > > >> Allow a plugin's metadata to say: 'please leave slf4j isolated
> here'.
> > > >> Such a plugin could only log to the Maven log t

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

On Dec 6, 2012, at 4:34 PM, Hervé BOUTEMY  wrote:

> I'm interested to help working on adding a metadata to enable slf4j 
> visibility 
> from a plugin: by default, slf4j is not visible, plugins are expected to use 
> plugin-api's Log. But if the plugin wants to use core's slf4j, he would be 
> able to add an annotation in the goal requiring shared core slf4j, then the 
> plugin descriptor would enable slf4j api import from core.
> 

I sent a mail a while back with how the internals but here are the things you 
should know:

- We export the SLF4J API currently, and we do not export the implementation
- The user gets the implementation used by the core through Mojo.getLog(), or 
by injecting an SLF4J logger
- SLF4J once initialized cannot change the implementation so there isn't going 
to be any deciding by the user to use something else, it's not possible after 
initialization

If you want to try and block the SLF4J API then you'll have to dynamically 
change what packages get imported into the plugin realm. The ClassRealm manager 
already gets injected into the plugin manager and you could look at the 
annotation and alter the the realm created accordingly in 
DefaultMavenPluginManager.calcImports().

Is this a good idea. I don't really think so but give it a whirl. It means that 
the logging for the plugin won't be integrated so if someone uses the -l option 
and the rest of the input goes once place and some plugins go to another. I 
also don't know what other side effects so I think it would be wise to see what 
actually happens.

One benefit is that it would hopefully fix the Sonar problem. But I'm not sure 
what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely 
to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already 
loaded. Ceki might want to comment on how that works. If two SLF4J "systems" 
can run in the same JVM it may work. For the non-SLF4J case it's not using 
SLF4J, obviously, so there is no need to block it.

So if the desire is to allow for a plugin to do its own SLF4J thing you'll want 
to investigate if it's possible. If it's not then I don't think anything needs 
to change from how it currently is. If you can make Sonar work, it's worth it 
the effort.

> Stephen: is this what you have in mind?
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
>> I tend to agree. There are two use-cases I see that a plugin has for
>> bundling a logging implementation:
>> 
>> 1. They are wanting to shunt the logs from the build tool they are invoking
>> on to the user. Typically if they are being good plugins they just take the
>> logging output and shunt it onto org.apache.maven.plugin.Log.info()
>> 
>> 2. They are wanting to shunt the logs from the build tool (or more likely
>> app server) to a separate file, or tweak the level of logs higher than INFO
>> for that app server/mojo execution as it will just drown the user.
>> 
>> In the first use case, Jason's point is correct. They shouldn't need to
>> bundle a logging implementation any more.
>> 
>> The second case, Jason is arguing that they shouldn't be using the Maven
>> JVM for running that tool, they should be running it in a forked JVM and
>> then they can configure the logging in that JVM. I disagree. Forking a JVM
>> for every little build tool just to control its logging is going to kill
>> the build time.
>> 
>> My preference is for a metadata flag that says: Oy! I know what I'm doing
>> with logging, so don't pass logging on to me.
>> 
>> While it feels like a "special case" the truth is logging is always, and
>> always will be, a special case!
>> 
>> -Stephen
>> 
>> On 30 November 2012 12:09, Benson Margulies  wrote:
>>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
 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 implementation specifics in a system you're embedded in is not good
>>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to
>>> your own logging thing while being invoked by Maven then you fork the JVM
>>> and then you can do whatever you want.
>>> 
> I read Olivier's point to be this: it would be cool if we could think
> of a way for a plugin to use the slf4j API and remain independent of
> the logging workings of the maven core.
 
 I think you mean remain independent of the SLF4J implemented used by
>>> 
>>> Maven's core.
>>> 
 Sure, but my counter line of argument would be is that really valid? If
>>> 
>>> you are running in the context of Maven and you're using SLF4J I think you
>>> should defer to what Maven has setup.
>>> 
> As things are, that could be
> done only, I think, by using shade to  rename a copy of

Re: [VOTE] Maven 3.1.0

[Hervé BOUTEMY]

I'm interested to help working on adding a metadata to enable slf4j visibility 
from a plugin: by default, slf4j is not visible, plugins are expected to use 
plugin-api's Log. But if the plugin wants to use core's slf4j, he would be 
able to add an annotation in the goal requiring shared core slf4j, then the 
plugin descriptor would enable slf4j api import from core.

Stephen: is this what you have in mind?

Regards,

Hervé

Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit :
> I tend to agree. There are two use-cases I see that a plugin has for
> bundling a logging implementation:
> 
> 1. They are wanting to shunt the logs from the build tool they are invoking
> on to the user. Typically if they are being good plugins they just take the
> logging output and shunt it onto org.apache.maven.plugin.Log.info()
> 
> 2. They are wanting to shunt the logs from the build tool (or more likely
> app server) to a separate file, or tweak the level of logs higher than INFO
> for that app server/mojo execution as it will just drown the user.
> 
> In the first use case, Jason's point is correct. They shouldn't need to
> bundle a logging implementation any more.
> 
> The second case, Jason is arguing that they shouldn't be using the Maven
> JVM for running that tool, they should be running it in a forked JVM and
> then they can configure the logging in that JVM. I disagree. Forking a JVM
> for every little build tool just to control its logging is going to kill
> the build time.
> 
> My preference is for a metadata flag that says: Oy! I know what I'm doing
> with logging, so don't pass logging on to me.
> 
> While it feels like a "special case" the truth is logging is always, and
> always will be, a special case!
> 
> -Stephen
> 
> On 30 November 2012 12:09, Benson Margulies  wrote:
> > On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
> > > 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 implementation specifics in a system you're embedded in is not good
> > e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to
> > your own logging thing while being invoked by Maven then you fork the JVM
> > and then you can do whatever you want.
> > 
> > >> I read Olivier's point to be this: it would be cool if we could think
> > >> of a way for a plugin to use the slf4j API and remain independent of
> > >> the logging workings of the maven core.
> > > 
> > > I think you mean remain independent of the SLF4J implemented used by
> > 
> > Maven's core.
> > 
> > > Sure, but my counter line of argument would be is that really valid? If
> > 
> > you are running in the context of Maven and you're using SLF4J I think you
> > should defer to what Maven has setup.
> > 
> > >> As things are, that could be
> > >> done only, I think, by using shade to  rename a copy of slf4j for the
> > >> guts of the plugin.
> > > 
> > > We have the capability in the core, that is OSGi-esque, that allows us
> > 
> > to block classes from being accessible to plugins. We can block/allow any
> > classes we choose: we can effectively make anything invisible to plugins
> > if
> > we choose. This capability was added to Classworlds some time ago.
> > 
> > >> If I were less sleep-deprived, I might be able to
> > >> put forth an idea about how an enhancement to slf4j could allow
> > >> everyone to be happy here, but I don't see a way to make everyone
> > >> happy as things are.
> > >> 
> > >> My personal view is that 'giant subsystem' plugins are rarities at
> > >> most, and the attraction of saying 'the Maven logging API *is* slf4j'
> > >> outweighs for me the problems.
> > > 
> > > I think everyone agrees there, it's really now a matter would we let
> > 
> > plugins pick and use a different implementation than the core.
> > 
> > >> However, another possibility that occurs to me is this:
> > >> 
> > >> Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
> > >> Such a plugin could only log to the Maven log through the Mojo log
> > >> API.
> > > 
> > > That's the magic I would like to avoid. Anything is possible but I would
> > 
> > prefer how a plugin author should integrate with our SLF4J logging.
> > 
> > Here's the crux of the disagreement. To be clear, I'm not trying to
> > derail any 3.1.0 trains here, just thinking ahead.
> > 
> > A logging framework is a tool for collecting and distributing
> > information. When someone plugs 'thing X' into Maven, I don't think
> > that it follows, necessarily, that their application of a logging
> > framework necessarily aligns with ours. We are logging 'the build' --
> > they are logging 'whatever it is that they are doing'. They may log
> > thousands of messages at 'INFO' that are only interesting to some
> > progra

Re: [VOTE] Maven 3.1.0

[Igor Fedorenko]

Minor problem, but I just noticed that wagon-http-2.3-shaded.jar and
wagon-provider-api-2.3.jar include what looks like test-related files
inside them.

--
Regards,
Igor

On 12-12-03 11:10 PM, 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

[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: [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: [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: [VOTE] Maven 3.1.0

[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
>
>

Re: [VOTE] Maven 3.1.0

[Jesse Glick]

On 11/28/2012 11:04 AM, Arnaud Héritier wrote:

there are only few bug fixes


For the affected users, MNG-5312 [1] is pretty serious.

[1] https://jira.codehaus.org/browse/MNG-5312


-
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 Struberg]

In that case the users cannot use plain slf4j APIs and we would not gain 
anything anyway.

This would have the same effect like not exposing the classes in our core realm 
at all.

LieGrue,
strub



>
> From: Arnaud Héritier 
>To: Maven Developers List ; Mark Struberg 
> 
>Sent: Saturday, December 1, 2012 11:20 AM
>Subject: Re: [VOTE] Maven 3.1.0
> 
>
>Couldn't we use the shading plugin to not expose the original implementation 
>(logback, log4k, whatever ..) but a repackaged one to avoid conflicts with 
>plugins which may bring (intentionally or by error) its own impl ? ?
>Perhaps my idea is just stupid ...
>
>
>Arnaud
>
>
>
>On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg  wrote:
>
>what is complex with say am openjpa enhancer mojo?
>>Still this will break depending what the project configures in it's 
>>persistence.xml.
>>
>>Just an idea for now:
>>The safe route might be a plugin-plugin annotatation which tells us 'plugin 
>>uses slf4j' in that case it gets exposed, in other cases it doesn't.
>>
>>Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will 
>>evaluate it and add slf4j injection support for those plugins.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>- Original Message -
>>
>>> From: Benson Margulies 
>>> To: Maven Developers List 
>>> Cc:
>>
>>> Sent: Friday, November 30, 2012 10:15 PM
>>> Subject: Re: [VOTE] Maven 3.1.0
>>>
>>
>>> At the end of the day, either Maven uses a standard logging API inside
>>> plugins, or it does not. Using a standard logging API has giant
>>> advantages - but it can inconvenience people integrating complex code
>>> via plugins.
>>>
>>> In this thread, there are two approaches to removing that
>>> inconvenience: a plugin annotation that changing the logging
>>> integration, and use of forking. Both work. I have some sympathy for
>>> the view that anything complex enough to care should fork. When people
>>> integrate big complex things, it has unpleasant consequences like
>>> System.exit() calls.
>>>
>>> So I'm entirely +1 for the code as it stands, and I see adding an
>>> annotation or something to avoid injecting the logging back end as a
>>> nice to have. As I wrote before, I'd feel better about the 'stick a
>>> fork' in it prescription if we had better reusable forking code.
>>>
>>> -
>>> 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
>
>
>

-
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

[Arnaud Héritier]

Couldn't we use the shading plugin to not expose the original
implementation (logback, log4k, whatever ..) but a repackaged one to avoid
conflicts with plugins which may bring (intentionally or by error) its own
impl ? ?
Perhaps my idea is just stupid ...

Arnaud


On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg  wrote:

> what is complex with say am openjpa enhancer mojo?
> Still this will break depending what the project configures in it's
> persistence.xml.
>
> Just an idea for now:
> The safe route might be a plugin-plugin annotatation which tells us
> 'plugin uses slf4j' in that case it gets exposed, in other cases it doesn't.
>
> Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will
> evaluate it and add slf4j injection support for those plugins.
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Benson Margulies 
> > To: Maven Developers List 
> > Cc:
> > Sent: Friday, November 30, 2012 10:15 PM
> > Subject: Re: [VOTE] Maven 3.1.0
> >
> > At the end of the day, either Maven uses a standard logging API inside
> > plugins, or it does not. Using a standard logging API has giant
> > advantages - but it can inconvenience people integrating complex code
> > via plugins.
> >
> > In this thread, there are two approaches to removing that
> > inconvenience: a plugin annotation that changing the logging
> > integration, and use of forking. Both work. I have some sympathy for
> > the view that anything complex enough to care should fork. When people
> > integrate big complex things, it has unpleasant consequences like
> > System.exit() calls.
> >
> > So I'm entirely +1 for the code as it stands, and I see adding an
> > annotation or something to avoid injecting the logging back end as a
> > nice to have. As I wrote before, I'd feel better about the 'stick a
> > fork' in it prescription if we had better reusable forking code.
> >
> > -
> > 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

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

what is complex with say am openjpa enhancer mojo?
Still this will break depending what the project configures in it's 
persistence.xml.

Just an idea for now:
The safe route might be a plugin-plugin annotatation which tells us 'plugin 
uses slf4j' in that case it gets exposed, in other cases it doesn't.

Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will 
evaluate it and add slf4j injection support for those plugins.

LieGrue,
strub



- Original Message -
> From: Benson Margulies 
> To: Maven Developers List 
> Cc: 
> Sent: Friday, November 30, 2012 10:15 PM
> Subject: Re: [VOTE] Maven 3.1.0
> 
> At the end of the day, either Maven uses a standard logging API inside
> plugins, or it does not. Using a standard logging API has giant
> advantages - but it can inconvenience people integrating complex code
> via plugins.
> 
> In this thread, there are two approaches to removing that
> inconvenience: a plugin annotation that changing the logging
> integration, and use of forking. Both work. I have some sympathy for
> the view that anything complex enough to care should fork. When people
> integrate big complex things, it has unpleasant consequences like
> System.exit() calls.
> 
> So I'm entirely +1 for the code as it stands, and I see adding an
> annotation or something to avoid injecting the logging back end as a
> nice to have. As I wrote before, I'd feel better about the 'stick a
> fork' in it prescription if we had better reusable forking code.
> 
> -
> 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

[Benson Margulies]

At the end of the day, either Maven uses a standard logging API inside
plugins, or it does not. Using a standard logging API has giant
advantages - but it can inconvenience people integrating complex code
via plugins.

In this thread, there are two approaches to removing that
inconvenience: a plugin annotation that changing the logging
integration, and use of forking. Both work. I have some sympathy for
the view that anything complex enough to care should fork. When people
integrate big complex things, it has unpleasant consequences like
System.exit() calls.

So I'm entirely +1 for the code as it stands, and I see adding an
annotation or something to avoid injecting the logging back end as a
nice to have. As I wrote before, I'd feel better about the 'stick a
fork' in it prescription if we had better reusable forking code.

-
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]

Anything is possible but I honestly don't want to do it because I don't really 
think it's worth it. Just use SLF4J properly, that's your path. I don't think 
this is really that onerous and deprives developers of their liberty :-) So 
many systems use SLF4J and I don't think many of them allow magic 
implementation selection. I don't think we're any different.

On Nov 30, 2012, at 1:07 PM, Mark Derricutt  wrote:

> Would it be possible to implement something (nasty and rather iki under the 
> covers) along the lines of using say a 
> MavenLoggerFactory.getLogger(Foo.class, ImplementationClass.class, String 
> config).
> 
> If this variation is used to get a Logger, use ClassWorlds or something to 
> create a new classloader -excluding- the system SLF4J setup, and using the 
> caller is requesting.
> 
> Is something like that possible at all?
> 
> 
> Jason van Zyl wrote:
>> I don't believe it's valid to just let everyone do whatever they want. The 
>> only problem we've seen thus far is a problem where it's clearly a misuse of 
>> the SLF4J API. I still argue that the implementation used by the core can be 
>> used by plugins and letting arbitrary implementations and arbitrary 
>> manipulation of the logging system isn't really that valuable in compared to 
>> having a a consistent pattern that's used by so many others.
> 
> -
> 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
-

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: [VOTE] Maven 3.1.0

[Mark Derricutt]

Would it be possible to implement something (nasty and rather iki under 
the covers) along the lines of using say a 
MavenLoggerFactory.getLogger(Foo.class, ImplementationClass.class, 
String config).


If this variation is used to get a Logger, use ClassWorlds or something 
to create a new classloader -excluding- the system SLF4J setup, and 
using the caller is requesting.


Is something like that possible at all?


Jason van Zyl wrote:

I don't believe it's valid to just let everyone do whatever they want. The only 
problem we've seen thus far is a problem where it's clearly a misuse of the 
SLF4J API. I still argue that the implementation used by the core can be used 
by plugins and letting arbitrary implementations and arbitrary manipulation of 
the logging system isn't really that valuable in compared to having a a 
consistent pattern that's used by so many others.


-
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

[Manfred Moser]

On Fri, November 30, 2012 12:33 pm, Mark Struberg wrote:
>
>>I don't believe it's valid to just let everyone do whatever they want.
>
> Well, I think this is the fundamental point we disagree on.
> Maven is not only a build system but also a container which runs user
> specific stuff. And a container should try to isolate as much internal
> details from it's users as he can. So yes, imo we should let everyone do
> whatever they want!

Hm... as far as I am concerned Maven is all about convention over
configuration and telling users what is best for them and NOT letting them
do whatever they want. Thats what Ant and Gradle are for.

> By forcing some specific logging mechanism on any users we will heavily
> restrict plugin programmers. And sometimes even the plugin programmers
> cannot change anything because the are only 'users' of the library the
> plugin uses.

I have been working on the Android plugin for a long time and I never saw
the need to doodle around or worry about logging. I just want Maven to
deal with it for me.

> I personally believe we will introduce quite some backward
> incompatibility.

Yes... maybe, but even if .. that might not be such a bad idea. The more
reasons we have to get users to upgrade to latest and greatest versions of
Maven the better coverage of it we get and the more relevant feedback to
fix things that actually matter.

manfred


-
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]

On Nov 30, 2012, at 12:33 PM, Mark Struberg  wrote:

> 
>> I don't believe it's valid to just let everyone do whatever they want.
> 
> Well, I think this is the fundamental point we disagree on.
> Maven is not only a build system

No, but the only other one people are contemplating using, Gradle, also uses 
SLF4J.

> but also a container which runs user specific stuff. And a container should 
> try to isolate as much internal details from it's users as he can. So yes, 
> imo we should let everyone do whatever they want! 
> 
> By forcing some specific logging mechanism on any users we will heavily 
> restrict plugin programmers. And sometimes even the plugin programmers cannot 
> change anything because the are only 'users' of the library the plugin uses.

Then systems change to integrate and over time that will happen. The only issue 
is if they use SLF4J as the API and assume an implementation, otherwise their 
own custom logging stuff will kick in. I don't think misusing SLF4J is our 
problem really. Unfortunately Sonar will get dinged but dynamically flipping 
implementations isn't something SLF4J does and really it's not something any 
logging framework has really done is it? 

> 
> 
> I personally believe we will introduce quite some backward incompatibility.
> Plugins which didn't use slf4j will not see any difference. And plugins and 
> frameworks which used slf4j will loose control over their logging.
> 
> I'd be happy to be proved wrong...

We are discussing and implementing different solutions so give your theory a 
try. No one here is in a dire rush here but I think we have something that's 
viable. There will always be exceptions but for the most part I believe what we 
have will work. 

> 
> LieGrue,
> strub
> 
>> ____
>> From: Jason van Zyl 
>> To: Maven Developers List ; Mark Struberg 
>>  
>> Sent: Friday, November 30, 2012 9:08 PM
>> Subject: Re: [VOTE] Maven 3.1.0
>> 
>> 
>> 
>> 
>> On Nov 30, 2012, at 11:55 AM, Mark Struberg  wrote:
>> 
>> That's all broken by design as already predicted 2 months ago.
>>> 
>>> 
>> 
>> 
>> It is not broken by design and you're not being helpful. Retreating into 
>> trying to implement all this ourselves is not a solution. Try it Mark, 
>> implement your system and ignore everything that's been done and I predict 
>> you're going to end up in the exact same place because integrating many 
>> systems in a common way is hard. This is the nitty gritty of integration, 
>> it's ugly to make it work but that's always the way it is.
>> 
>> 
>> We're still going to end up in the same place and it's not impossible to 
>> change the way the binding works in SLF4J and it's been requested, but the 
>> entire world of use of SLF4J doesn't seem to see it as a problem.
>> 
>> Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
>> The other way would be to introduce a plugin-plugin configuration which says 
>> logging yes/no.
>>> 
>>> 
>> 
>> 
>> I don't believe it's valid to just let everyone do whatever they want. The 
>> only problem we've seen thus far is a problem where it's clearly a misuse of 
>> the SLF4J API. I still argue that the implementation used by the core can be 
>> used by plugins and letting arbitrary implementations and arbitrary 
>> manipulation of the logging system isn't really that valuable in compared to 
>> having a a consistent pattern that's used by so many others.
>> 
>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
>>> From: Stephen Connolly 
>>>> To: Maven Developers List 
>>>> Cc: 
>>>> Sent: Friday, November 30, 2012 8:15 PM
>>>> Subject: Re: [VOTE] Maven 3.1.0
>>>> 
>>>> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
>>>> 
>>>> Currently 3.0.4 does not provide either the api or an impl, so I need both
>>>> as a dependency..,
>>>> 
>>>> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
>>>> and part of the plugin jar (because it makes most sense to scope it there)
>>>> 
>>>> What happens when that runs on 3.1.0?
>>>> 
>>>> Oh and in my custom slf4j impl I actuall knock all the logging levels down
>>>> by 1, because this tool I am using is t

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

>I don't believe it's valid to just let everyone do whatever they want.

Well, I think this is the fundamental point we disagree on.
Maven is not only a build system but also a container which runs user specific 
stuff. And a container should try to isolate as much internal details from it's 
users as he can. So yes, imo we should let everyone do whatever they want! 

By forcing some specific logging mechanism on any users we will heavily 
restrict plugin programmers. And sometimes even the plugin programmers cannot 
change anything because the are only 'users' of the library the plugin uses.


I personally believe we will introduce quite some backward incompatibility.
Plugins which didn't use slf4j will not see any difference. And plugins and 
frameworks which used slf4j will loose control over their logging.

I'd be happy to be proved wrong...

LieGrue,
strub

>
> From: Jason van Zyl 
>To: Maven Developers List ; Mark Struberg 
> 
>Sent: Friday, November 30, 2012 9:08 PM
>Subject: Re: [VOTE] Maven 3.1.0
> 
>
>
>
>On Nov 30, 2012, at 11:55 AM, Mark Struberg  wrote:
>
>That's all broken by design as already predicted 2 months ago.
>>
>>
>
>
>It is not broken by design and you're not being helpful. Retreating into 
>trying to implement all this ourselves is not a solution. Try it Mark, 
>implement your system and ignore everything that's been done and I predict 
>you're going to end up in the exact same place because integrating many 
>systems in a common way is hard. This is the nitty gritty of integration, it's 
>ugly to make it work but that's always the way it is.
>
>
>We're still going to end up in the same place and it's not impossible to 
>change the way the binding works in SLF4J and it's been requested, but the 
>entire world of use of SLF4J doesn't seem to see it as a problem.
>
>Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
>The other way would be to introduce a plugin-plugin configuration which says 
>logging yes/no.
>>
>>
>
>
>I don't believe it's valid to just let everyone do whatever they want. The 
>only problem we've seen thus far is a problem where it's clearly a misuse of 
>the SLF4J API. I still argue that the implementation used by the core can be 
>used by plugins and letting arbitrary implementations and arbitrary 
>manipulation of the logging system isn't really that valuable in compared to 
>having a a consistent pattern that's used by so many others.
>
>LieGrue,
>>strub
>>
>>
>>
>>
>>- Original Message -
>>
>>From: Stephen Connolly 
>>>To: Maven Developers List 
>>>Cc: 
>>>Sent: Friday, November 30, 2012 8:15 PM
>>>Subject: Re: [VOTE] Maven 3.1.0
>>>
>>>What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
>>>
>>>Currently 3.0.4 does not provide either the api or an impl, so I need both
>>>as a dependency..,
>>>
>>>I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
>>>and part of the plugin jar (because it makes most sense to scope it there)
>>>
>>>What happens when that runs on 3.1.0?
>>>
>>>Oh and in my custom slf4j impl I actuall knock all the logging levels down
>>>by 1, because this tool I am using is too verbose and what it spouts at
>>>INFO is really DEBUG... So bypassing my impl would be a "bad thing" 
>>>for
>>>users
>>>
>>>On Friday, 30 November 2012, Jason van Zyl wrote:
>>>
>>>
>>>For case 2) I would say only fork if your logging is know to interfere
>>>>with standard SLF4J practices which I think would be rare. But I'll see 
>>>>how
>>>
>>>easy it is to implement a flag while I'm looking at this in general.
>>>>
>>>>On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>>>>stephen.alan.conno...@gmail.com> wrote:
>>>>
>>>>
>>>>I tend to agree. There are two use-cases I see that a plugin has for
>>>>>bundling a logging implementation:
>>>>>
>>>>>1. They are wanting to shunt the logs from the build tool they are
>>>>>
invoking
>>>>
>>>>on to the user. Typically if they are being good plugins they just 
>>>>>take
>>>
>>>the
>>>>
>>>>logging output and shunt it onto org.apache.maven.plugin.Log.info()
>>>>>
>>>>>2. They are wanti

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

On Nov 30, 2012, at 11:55 AM, Mark Struberg  wrote:

> That's all broken by design as already predicted 2 months ago.
> 

It is not broken by design and you're not being helpful. Retreating into trying 
to implement all this ourselves is not a solution. Try it Mark, implement your 
system and ignore everything that's been done and I predict you're going to end 
up in the exact same place because integrating many systems in a common way is 
hard. This is the nitty gritty of integration, it's ugly to make it work but 
that's always the way it is.

We're still going to end up in the same place and it's not impossible to change 
the way the binding works in SLF4J and it's been requested, but the entire 
world of use of SLF4J doesn't seem to see it as a problem.

> Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
> The other way would be to introduce a plugin-plugin configuration which says 
> logging yes/no.
> 

I don't believe it's valid to just let everyone do whatever they want. The only 
problem we've seen thus far is a problem where it's clearly a misuse of the 
SLF4J API. I still argue that the implementation used by the core can be used 
by plugins and letting arbitrary implementations and arbitrary manipulation of 
the logging system isn't really that valuable in compared to having a a 
consistent pattern that's used by so many others.

> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
>> From: Stephen Connolly 
>> To: Maven Developers List 
>> Cc: 
>> Sent: Friday, November 30, 2012 8:15 PM
>> Subject: Re: [VOTE] Maven 3.1.0
>> 
>> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
>> 
>> Currently 3.0.4 does not provide either the api or an impl, so I need both
>> as a dependency..,
>> 
>> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
>> and part of the plugin jar (because it makes most sense to scope it there)
>> 
>> What happens when that runs on 3.1.0?
>> 
>> Oh and in my custom slf4j impl I actuall knock all the logging levels down
>> by 1, because this tool I am using is too verbose and what it spouts at
>> INFO is really DEBUG... So bypassing my impl would be a "bad thing" 
>> for
>> users
>> 
>> On Friday, 30 November 2012, Jason van Zyl wrote:
>> 
>>> For case 2) I would say only fork if your logging is know to interfere
>>> with standard SLF4J practices which I think would be rare. But I'll see 
>> how
>>> easy it is to implement a flag while I'm looking at this in general.
>>> 
>>> On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>> 
>>>> I tend to agree. There are two use-cases I see that a plugin has for
>>>> bundling a logging implementation:
>>>> 
>>>> 1. They are wanting to shunt the logs from the build tool they are
>>> invoking
>>>> on to the user. Typically if they are being good plugins they just 
>> take
>>> the
>>>> logging output and shunt it onto org.apache.maven.plugin.Log.info()
>>>> 
>>>> 2. They are wanting to shunt the logs from the build tool (or more 
>> likely
>>>> app server) to a separate file, or tweak the level of logs higher than
>>> INFO
>>>> for that app server/mojo execution as it will just drown the user.
>>>> 
>>>> In the first use case, Jason's point is correct. They 
>> shouldn't need to
>>>> bundle a logging implementation any more.
>>>> 
>>>> The second case, Jason is arguing that they shouldn't be using the 
>> Maven
>>>> JVM for running that tool, they should be running it in a forked JVM 
>> and
>>>> then they can configure the logging in that JVM. I disagree. Forking a
>>> JVM
>>>> for every little build tool just to control its logging is going to 
>> kill
>>>> the build time.
>>>> 
>>>> My preference is for a metadata flag that says: Oy! I know what 
>> I'm doing
>>>> with logging, so don't pass logging on to me.
>>>> 
>>>> While it feels like a "special case" the truth is logging is 
>> always, and
>>>> always will be, a special case!
>>>> 
>>>> -Stephen
>>>> 
>>>> 
>>>> On 30 November 2012 12:09, Benson Margulies 
>> 
>>> wrote:
>>>> 
>>>&

Re: [VOTE] Maven 3.1.0

[Mark Struberg]

That's all broken by design as already predicted 2 months ago.

Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
The other way would be to introduce a plugin-plugin configuration which says 
logging yes/no.

LieGrue,
strub




- Original Message -
> From: Stephen Connolly 
> To: Maven Developers List 
> Cc: 
> Sent: Friday, November 30, 2012 8:15 PM
> Subject: Re: [VOTE] Maven 3.1.0
> 
> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
> 
> Currently 3.0.4 does not provide either the api or an impl, so I need both
> as a dependency..,
> 
> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
> and part of the plugin jar (because it makes most sense to scope it there)
> 
> What happens when that runs on 3.1.0?
> 
> Oh and in my custom slf4j impl I actuall knock all the logging levels down
> by 1, because this tool I am using is too verbose and what it spouts at
> INFO is really DEBUG... So bypassing my impl would be a "bad thing" 
> for
> users
> 
> On Friday, 30 November 2012, Jason van Zyl wrote:
> 
>>  For case 2) I would say only fork if your logging is know to interfere
>>  with standard SLF4J practices which I think would be rare. But I'll see 
> how
>>  easy it is to implement a flag while I'm looking at this in general.
>> 
>>  On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>>  stephen.alan.conno...@gmail.com> wrote:
>> 
>>  > I tend to agree. There are two use-cases I see that a plugin has for
>>  > bundling a logging implementation:
>>  >
>>  > 1. They are wanting to shunt the logs from the build tool they are
>>  invoking
>>  > on to the user. Typically if they are being good plugins they just 
> take
>>  the
>>  > logging output and shunt it onto org.apache.maven.plugin.Log.info()
>>  >
>>  > 2. They are wanting to shunt the logs from the build tool (or more 
> likely
>>  > app server) to a separate file, or tweak the level of logs higher than
>>  INFO
>>  > for that app server/mojo execution as it will just drown the user.
>>  >
>>  > In the first use case, Jason's point is correct. They 
> shouldn't need to
>>  > bundle a logging implementation any more.
>>  >
>>  > The second case, Jason is arguing that they shouldn't be using the 
> Maven
>>  > JVM for running that tool, they should be running it in a forked JVM 
> and
>>  > then they can configure the logging in that JVM. I disagree. Forking a
>>  JVM
>>  > for every little build tool just to control its logging is going to 
> kill
>>  > the build time.
>>  >
>>  > My preference is for a metadata flag that says: Oy! I know what 
> I'm doing
>>  > with logging, so don't pass logging on to me.
>>  >
>>  > While it feels like a "special case" the truth is logging is 
> always, and
>>  > always will be, a special case!
>>  >
>>  > -Stephen
>>  >
>>  >
>>  > On 30 November 2012 12:09, Benson Margulies 
> 
>>  wrote:
>>  >
>>  >> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl 
>  wrote:
>>  >>>
>>  >>> 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 implementation specifics in a system you're embedded in 
> is not
>>  good
>>  >> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you 
> want
>>  to
>>  >> your own logging thing while being invoked by Maven then you fork 
> the
>>  JVM
>>  >> and then you can do whatever you want.
>>  >>>>
>>  >>>> I read Olivier's point to be this: it would be cool if 
> we could think
>>  >>>> of a way for a plugin to use the slf4j API and remain 
> independent of
>>  >>>> the logging workings of the maven core.
>>  >>>
>>  >>> I think you mean remain independent of the SLF4J implemented 
> used by
>>  >> Maven's core.
>>  >>>
>>  >>> Sure, but my counter line of argument would be is that really 
&

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

On Nov 30, 2012, at 11:15 AM, Stephen Connolly 
 wrote:

> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
> 

If it's in 3.0.4 then you are using Mojo.getLog(), which is probably the ideal 
case, and this will work without change in 3.1.0.

> Currently 3.0.4 does not provide either the api or an impl, so I need both
> as a dependency..,
> 

If you want to use SLF4J in 3.0.4 where is doesn't exist then yes. But I would 
just stick with Mojo.getLog().

> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
> and part of the plugin jar (because it makes most sense to scope it there)
> 
> What happens when that runs on 3.1.0?

Can you give me a little plugin that demonstrates? I'm building a bunch of 
sample plugins now doing all the weird things we can think of.
> 
> Oh and in my custom slf4j impl I actuall knock all the logging levels down
> by 1, because this tool I am using is too verbose and what it spouts at
> INFO is really DEBUG... So bypassing my impl would be a "bad thing" for
> users

You can control that with the configuration included, we have done that with 
Sisu to quiet it down.

After chatting with Ceki I learned that it's not possible once SLF4J starts up 
to change the implementation. I don't think this is really a problem, the host 
system picks the implementation and that's what's used. So I think this is 
becoming rather clear that we should probably just pick the best implementation 
we can and go with it.



> 
> On Friday, 30 November 2012, Jason van Zyl wrote:
> 
>> For case 2) I would say only fork if your logging is know to interfere
>> with standard SLF4J practices which I think would be rare. But I'll see how
>> easy it is to implement a flag while I'm looking at this in general.
>> 
>> On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>> 
>>> I tend to agree. There are two use-cases I see that a plugin has for
>>> bundling a logging implementation:
>>> 
>>> 1. They are wanting to shunt the logs from the build tool they are
>> invoking
>>> on to the user. Typically if they are being good plugins they just take
>> the
>>> logging output and shunt it onto org.apache.maven.plugin.Log.info()
>>> 
>>> 2. They are wanting to shunt the logs from the build tool (or more likely
>>> app server) to a separate file, or tweak the level of logs higher than
>> INFO
>>> for that app server/mojo execution as it will just drown the user.
>>> 
>>> In the first use case, Jason's point is correct. They shouldn't need to
>>> bundle a logging implementation any more.
>>> 
>>> The second case, Jason is arguing that they shouldn't be using the Maven
>>> JVM for running that tool, they should be running it in a forked JVM and
>>> then they can configure the logging in that JVM. I disagree. Forking a
>> JVM
>>> for every little build tool just to control its logging is going to kill
>>> the build time.
>>> 
>>> My preference is for a metadata flag that says: Oy! I know what I'm doing
>>> with logging, so don't pass logging on to me.
>>> 
>>> While it feels like a "special case" the truth is logging is always, and
>>> always will be, a special case!
>>> 
>>> -Stephen
>>> 
>>> 
>>> On 30 November 2012 12:09, Benson Margulies 
>> wrote:
>>> 
 On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
> 
> 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 implementation specifics in a system you're embedded in is not
>> good
 e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want
>> to
 your own logging thing while being invoked by Maven then you fork the
>> JVM
 and then you can do whatever you want.
>> 
>> I read Olivier's point to be this: it would be cool if we could think
>> of a way for a plugin to use the slf4j API and remain independent of
>> the logging workings of the maven core.
> 
> I think you mean remain independent of the SLF4J implemented used by
 Maven's core.
> 
> Sure, but my counter line of argument would be is that really valid? If
 you are running in the context of Maven and you're using SLF4J I think
>> you
 should defer to what Maven has setup.
> 
>> As things are, that could be
>> done only, I think, by using shade to  rename a copy of slf4j for the
>> guts of the plugin.
> 
> We have the capability in the core, that is OSGi-esque, that allows us
 to block classes from being accessible to plugins. We can block/allow
>> any
 classes we choose: we can effectively make anything invisible to
>> plugins if
 we choose. This capability was added to Classworlds some time ago.
> 
>> If I were less sleep-deprive

Re: [VOTE] Maven 3.1.0

[Stephen Connolly]

What about the case where a plugin needs to work with both 3.0.4 and 3.1.0

Currently 3.0.4 does not provide either the api or an impl, so I need both
as a dependency..,

I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
and part of the plugin jar (because it makes most sense to scope it there)

What happens when that runs on 3.1.0?

Oh and in my custom slf4j impl I actuall knock all the logging levels down
by 1, because this tool I am using is too verbose and what it spouts at
INFO is really DEBUG... So bypassing my impl would be a "bad thing" for
users

On Friday, 30 November 2012, Jason van Zyl wrote:

> For case 2) I would say only fork if your logging is know to interfere
> with standard SLF4J practices which I think would be rare. But I'll see how
> easy it is to implement a flag while I'm looking at this in general.
>
> On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I tend to agree. There are two use-cases I see that a plugin has for
> > bundling a logging implementation:
> >
> > 1. They are wanting to shunt the logs from the build tool they are
> invoking
> > on to the user. Typically if they are being good plugins they just take
> the
> > logging output and shunt it onto org.apache.maven.plugin.Log.info()
> >
> > 2. They are wanting to shunt the logs from the build tool (or more likely
> > app server) to a separate file, or tweak the level of logs higher than
> INFO
> > for that app server/mojo execution as it will just drown the user.
> >
> > In the first use case, Jason's point is correct. They shouldn't need to
> > bundle a logging implementation any more.
> >
> > The second case, Jason is arguing that they shouldn't be using the Maven
> > JVM for running that tool, they should be running it in a forked JVM and
> > then they can configure the logging in that JVM. I disagree. Forking a
> JVM
> > for every little build tool just to control its logging is going to kill
> > the build time.
> >
> > My preference is for a metadata flag that says: Oy! I know what I'm doing
> > with logging, so don't pass logging on to me.
> >
> > While it feels like a "special case" the truth is logging is always, and
> > always will be, a special case!
> >
> > -Stephen
> >
> >
> > On 30 November 2012 12:09, Benson Margulies 
> wrote:
> >
> >> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
> >>>
> >>> 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 implementation specifics in a system you're embedded in is not
> good
> >> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want
> to
> >> your own logging thing while being invoked by Maven then you fork the
> JVM
> >> and then you can do whatever you want.
> 
>  I read Olivier's point to be this: it would be cool if we could think
>  of a way for a plugin to use the slf4j API and remain independent of
>  the logging workings of the maven core.
> >>>
> >>> I think you mean remain independent of the SLF4J implemented used by
> >> Maven's core.
> >>>
> >>> Sure, but my counter line of argument would be is that really valid? If
> >> you are running in the context of Maven and you're using SLF4J I think
> you
> >> should defer to what Maven has setup.
> >>>
>  As things are, that could be
>  done only, I think, by using shade to  rename a copy of slf4j for the
>  guts of the plugin.
> >>>
> >>> We have the capability in the core, that is OSGi-esque, that allows us
> >> to block classes from being accessible to plugins. We can block/allow
> any
> >> classes we choose: we can effectively make anything invisible to
> plugins if
> >> we choose. This capability was added to Classworlds some time ago.
> >>>
>  If I were less sleep-deprived, I might be able to
>  put forth an idea about how an enhancement to slf4j could allow
>  everyone to be happy here, but I don't see a way to make everyone
>  happy as things are.
> 
>  My personal view is that 'giant subsystem' plugins are rarities at
>  most, and the attraction of saying 'the Maven logging API *is* slf4j'
>  outweighs for me the problems.
> >>>
> >>> I think everyone agrees there, it's really now a matter would we let
> >> plugins pick and use a different implementation than the core.
> >>>
> 
>  However, another possibility that occurs to me

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

For case 2) I would say only fork if your logging is know to interfere with 
standard SLF4J practices which I think would be rare. But I'll see how easy it 
is to implement a flag while I'm looking at this in general.

On Nov 30, 2012, at 4:20 AM, Stephen Connolly  
wrote:

> I tend to agree. There are two use-cases I see that a plugin has for
> bundling a logging implementation:
> 
> 1. They are wanting to shunt the logs from the build tool they are invoking
> on to the user. Typically if they are being good plugins they just take the
> logging output and shunt it onto org.apache.maven.plugin.Log.info()
> 
> 2. They are wanting to shunt the logs from the build tool (or more likely
> app server) to a separate file, or tweak the level of logs higher than INFO
> for that app server/mojo execution as it will just drown the user.
> 
> In the first use case, Jason's point is correct. They shouldn't need to
> bundle a logging implementation any more.
> 
> The second case, Jason is arguing that they shouldn't be using the Maven
> JVM for running that tool, they should be running it in a forked JVM and
> then they can configure the logging in that JVM. I disagree. Forking a JVM
> for every little build tool just to control its logging is going to kill
> the build time.
> 
> My preference is for a metadata flag that says: Oy! I know what I'm doing
> with logging, so don't pass logging on to me.
> 
> While it feels like a "special case" the truth is logging is always, and
> always will be, a special case!
> 
> -Stephen
> 
> 
> On 30 November 2012 12:09, Benson Margulies  wrote:
> 
>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
>>> 
>>> 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 implementation specifics in a system you're embedded in is not good
>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to
>> your own logging thing while being invoked by Maven then you fork the JVM
>> and then you can do whatever you want.
 
 I read Olivier's point to be this: it would be cool if we could think
 of a way for a plugin to use the slf4j API and remain independent of
 the logging workings of the maven core.
>>> 
>>> I think you mean remain independent of the SLF4J implemented used by
>> Maven's core.
>>> 
>>> Sure, but my counter line of argument would be is that really valid? If
>> you are running in the context of Maven and you're using SLF4J I think you
>> should defer to what Maven has setup.
>>> 
 As things are, that could be
 done only, I think, by using shade to  rename a copy of slf4j for the
 guts of the plugin.
>>> 
>>> We have the capability in the core, that is OSGi-esque, that allows us
>> to block classes from being accessible to plugins. We can block/allow any
>> classes we choose: we can effectively make anything invisible to plugins if
>> we choose. This capability was added to Classworlds some time ago.
>>> 
 If I were less sleep-deprived, I might be able to
 put forth an idea about how an enhancement to slf4j could allow
 everyone to be happy here, but I don't see a way to make everyone
 happy as things are.
 
 My personal view is that 'giant subsystem' plugins are rarities at
 most, and the attraction of saying 'the Maven logging API *is* slf4j'
 outweighs for me the problems.
>>> 
>>> I think everyone agrees there, it's really now a matter would we let
>> plugins pick and use a different implementation than the core.
>>> 
 
 However, another possibility that occurs to me is this:
 
 Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
 Such a plugin could only log to the Maven log through the Mojo log
 API.
>>> 
>>> That's the magic I would like to avoid. Anything is possible but I would
>> prefer how a plugin author should integrate with our SLF4J logging.
>> 
>> Here's the crux of the disagreement. To be clear, I'm not trying to
>> derail any 3.1.0 trains here, just thinking ahead.
>> 
>> A logging framework is a tool for collecting and distributing
>> information. When someone plugs 'thing X' into Maven, I don't think
>> that it follows, necessarily, that their application of a logging
>> framework necessarily aligns with ours. We are logging 'the build' --
>> they are logging 'whatever it is that they are doing'. They may log
>> thousands of messages at 'INFO' that are only interesting to some
>> program that digests them, like Apache Flume. That's going to make an
>> awfully hard-to-read console. If we stick to your view, their only
>> option is to mess with the global Maven logging config to reroute
>> their messages, and that's very out of keeping with the whole model of
>> maven plugins as self-contained.
>>

Re: [VOTE] Maven 3.1.0

[Benson Margulies]

I agree that the Sonar plugin is bogus and unrelated to the discussion
at hand, and I accept your explanation that we're not, in fact, going
to derail legitimate 'self-contained' plugins.

-
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]

On Nov 30, 2012, at 4:09 AM, Benson Margulies  wrote:

>> 
>> That's the magic I would like to avoid. Anything is possible but I would 
>> prefer how a plugin author should integrate with our SLF4J logging.
> 
> Here's the crux of the disagreement. To be clear, I'm not trying to
> derail any 3.1.0 trains here, just thinking ahead.
> 

These are good discussions and it's important to make sure we try some things 
because one we let this out it's going to be hard to pull back. If we roll it 
five more times I don't think that's a problem and I don't mind rolling it 
again and again.

But I shouldn't send email right before going to bed and I should have looked 
at the realms because we're not exporting the package that contains the SLF4J 
implementation, we are only exporting the API if you look at the 
DefaultClassRealmManager. I will try something here locally but after looking 
again I think plugins will be fine because the Plugin API is exported and 
therefore users have access to the implementation of SLF4J used in the core 
without exposing it, and the implementation is also available through injection 
or using the static LoggerFactory method. I will verify that now. I think the 
problem with Sonar is misuse of the API and Simon agrees with me but I don't 
want to break Sonar users.

> A logging framework is a tool for collecting and distributing
> information. When someone plugs 'thing X' into Maven, I don't think
> that it follows, necessarily, that their application of a logging
> framework necessarily aligns with ours. We are logging 'the build' --
> they are logging 'whatever it is that they are doing'. They may log
> thousands of messages at 'INFO' that are only interesting to some
> program that digests them, like Apache Flume. That's going to make an
> awfully hard-to-read console. If we stick to your view, their only
> option is to mess with the global Maven logging config to reroute
> their messages, and that's very out of keeping with the whole model of
> maven plugins as self-contained.

If you are running something like Flume that also has the possibly of making 
your CI server fall over I would not run that in-process. If they fork and run 
it in isolation I believe they will have not have to contend with what we've 
setup for logging.

> 
> I am content to wait for the first JIRA from someone who has this
> issue, and then advocate for the magic, rather than continue an
> argument right now.
> 

I think it's setup now the way we want, we just happen to have an unfortunate 
use of the API in Sonar but I think we're going to have to deal with that. If 
3.1.0 comes out and Sonar doesn't work I don't think that's acceptable even 
though it's not really our fault.

>> 
>>> 
>>> I may be understating the strength of Olivier's (and others') desire
>>> to avoid surprising the authors of plugins that call things that call
>>> slf4j, though I can see 'surprise' in both directions here in the long
>>> run.
>> 
>> Given this is 3.1.0 I believe it's more a matter of documenting how plugin 
>> should integrate their logging with Maven's SLF4J system. An app server 
>> which may integrate all manner of things works. If you want to integrate 
>> with me, this is how you need to do it.
>> 
>>> 
>>> -
>>> 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
-

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

Re: [VOTE] Maven 3.1.0

[ceki]

Hi All,

In sonar-core, looking at the Logback class in the
org.sonar.core.config package, you can find following lines:

import ch.qos.logback.classic.LoggerContext;
import org.slf4j.LoggerFactory;
...

LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();

Sonar is assuming that SLF4J is bound with Logback, not an
unreasonable assumption for stand-alone Sonar or for a maven-plugin
before Maven started using SLF4J.

However, with Maven 3.1, this assumption proves to be incorrect. I
would suggest to contact Sonar people so that the code which
configures Logback first checks that SLF4J is bound to Logback. If
not, the code should not attempt to configure logback. Basically,
Sonar should add a few lines of defensive code.

My 2c.

--
Ceki
65% of statistics are made up on the spot

-
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

[Benson Margulies]

On Fri, Nov 30, 2012 at 7:20 AM, Stephen Connolly
 wrote:
> I tend to agree. There are two use-cases I see that a plugin has for
> bundling a logging implementation:
>
> 1. They are wanting to shunt the logs from the build tool they are invoking
> on to the user. Typically if they are being good plugins they just take the
> logging output and shunt it onto org.apache.maven.plugin.Log.info()
>
> 2. They are wanting to shunt the logs from the build tool (or more likely
> app server) to a separate file, or tweak the level of logs higher than INFO
> for that app server/mojo execution as it will just drown the user.
>
> In the first use case, Jason's point is correct. They shouldn't need to
> bundle a logging implementation any more.
>
> The second case, Jason is arguing that they shouldn't be using the Maven
> JVM for running that tool, they should be running it in a forked JVM and
> then they can configure the logging in that JVM. I disagree. Forking a JVM
> for every little build tool just to control its logging is going to kill
> the build time.

I'd be happier with forking if we had a maven-fork-utils project that
allowed any plugin author, easily, to have as many forks at his or her
place-setting as we see in, say, surefire.


>
> My preference is for a metadata flag that says: Oy! I know what I'm doing
> with logging, so don't pass logging on to me.
>
> While it feels like a "special case" the truth is logging is always, and
> always will be, a special case!
>
> -Stephen
>
>
> On 30 November 2012 12:09, Benson Margulies  wrote:
>
>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
>> >
>> > 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 implementation specifics in a system you're embedded in is not good
>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to
>> your own logging thing while being invoked by Maven then you fork the JVM
>> and then you can do whatever you want.
>> >>
>> >> I read Olivier's point to be this: it would be cool if we could think
>> >> of a way for a plugin to use the slf4j API and remain independent of
>> >> the logging workings of the maven core.
>> >
>> > I think you mean remain independent of the SLF4J implemented used by
>> Maven's core.
>> >
>> > Sure, but my counter line of argument would be is that really valid? If
>> you are running in the context of Maven and you're using SLF4J I think you
>> should defer to what Maven has setup.
>> >
>> >> As things are, that could be
>> >> done only, I think, by using shade to  rename a copy of slf4j for the
>> >> guts of the plugin.
>> >
>> > We have the capability in the core, that is OSGi-esque, that allows us
>> to block classes from being accessible to plugins. We can block/allow any
>> classes we choose: we can effectively make anything invisible to plugins if
>> we choose. This capability was added to Classworlds some time ago.
>> >
>> >> If I were less sleep-deprived, I might be able to
>> >> put forth an idea about how an enhancement to slf4j could allow
>> >> everyone to be happy here, but I don't see a way to make everyone
>> >> happy as things are.
>> >>
>> >> My personal view is that 'giant subsystem' plugins are rarities at
>> >> most, and the attraction of saying 'the Maven logging API *is* slf4j'
>> >> outweighs for me the problems.
>> >
>> > I think everyone agrees there, it's really now a matter would we let
>> plugins pick and use a different implementation than the core.
>> >
>> >>
>> >> However, another possibility that occurs to me is this:
>> >>
>> >> Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
>> >> Such a plugin could only log to the Maven log through the Mojo log
>> >> API.
>> >
>> > That's the magic I would like to avoid. Anything is possible but I would
>> prefer how a plugin author should integrate with our SLF4J logging.
>>
>> Here's the crux of the disagreement. To be clear, I'm not trying to
>> derail any 3.1.0 trains here, just thinking ahead.
>>
>> A logging framework is a tool for collecting and distributing
>> information. When someone plugs 'thing X' into Maven, I don't think
>> that it follows, necessarily, that their application of a logging
>> framework necessarily aligns with ours. We are logging 'the build' --
>> they are logging 'whatever it is that they are doing'. They may log
>> thousands of messages at 'INFO' that are only interesting to some
>> program that digests them, like Apache Flume. That's going to make an
>> awfully hard-to-read console. If we stick to your view, their only
>> option is to mess with the global Maven logging config to reroute
>> their messages, and that's very out of keeping with the whole model of
>> maven plugins as self-contained.
>>
>> I am content t

Re: [VOTE] Maven 3.1.0

[Stephen Connolly]

I tend to agree. There are two use-cases I see that a plugin has for
bundling a logging implementation:

1. They are wanting to shunt the logs from the build tool they are invoking
on to the user. Typically if they are being good plugins they just take the
logging output and shunt it onto org.apache.maven.plugin.Log.info()

2. They are wanting to shunt the logs from the build tool (or more likely
app server) to a separate file, or tweak the level of logs higher than INFO
for that app server/mojo execution as it will just drown the user.

In the first use case, Jason's point is correct. They shouldn't need to
bundle a logging implementation any more.

The second case, Jason is arguing that they shouldn't be using the Maven
JVM for running that tool, they should be running it in a forked JVM and
then they can configure the logging in that JVM. I disagree. Forking a JVM
for every little build tool just to control its logging is going to kill
the build time.

My preference is for a metadata flag that says: Oy! I know what I'm doing
with logging, so don't pass logging on to me.

While it feels like a "special case" the truth is logging is always, and
always will be, a special case!

-Stephen


On 30 November 2012 12:09, Benson Margulies  wrote:

> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
> >
> > 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 implementation specifics in a system you're embedded in is not good
> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to
> your own logging thing while being invoked by Maven then you fork the JVM
> and then you can do whatever you want.
> >>
> >> I read Olivier's point to be this: it would be cool if we could think
> >> of a way for a plugin to use the slf4j API and remain independent of
> >> the logging workings of the maven core.
> >
> > I think you mean remain independent of the SLF4J implemented used by
> Maven's core.
> >
> > Sure, but my counter line of argument would be is that really valid? If
> you are running in the context of Maven and you're using SLF4J I think you
> should defer to what Maven has setup.
> >
> >> As things are, that could be
> >> done only, I think, by using shade to  rename a copy of slf4j for the
> >> guts of the plugin.
> >
> > We have the capability in the core, that is OSGi-esque, that allows us
> to block classes from being accessible to plugins. We can block/allow any
> classes we choose: we can effectively make anything invisible to plugins if
> we choose. This capability was added to Classworlds some time ago.
> >
> >> If I were less sleep-deprived, I might be able to
> >> put forth an idea about how an enhancement to slf4j could allow
> >> everyone to be happy here, but I don't see a way to make everyone
> >> happy as things are.
> >>
> >> My personal view is that 'giant subsystem' plugins are rarities at
> >> most, and the attraction of saying 'the Maven logging API *is* slf4j'
> >> outweighs for me the problems.
> >
> > I think everyone agrees there, it's really now a matter would we let
> plugins pick and use a different implementation than the core.
> >
> >>
> >> However, another possibility that occurs to me is this:
> >>
> >> Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
> >> Such a plugin could only log to the Maven log through the Mojo log
> >> API.
> >
> > That's the magic I would like to avoid. Anything is possible but I would
> prefer how a plugin author should integrate with our SLF4J logging.
>
> Here's the crux of the disagreement. To be clear, I'm not trying to
> derail any 3.1.0 trains here, just thinking ahead.
>
> A logging framework is a tool for collecting and distributing
> information. When someone plugs 'thing X' into Maven, I don't think
> that it follows, necessarily, that their application of a logging
> framework necessarily aligns with ours. We are logging 'the build' --
> they are logging 'whatever it is that they are doing'. They may log
> thousands of messages at 'INFO' that are only interesting to some
> program that digests them, like Apache Flume. That's going to make an
> awfully hard-to-read console. If we stick to your view, their only
> option is to mess with the global Maven logging config to reroute
> their messages, and that's very out of keeping with the whole model of
> maven plugins as self-contained.
>
> I am content to wait for the first JIRA from someone who has this
> issue, and then advocate for the magic, rather than continue an
> argument right now.
>
> >
> >>
> >> I may be understating the strength of Olivier's (and others') desire
> >> to avoid surprising the authors of plugins that call things that call
> >> slf4j, though I can see 'surprise' in both directions here in th

Re: [VOTE] Maven 3.1.0

[Benson Margulies]

On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl  wrote:
>
> 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 implementation specifics in a system you're embedded in is not good 
>>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to 
>>> your own logging thing while being invoked by Maven then you fork the JVM 
>>> and then you can do whatever you want.
>>
>> I read Olivier's point to be this: it would be cool if we could think
>> of a way for a plugin to use the slf4j API and remain independent of
>> the logging workings of the maven core.
>
> I think you mean remain independent of the SLF4J implemented used by Maven's 
> core.
>
> Sure, but my counter line of argument would be is that really valid? If you 
> are running in the context of Maven and you're using SLF4J I think you should 
> defer to what Maven has setup.
>
>> As things are, that could be
>> done only, I think, by using shade to  rename a copy of slf4j for the
>> guts of the plugin.
>
> We have the capability in the core, that is OSGi-esque, that allows us to 
> block classes from being accessible to plugins. We can block/allow any 
> classes we choose: we can effectively make anything invisible to plugins if 
> we choose. This capability was added to Classworlds some time ago.
>
>> If I were less sleep-deprived, I might be able to
>> put forth an idea about how an enhancement to slf4j could allow
>> everyone to be happy here, but I don't see a way to make everyone
>> happy as things are.
>>
>> My personal view is that 'giant subsystem' plugins are rarities at
>> most, and the attraction of saying 'the Maven logging API *is* slf4j'
>> outweighs for me the problems.
>
> I think everyone agrees there, it's really now a matter would we let plugins 
> pick and use a different implementation than the core.
>
>>
>> However, another possibility that occurs to me is this:
>>
>> Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
>> Such a plugin could only log to the Maven log through the Mojo log
>> API.
>
> That's the magic I would like to avoid. Anything is possible but I would 
> prefer how a plugin author should integrate with our SLF4J logging.

Here's the crux of the disagreement. To be clear, I'm not trying to
derail any 3.1.0 trains here, just thinking ahead.

A logging framework is a tool for collecting and distributing
information. When someone plugs 'thing X' into Maven, I don't think
that it follows, necessarily, that their application of a logging
framework necessarily aligns with ours. We are logging 'the build' --
they are logging 'whatever it is that they are doing'. They may log
thousands of messages at 'INFO' that are only interesting to some
program that digests them, like Apache Flume. That's going to make an
awfully hard-to-read console. If we stick to your view, their only
option is to mess with the global Maven logging config to reroute
their messages, and that's very out of keeping with the whole model of
maven plugins as self-contained.

I am content to wait for the first JIRA from someone who has this
issue, and then advocate for the magic, rather than continue an
argument right now.

>
>>
>> I may be understating the strength of Olivier's (and others') desire
>> to avoid surprising the authors of plugins that call things that call
>> slf4j, though I can see 'surprise' in both directions here in the long
>> run.
>
> Given this is 3.1.0 I believe it's more a matter of documenting how plugin 
> should integrate their logging with Maven's SLF4J system. An app server which 
> may integrate all manner of things works. If you want to integrate with me, 
> this is how you need to do it.
>
>>
>> -
>> 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

[Jason van Zyl]

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 implementation specifics in a system you're embedded in is not good 
>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to 
>> your own logging thing while being invoked by Maven then you fork the JVM 
>> and then you can do whatever you want.
> 
> I read Olivier's point to be this: it would be cool if we could think
> of a way for a plugin to use the slf4j API and remain independent of
> the logging workings of the maven core.

I think you mean remain independent of the SLF4J implemented used by Maven's 
core.

Sure, but my counter line of argument would be is that really valid? If you are 
running in the context of Maven and you're using SLF4J I think you should defer 
to what Maven has setup.

> As things are, that could be
> done only, I think, by using shade to  rename a copy of slf4j for the
> guts of the plugin.

We have the capability in the core, that is OSGi-esque, that allows us to block 
classes from being accessible to plugins. We can block/allow any classes we 
choose: we can effectively make anything invisible to plugins if we choose. 
This capability was added to Classworlds some time ago.

> If I were less sleep-deprived, I might be able to
> put forth an idea about how an enhancement to slf4j could allow
> everyone to be happy here, but I don't see a way to make everyone
> happy as things are.
> 
> My personal view is that 'giant subsystem' plugins are rarities at
> most, and the attraction of saying 'the Maven logging API *is* slf4j'
> outweighs for me the problems.

I think everyone agrees there, it's really now a matter would we let plugins 
pick and use a different implementation than the core.

> 
> However, another possibility that occurs to me is this:
> 
> Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
> Such a plugin could only log to the Maven log through the Mojo log
> API.

That's the magic I would like to avoid. Anything is possible but I would prefer 
how a plugin author should integrate with our SLF4J logging.

> 
> I may be understating the strength of Olivier's (and others') desire
> to avoid surprising the authors of plugins that call things that call
> slf4j, though I can see 'surprise' in both directions here in the long
> run.

Given this is 3.1.0 I believe it's more a matter of documenting how plugin 
should integrate their logging with Maven's SLF4J system. An app server which 
may integrate all manner of things works. If you want to integrate with me, 
this is how you need to do it.

> 
> -
> 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

[Benson Margulies]

>
> 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 e.g. 
> Logback in Sonar running in Maven using SLF4J Simple. If you want to your own 
> logging thing while being invoked by Maven then you fork the JVM and then you 
> can do whatever you want.

I read Olivier's point to be this: it would be cool if we could think
of a way for a plugin to use the slf4j API and remain independent of
the logging workings of the maven core. As things are, that could be
done only, I think, by using shade to  rename a copy of slf4j for the
guts of the plugin. If I were less sleep-deprived, I might be able to
put forth an idea about how an enhancement to slf4j could allow
everyone to be happy here, but I don't see a way to make everyone
happy as things are.

My personal view is that 'giant subsystem' plugins are rarities at
most, and the attraction of saying 'the Maven logging API *is* slf4j'
outweighs for me the problems.

However, another possibility that occurs to me is this:

Allow a plugin's metadata to say: 'please leave slf4j isolated here'.
Such a plugin could only log to the Maven log through the Mojo log
API.

I may be understating the strength of Olivier's (and others') desire
to avoid surprising the authors of plugins that call things that call
slf4j, though I can see 'surprise' in both directions here in the long
run.

-
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]

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 endpoints, or applications. They consume a bunch of 
components and are the host. They should control everything the way they like.

> It might, for example, have plugin parameters that control the logging
> and the destination.

Maybe. So far I've seen one plugin that tries to set the logging level.

> 
> The users of that plugin will not be happy if a change to maven x.y
> results in all this information being re-routed into Maven's Own Log,
> instead of landing where their configuration tells it to land.

If they are using SLF4 they are either a component to be embedded in which case 
the host is going to pick the implementation and the host controls the log 
output, or they are an application that we are wrapping and I'm not sure what 
to do there. In the case of Sonar it seems like we're wrapping an app because 
it expects Logback to be present. I don't think they use SLF4J correctly but I 
think they just try to use what they have for the app and the Maven plugin.

Maybe Maven is different but consider other systems with plugins: JIRA, 
Confluence, Bamboo, Jenkins. Do they let the plugin authors do whatever they 
want with respect to logging? If so is that useful, not useful?

If we block the implementation we force all plugin authors to specify an 
implementation even if they only use getLog() which to me is not ideal. If we 
let our implementation through then we are going to override the implementation 
specified by the component/app we are consuming which is what's happening with 
Sonar. I would like to avoid any magic of trying to detect implementations: in 
a single invocation of Maven what's the benefit of using multiple 
implementations of the SLF4J API? I don't see any.

The Maven 3.1.0 version might be appropriate if we're saying "If you use SLF4J 
you must follow these guidelines, otherwise you will break."

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 e.g. 
Logback in Sonar running in Maven using SLF4J Simple. If you want to your own 
logging thing while being invoked by Maven then you fork the JVM and then you 
can do whatever you want.

> 
> -
> 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
-

Re: [VOTE] Maven 3.1.0

[Benson Margulies]

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.

The users of that plugin will not be happy if a change to maven x.y
results in all this information being re-routed into Maven's Own Log,
instead of landing where their configuration tells it to land.

-
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]

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 the last 12 months, and 
Sonar specifically is verification. It expects Logback by way of unusual cast 
to ch.qos.logback.classic.Logger.

> The issue can happend with any other plugin using any other slf4j impl.
> 
> My point is: we must first try to find a solution to not export core
> slf4j-impl to plugins.
> AFAIK users and/or mojo developpers are free to use slf4j-impl they want.
> We must not force them to use A impl whereas they prefer B or the last
> "à la mode" impl.

This is not the cause of this problem in this specific case. In the standard 
pattern of use it is the host that decides the implementation. I consume a 
component that uses SLF4J and I pick the implementation. In this case the host 
is Maven. I'm still not convinced allowing something like Sonar to pick its 
implementation makes any sense. In this case they aren't using the SLF4J API 
which is the source of the problem. They cast to an implementation making a 
specific call to that implementation.

> 
> 
>> 
>> 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 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:
> 
>> 
>> 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 it's not very widely tested.  :-(
>> 
> 
> I'm using it and noticed this annoying icon but I though it was related to
> some tests executions.
> What I would like is to release a 2.3.1 ASAP if everybody is agree
 
 I'll deploy a new XStream SNAPSHOT this evening, where you might test if
 this problem still occurs.
 
> After that I agree to not put it in 3.1 if we have too many doubts about
> its quality
> 
>> 
>> Much like the compiler plugin, I'd let this bake a little more before
>> making it the default.
>> 
> 
> +1
> Using it too but I didn't find nor good nor bad changes about it. In my
> case the new incremental stuff is never called thus it works like before.
 
 Cheers,
 Jörg
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
>>> 
>>> 
>>> 
>>> --
>>> 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
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>> 
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>> 
>> 
>> 
>> 
>> 
> 
> -
> 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
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

Re: [VOTE] Maven 3.1.0

[Olivier Lamy]

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/prefer,
> its what the USER prefers.
agree.
But we must try (not sure how :-) ) to not break as it's the case here
with the sonar plugin (I didn't have a look so no idea what is the
real issue here)
>
> Unless I'm missing some reasoning behind this...
>
>
> Olivier Lamy wrote:
>>
>> My point is: we must first try to find a solution to not export core
>> slf4j-impl to plugins.
>> AFAIK users and/or mojo developpers are free to use slf4j-impl they want.
>> We must not force them to use A impl whereas they prefer B or the last
>> "à la mode" impl.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



--
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

Re: [VOTE] Maven 3.1.0

[Jörg Schaible]

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:
> 
>> Hi Arnaud and Dan,
>> 
>> Arnaud Héritier wrote:
>> 

[snip]

>>> I'm using it and noticed this annoying icon but I though it was related
>>> to some tests executions.
>>> What I would like is to release a 2.3.1 ASAP if everybody is agree
>> 
>> I'll deploy a new XStream SNAPSHOT this evening, where you might test if
>> this problem still occurs.

OK, my internet is back again and the new SNAPSHOT is available.

[snip]

- Jörg


-
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]

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.


Unless I'm missing some reasoning behind this...

Olivier Lamy wrote:

My point is: we must first try to find a solution to not export core
slf4j-impl to plugins.
AFAIK users and/or mojo developpers are free to use slf4j-impl they want.
We must not force them to use A impl whereas they prefer B or the last
"à la mode" impl.



-
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

[Olivier Lamy]

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 solution to not export core
slf4j-impl to plugins.
AFAIK users and/or mojo developpers are free to use slf4j-impl they want.
We must not force them to use A impl whereas they prefer B or the last
"à la mode" impl.


>
> 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 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:
> >>>
> 
>  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 it's not very widely tested.  :-(
> 
> >>>
> >>> I'm using it and noticed this annoying icon but I though it was related to
> >>> some tests executions.
> >>> What I would like is to release a 2.3.1 ASAP if everybody is agree
> >>
> >> I'll deploy a new XStream SNAPSHOT this evening, where you might test if
> >> this problem still occurs.
> >>
> >>> After that I agree to not put it in 3.1 if we have too many doubts about
> >>> its quality
> >>>
> 
>  Much like the compiler plugin, I'd let this bake a little more before
>  making it the default.
> 
> >>>
> >>> +1
> >>> Using it too but I didn't find nor good nor bad changes about it. In my
> >>> case the new incremental stuff is never called thus it works like before.
> >>
> >> Cheers,
> >> Jörg
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
> >
> > --
> > 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
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>

-
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

[Jörg Schaible]

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 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 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 it's not very widely tested. 
>>> :-(
>>>
>> 
>> I'm using it and noticed this annoying icon but I though it was related
>> to some tests executions.
>> What I would like is to release a 2.3.1 ASAP if everybody is agree
> 
> I'll deploy a new XStream SNAPSHOT this evening, where you might test if
> this problem still occurs.
> 
>> After that I agree to not put it in 3.1 if we have too many doubts about
>> its quality
>>
>>>
>>> Much like the compiler plugin, I'd let this bake a little more before
>>> making it the default.
>>>
>> 
>> +1
>> Using it too but I didn't find nor good nor bad changes about it. In my
>> case the new incremental stuff is never called thus it works like before.
> 
> Cheers,
> Jörg



-
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]

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 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:
>>> 
 
 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 it's not very widely tested.  :-(
 
>>> 
>>> I'm using it and noticed this annoying icon but I though it was related to
>>> some tests executions.
>>> What I would like is to release a 2.3.1 ASAP if everybody is agree
>> 
>> I'll deploy a new XStream SNAPSHOT this evening, where you might test if
>> this problem still occurs.
>> 
>>> After that I agree to not put it in 3.1 if we have too many doubts about
>>> its quality
>>> 
 
 Much like the compiler plugin, I'd let this bake a little more before
 making it the default.
 
>>> 
>>> +1
>>> Using it too but I didn't find nor good nor bad changes about it. In my
>>> case the new incremental stuff is never called thus it works like before.
>> 
>> Cheers,
>> Jörg
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> 
> 
> -- 
> 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
> 

Thanks,

Jason

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

Simplex sigillum veri. (Simplicity is the seal of truth.)

Re: [VOTE] Maven 3.1.0

[Olivier Lamy]

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:
>>
>>>
>>> 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 it's not very widely tested.  :-(
>>>
>>
>> I'm using it and noticed this annoying icon but I though it was related to
>> some tests executions.
>> What I would like is to release a 2.3.1 ASAP if everybody is agree
>
> I'll deploy a new XStream SNAPSHOT this evening, where you might test if
> this problem still occurs.
>
>> After that I agree to not put it in 3.1 if we have too many doubts about
>> its quality
>>
>>>
>>> Much like the compiler plugin, I'd let this bake a little more before
>>> making it the default.
>>>
>>
>> +1
>> Using it too but I didn't find nor good nor bad changes about it. In my
>> case the new incremental stuff is never called thus it works like before.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
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

Re: [VOTE] Maven 3.1.0

[Jörg Schaible]

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 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 it's not very widely tested.  :-(
>>
> 
> I'm using it and noticed this annoying icon but I though it was related to
> some tests executions.
> What I would like is to release a 2.3.1 ASAP if everybody is agree

I'll deploy a new XStream SNAPSHOT this evening, where you might test if 
this problem still occurs.

> After that I agree to not put it in 3.1 if we have too many doubts about
> its quality
>
>>
>> Much like the compiler plugin, I'd let this bake a little more before
>> making it the default.
>>
> 
> +1
> Using it too but I didn't find nor good nor bad changes about it. In my
> case the new incremental stuff is never called thus it works like before.

Cheers,
Jörg


-
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

[Arnaud Héritier]

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 the first one to even notice
> that 2.3 has issues on the Mac suggests it's not very widely tested.  :-(
>

I'm using it and noticed this annoying icon but I though it was related to
some tests executions.
What I would like is to release a 2.3.1 ASAP if everybody is agree
After that I agree to not put it in 3.1 if we have too many doubts about
its quality


>
> Much like the compiler plugin, I'd let this bake a little more before
> making it the default.
>

+1
Using it too but I didn't find nor good nor bad changes about it. In my
case the new incremental stuff is never called thus it works like before.


>
> Dan
>

Arnaud

Re: [VOTE] Maven 3.1.0

[Daniel Kulp]

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 it's not very widely tested.  :-(

Much like the compiler plugin, I'd let this bake a little more before making it 
the default.

Dan


> On Thursday, November 29, 2012, Jason van Zyl wrote:
> 
>> I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin
>> 2.4?
>> 
>> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>> 
>>> 
>>> On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
 But what version of the plugin are users going to get?
>>> 
>>> If it's not locked down, they would get 2.3.  (maven 3.0.x users get
>> 2.1.3 I think)
>>> 
>>> 
>>> However, I want to be clear:
>>> 
>>> * The issue ONLY affects Mac users.  Other platforms are OK.
>>> 
>>> * The issue only affects users that use the war plugin.
>>> 
>>> * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
>> is released).
>>> 
>>> * Another work around: adding the -Djava.awt.headless=true flag to the
>> MAVEN_OPTS.
>>> 
>>> * The issue does NOT affect the output of the war plugin.  The plugin
>> does exactly what it's supposed to do and produces a proper war.
>>> 
>>> 
>>> The only "problem" is the Java Icon that would appear on the Mac Dock
>> for the duration of the build.   It doesn't affect the actual build at all.
>>> 
>>> So basically, it affects a relatively small number of maven users,
>> doesn't affect the actual build at all, and has a relatively easy
>> workaround for people that are annoyed by it.
>>> 
>>> 
>>> Dan
>>> 
>>> 
>>> 
 On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
 
> 
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
>> wrote:
> 
>> there is an issue opened about it ?
>> I didn't find it.
> 
> No, Olivier and I spent a chunk of time yesterday on IRC trying to
>> figure out what was going on.   Once we figured it out, he committed a fix
>> before I could even login to JIRA.  :-)
> 
> 
> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
>> line
> back tp xstream 1.4.2 to avoid
>> http://jira.codehaus.org/browse/XSTR-709
> 
> 
> Dan
> 
> 
>> 
>> 
>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
>> wrote:
>> 
>>> 
>>> +1
>>> 
>>> I've tested this with a few projects and it seems to work.
>>> 
>>> I DON'T like that it updates the war plugin to 2.3 as that version
>> has
>>> issues on the Mac related to setting up an awt Toolkit.   However,
>> there is
>>> a simple workaround of locking the war version down to 2.2 in the
>> project
>>> pom (which is something the project in question should have done
>> anyway).
>>> 
>>> Dan
>>> 
>>> 
>>> 
 On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
>> wrote:
 
> Hi,
> 
> Here is a link to Jira with 30 issues resolved:
> 
> 
>>> 
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-073/
> 
> The distributable binaries and sources for testing can be found
>> here:
> 
> 
>>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-the
>> course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
>> 

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.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

[Jason van Zyl]

I was just going to wait the 3 days if folks wanted 2.4. It's been 11 months, 
another 3 days isn't a big deal.

jvz

On 2012-11-28, at 10:22 PM, 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.
> 
> On Thursday, November 29, 2012, Jason van Zyl wrote:
> 
>> I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin
>> 2.4?
>> 
>> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>> 
>>> 
>>> On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
 But what version of the plugin are users going to get?
>>> 
>>> If it's not locked down, they would get 2.3.  (maven 3.0.x users get
>> 2.1.3 I think)
>>> 
>>> 
>>> However, I want to be clear:
>>> 
>>> * The issue ONLY affects Mac users.  Other platforms are OK.
>>> 
>>> * The issue only affects users that use the war plugin.
>>> 
>>> * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
>> is released).
>>> 
>>> * Another work around: adding the -Djava.awt.headless=true flag to the
>> MAVEN_OPTS.
>>> 
>>> * The issue does NOT affect the output of the war plugin.  The plugin
>> does exactly what it's supposed to do and produces a proper war.
>>> 
>>> 
>>> The only "problem" is the Java Icon that would appear on the Mac Dock
>> for the duration of the build.   It doesn't affect the actual build at all.
>>> 
>>> So basically, it affects a relatively small number of maven users,
>> doesn't affect the actual build at all, and has a relatively easy
>> workaround for people that are annoyed by it.
>>> 
>>> 
>>> Dan
>>> 
>>> 
>>> 
 On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
 
> 
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
>> wrote:
> 
>> there is an issue opened about it ?
>> I didn't find it.
> 
> No, Olivier and I spent a chunk of time yesterday on IRC trying to
>> figure out what was going on.   Once we figured it out, he committed a fix
>> before I could even login to JIRA.  :-)
> 
> 
> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
>> line
> back tp xstream 1.4.2 to avoid
>> http://jira.codehaus.org/browse/XSTR-709
> 
> 
> Dan
> 
> 
>> 
>> 
>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
>> wrote:
>> 
>>> 
>>> +1
>>> 
>>> I've tested this with a few projects and it seems to work.
>>> 
>>> I DON'T like that it updates the war plugin to 2.3 as that version
>> has
>>> issues on the Mac related to setting up an awt Toolkit.   However,
>> there is
>>> a simple workaround of locking the war version down to 2.2 in the
>> project
>>> pom (which is something the project in question should have done
>> anyway).
>>> 
>>> Dan
>>> 
>>> 
>>> 
 On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
>> wrote:
 
> Hi,
> 
> Here is a link to Jira with 30 issues resolved:
> 
> 
>>> 
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-073/
> 
> The distributable binaries and sources for testing can be found
>> here:
> 
> 
>>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-the
>> course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
>> 

-
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

[Stephane Nicoll]

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.

On Thursday, November 29, 2012, Jason van Zyl wrote:

> I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin
> 2.4?
>
> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>
> >
> > On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
> >> But what version of the plugin are users going to get?
> >
> > If it's not locked down, they would get 2.3.  (maven 3.0.x users get
> 2.1.3 I think)
> >
> >
> > However, I want to be clear:
> >
> > * The issue ONLY affects Mac users.  Other platforms are OK.
> >
> > * The issue only affects users that use the war plugin.
> >
> > * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
> is released).
> >
> > * Another work around: adding the -Djava.awt.headless=true flag to the
> MAVEN_OPTS.
> >
> > * The issue does NOT affect the output of the war plugin.  The plugin
> does exactly what it's supposed to do and produces a proper war.
> >
> >
> > The only "problem" is the Java Icon that would appear on the Mac Dock
> for the duration of the build.   It doesn't affect the actual build at all.
> >
> > So basically, it affects a relatively small number of maven users,
> doesn't affect the actual build at all, and has a relatively easy
> workaround for people that are annoyed by it.
> >
> >
> > Dan
> >
> >
> >
> >> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
> >>
> >>>
> >>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
> wrote:
> >>>
>  there is an issue opened about it ?
>  I didn't find it.
> >>>
> >>> No, Olivier and I spent a chunk of time yesterday on IRC trying to
> figure out what was going on.   Once we figured it out, he committed a fix
> before I could even login to JIRA.  :-)
> >>>
> >>>
> >>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
> line
> >>> back tp xstream 1.4.2 to avoid
> http://jira.codehaus.org/browse/XSTR-709
> >>>
> >>>
> >>> Dan
> >>>
> >>>
> 
> 
>  On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
> wrote:
> 
> >
> > +1
> >
> > I've tested this with a few projects and it seems to work.
> >
> > I DON'T like that it updates the war plugin to 2.3 as that version
> has
> > issues on the Mac related to setting up an awt Toolkit.   However,
> there is
> > a simple workaround of locking the war version down to 2.2 in the
> project
> > pom (which is something the project in question should have done
> anyway).
> >
> > Dan
> >
> >
> >
> >> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Here is a link to Jira with 30 issues resolved:
> >>>
> >>>
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-073/
> >>>
> >>> The distributable binaries and sources for testing can be found
> here:
> >>>
> >>>
> >
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-the
> course of true love never did run smooth ...
>
>  -- Shakespeare
>
>
>
>
>
>

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

It definitely needs a unit test, but I don't think that needs an IT. The logger 
can't be null before it's used. We used to resort to checking for null and 
using stdout if so. I thought I got all the paths where it could be null but 
obviously not.

On Nov 28, 2012, at 9:15 PM, Barrie Treloar  wrote:

> On Thu, Nov 29, 2012 at 10:48 AM, John Casey  wrote:
>> Found a minor regression:
>> 
>> http://jira.codehaus.org/browse/MNG-5390
>> 
>> It's not critical, but keeps the output from being as helpful as it could.
> 
> Is this something that we have an IT for?
> 
> -
> 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
-

What matters is not ideas, but the people who have them. Good people can fix 
bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: [VOTE] Maven 3.1.0

[Barrie Treloar]

On Thu, Nov 29, 2012 at 10:48 AM, John Casey  wrote:
> Found a minor regression:
>
> http://jira.codehaus.org/browse/MNG-5390
>
> It's not critical, but keeps the output from being as helpful as it could.

Is this something that we have an IT for?

-
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]

I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin 2.4?

On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:

> 
> On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
>> But what version of the plugin are users going to get?
> 
> If it's not locked down, they would get 2.3.  (maven 3.0.x users get 2.1.3 I 
> think)
> 
> 
> However, I want to be clear:
> 
> * The issue ONLY affects Mac users.  Other platforms are OK.
> 
> * The issue only affects users that use the war plugin.   
> 
> * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is 
> released).  
> 
> * Another work around: adding the -Djava.awt.headless=true flag to the 
> MAVEN_OPTS.
> 
> * The issue does NOT affect the output of the war plugin.  The plugin does 
> exactly what it's supposed to do and produces a proper war.
> 
> 
> The only "problem" is the Java Icon that would appear on the Mac Dock for the 
> duration of the build.   It doesn't affect the actual build at all.   
> 
> So basically, it affects a relatively small number of maven users, doesn't 
> affect the actual build at all, and has a relatively easy workaround for 
> people that are annoyed by it.
> 
> 
> Dan
> 
> 
> 
>> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
>> 
>>> 
>>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:
>>> 
 there is an issue opened about it ?
 I didn't find it.
>>> 
>>> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure 
>>> out what was going on.   Once we figured it out, he committed a fix before 
>>> I could even login to JIRA.  :-)
>>> 
>>> 
>>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
>>> back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709
>>> 
>>> 
>>> Dan
>>> 
>>> 
 
 
 On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
 
> 
> +1
> 
> I've tested this with a few projects and it seems to work.
> 
> I DON'T like that it updates the war plugin to 2.3 as that version has
> issues on the Mac related to setting up an awt Toolkit.   However, there 
> is
> a simple workaround of locking the war version down to 2.2 in the project
> pom (which is something the project in question should have done anyway).
> 
> Dan
> 
> 
> 
>> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
>> 
>>> Hi,
>>> 
>>> Here is a link to Jira with 30 issues resolved:
>>> 
>>> 
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/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
>>> 
> 
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
 
 
 -- 
 -
 Arnaud Héritier
 06-89-76-64-24
 http://aheritier.net
 Mail/GTalk: aherit...@gmail.com
 Twitter/Skype : aheritier
>>> 
>>> -- 
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ---

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Thanks, easy enough to fix. I'll wait until the morning for other comments but 
looks like a re-spin would be a good idea.

On Nov 28, 2012, at 7:18 PM, John Casey  wrote:

> Found a minor regression:
> 
> http://jira.codehaus.org/browse/MNG-5390
> 
> It's not critical, but keeps the output from being as helpful as it could.
> 
> On 11/28/12 2:52 PM, John Casey wrote:
>> +1
>> 
>> It appears to work fine on my largest builds here.
>> 
>> On 11/26/12 12:24 AM, Jason van Zyl wrote:
>>> Hi,
>>> 
>>> Here is a link to Jira with 30 issues resolved:
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/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
>>> 
>> 
>> 
> 
> 
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey
> 
> -
> 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
-

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: [VOTE] Maven 3.1.0

[John Casey]

Found a minor regression:

http://jira.codehaus.org/browse/MNG-5390

It's not critical, but keeps the output from being as helpful as it could.

On 11/28/12 2:52 PM, John Casey wrote:

+1

It appears to work fine on my largest builds here.

On 11/26/12 12:24 AM, Jason van Zyl wrote:

Hi,

Here is a link to Jira with 30 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967


Staging repo:
https://repository.apache.org/content/repositories/maven-073/

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip

https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz

https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip

https://repository.apache.org/content/repositories/maven-073/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







--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

-
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

[Dennis Lundberg]

Hi

The compiler plugin is at 2.5.1 in the release. The 3.0 release was
deemed to be to new to be included as default in core.

On 2012-11-28 22:08, Jason van Zyl wrote:
> I honestly don't mind re-spinning. It's not a big deal. What about the 
> compiler plugin?
> 
> jvz
> 
> On 2012-11-28, at 3:38 PM, Benson Margulies  wrote:
> 
>> It's an extremely minor annoyance, writing as one of the victims.
>> Please don't make Jason re-roll. I have better idea for the use of his
>> time.
>>
>> On Wed, Nov 28, 2012 at 1:40 PM, Arnaud Héritier  wrote:
>>> +1 with Jason to redo it.
>>> What do we do ? Excepted this bug the 2.3 was interesting to have for
>>> performances improvements and few bug fixes. Could we release a 2.3.1 and
>>> then/or in // re-release 3.1.0 ?
>>> WDYT ?
>>>
>>>
>>> On Wed, Nov 28, 2012 at 7:17 PM, Jason van Zyl  wrote:
>>>
 Even for that it's probably worth re-spinning. I think the math is pretty
 easy there. It will take me 30 minutes to fix and re-release versus
 potentially thousands of people spending 10-20 minutes. People on Macs
 using the default version of the WAR plugin is probably not a small number.
 Why even expose it.

 On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:

>
> On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
>> But what version of the plugin are users going to get?
>
> If it's not locked down, they would get 2.3.  (maven 3.0.x users get
 2.1.3 I think)
>
>
> However, I want to be clear:
>
> * The issue ONLY affects Mac users.  Other platforms are OK.
>
> * The issue only affects users that use the war plugin.
>
> * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
 is released).
>
> * Another work around: adding the -Djava.awt.headless=true flag to the
 MAVEN_OPTS.
>
> * The issue does NOT affect the output of the war plugin.  The plugin
 does exactly what it's supposed to do and produces a proper war.
>
>
> The only "problem" is the Java Icon that would appear on the Mac Dock
 for the duration of the build.   It doesn't affect the actual build at all.
>
> So basically, it affects a relatively small number of maven users,
 doesn't affect the actual build at all, and has a relatively easy
 workaround for people that are annoyed by it.
>
>
> Dan
>
>
>
>> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
>>
>>>
>>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
 wrote:
>>>
 there is an issue opened about it ?
 I didn't find it.
>>>
>>> No, Olivier and I spent a chunk of time yesterday on IRC trying to
 figure out what was going on.   Once we figured it out, he committed a fix
 before I could even login to JIRA.  :-)
>>>
>>>
>>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
 line
>>> back tp xstream 1.4.2 to avoid
 http://jira.codehaus.org/browse/XSTR-709
>>>
>>>
>>> Dan
>>>
>>>


 On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
 wrote:

>
> +1
>
> I've tested this with a few projects and it seems to work.
>
> I DON'T like that it updates the war plugin to 2.3 as that version
 has
> issues on the Mac related to setting up an awt Toolkit.   However,
 there is
> a simple workaround of locking the war version down to 2.2 in the
 project
> pom (which is something the project in question should have done
 anyway).
>
> Dan
>
>
>
>> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
 wrote:
>>
>>> Hi,
>>>
>>> Here is a link to Jira with 30 issues resolved:
>>>
>>>
>
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>>
>>> The distributable binaries and sources for testing can be found
 here:
>>>
>>>
>
 https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>>
>>>
>
 https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>>
>>>
>
 https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>>
>>>
>
 https://repository.apache.org/c

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

I honestly don't mind re-spinning. It's not a big deal. What about the compiler 
plugin?

jvz

On 2012-11-28, at 3:38 PM, Benson Margulies  wrote:

> It's an extremely minor annoyance, writing as one of the victims.
> Please don't make Jason re-roll. I have better idea for the use of his
> time.
> 
> On Wed, Nov 28, 2012 at 1:40 PM, Arnaud Héritier  wrote:
>> +1 with Jason to redo it.
>> What do we do ? Excepted this bug the 2.3 was interesting to have for
>> performances improvements and few bug fixes. Could we release a 2.3.1 and
>> then/or in // re-release 3.1.0 ?
>> WDYT ?
>> 
>> 
>> On Wed, Nov 28, 2012 at 7:17 PM, Jason van Zyl  wrote:
>> 
>>> Even for that it's probably worth re-spinning. I think the math is pretty
>>> easy there. It will take me 30 minutes to fix and re-release versus
>>> potentially thousands of people spending 10-20 minutes. People on Macs
>>> using the default version of the WAR plugin is probably not a small number.
>>> Why even expose it.
>>> 
>>> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>>> 
 
 On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
> But what version of the plugin are users going to get?
 
 If it's not locked down, they would get 2.3.  (maven 3.0.x users get
>>> 2.1.3 I think)
 
 
 However, I want to be clear:
 
 * The issue ONLY affects Mac users.  Other platforms are OK.
 
 * The issue only affects users that use the war plugin.
 
 * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
>>> is released).
 
 * Another work around: adding the -Djava.awt.headless=true flag to the
>>> MAVEN_OPTS.
 
 * The issue does NOT affect the output of the war plugin.  The plugin
>>> does exactly what it's supposed to do and produces a proper war.
 
 
 The only "problem" is the Java Icon that would appear on the Mac Dock
>>> for the duration of the build.   It doesn't affect the actual build at all.
 
 So basically, it affects a relatively small number of maven users,
>>> doesn't affect the actual build at all, and has a relatively easy
>>> workaround for people that are annoyed by it.
 
 
 Dan
 
 
 
> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
> 
>> 
>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
>>> wrote:
>> 
>>> there is an issue opened about it ?
>>> I didn't find it.
>> 
>> No, Olivier and I spent a chunk of time yesterday on IRC trying to
>>> figure out what was going on.   Once we figured it out, he committed a fix
>>> before I could even login to JIRA.  :-)
>> 
>> 
>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
>>> line
>> back tp xstream 1.4.2 to avoid
>>> http://jira.codehaus.org/browse/XSTR-709
>> 
>> 
>> Dan
>> 
>> 
>>> 
>>> 
>>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
>>> wrote:
>>> 
 
 +1
 
 I've tested this with a few projects and it seems to work.
 
 I DON'T like that it updates the war plugin to 2.3 as that version
>>> has
 issues on the Mac related to setting up an awt Toolkit.   However,
>>> there is
 a simple workaround of locking the war version down to 2.2 in the
>>> project
 pom (which is something the project in question should have done
>>> anyway).
 
 Dan
 
 
 
> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
>>> wrote:
> 
>> Hi,
>> 
>> Here is a link to Jira with 30 issues resolved:
>> 
>> 
 
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-073/
>> 
>> The distributable binaries and sources for testing can be found
>>> here:
>> 
>> 
 
>>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>> 
>> 
 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>> 
>> 
 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>> 
>> 
 
>>> https://repository.apache.org/content/repositories/maven-073/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 th

Re: [VOTE] Maven 3.1.0

[John Casey]

+1

It appears to work fine on my largest builds here.

On 11/26/12 12:24 AM, Jason van Zyl wrote:

Hi,

Here is a link to Jira with 30 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967

Staging repo:
https://repository.apache.org/content/repositories/maven-073/

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
https://repository.apache.org/content/repositories/maven-073/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




--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

-
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

[Benson Margulies]

It's an extremely minor annoyance, writing as one of the victims.
Please don't make Jason re-roll. I have better idea for the use of his
time.

On Wed, Nov 28, 2012 at 1:40 PM, Arnaud Héritier  wrote:
> +1 with Jason to redo it.
> What do we do ? Excepted this bug the 2.3 was interesting to have for
> performances improvements and few bug fixes. Could we release a 2.3.1 and
> then/or in // re-release 3.1.0 ?
> WDYT ?
>
>
> On Wed, Nov 28, 2012 at 7:17 PM, Jason van Zyl  wrote:
>
>> Even for that it's probably worth re-spinning. I think the math is pretty
>> easy there. It will take me 30 minutes to fix and re-release versus
>> potentially thousands of people spending 10-20 minutes. People on Macs
>> using the default version of the WAR plugin is probably not a small number.
>> Why even expose it.
>>
>> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>>
>> >
>> > On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
>> >> But what version of the plugin are users going to get?
>> >
>> > If it's not locked down, they would get 2.3.  (maven 3.0.x users get
>> 2.1.3 I think)
>> >
>> >
>> > However, I want to be clear:
>> >
>> > * The issue ONLY affects Mac users.  Other platforms are OK.
>> >
>> > * The issue only affects users that use the war plugin.
>> >
>> > * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
>> is released).
>> >
>> > * Another work around: adding the -Djava.awt.headless=true flag to the
>> MAVEN_OPTS.
>> >
>> > * The issue does NOT affect the output of the war plugin.  The plugin
>> does exactly what it's supposed to do and produces a proper war.
>> >
>> >
>> > The only "problem" is the Java Icon that would appear on the Mac Dock
>> for the duration of the build.   It doesn't affect the actual build at all.
>> >
>> > So basically, it affects a relatively small number of maven users,
>> doesn't affect the actual build at all, and has a relatively easy
>> workaround for people that are annoyed by it.
>> >
>> >
>> > Dan
>> >
>> >
>> >
>> >> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
>> >>
>> >>>
>> >>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
>> wrote:
>> >>>
>>  there is an issue opened about it ?
>>  I didn't find it.
>> >>>
>> >>> No, Olivier and I spent a chunk of time yesterday on IRC trying to
>> figure out what was going on.   Once we figured it out, he committed a fix
>> before I could even login to JIRA.  :-)
>> >>>
>> >>>
>> >>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
>> line
>> >>> back tp xstream 1.4.2 to avoid
>> http://jira.codehaus.org/browse/XSTR-709
>> >>>
>> >>>
>> >>> Dan
>> >>>
>> >>>
>> 
>> 
>>  On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
>> wrote:
>> 
>> >
>> > +1
>> >
>> > I've tested this with a few projects and it seems to work.
>> >
>> > I DON'T like that it updates the war plugin to 2.3 as that version
>> has
>> > issues on the Mac related to setting up an awt Toolkit.   However,
>> there is
>> > a simple workaround of locking the war version down to 2.2 in the
>> project
>> > pom (which is something the project in question should have done
>> anyway).
>> >
>> > Dan
>> >
>> >
>> >
>> >> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Here is a link to Jira with 30 issues resolved:
>> >>>
>> >>>
>> >
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>> >>>
>> >>> Staging repo:
>> >>> https://repository.apache.org/content/repositories/maven-073/
>> >>>
>> >>> The distributable binaries and sources for testing can be found
>> here:
>> >>>
>> >>>
>> >
>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>> >>>
>> >>>
>> >
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>> >>>
>> >>>
>> >
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>> >>>
>> >>>
>> >
>> https://repository.apache.org/content/repositories/maven-073/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

Re: [VOTE] Maven 3.1.0

[Arnaud Héritier]

+1 with Jason to redo it.
What do we do ? Excepted this bug the 2.3 was interesting to have for
performances improvements and few bug fixes. Could we release a 2.3.1 and
then/or in // re-release 3.1.0 ?
WDYT ?


On Wed, Nov 28, 2012 at 7:17 PM, Jason van Zyl  wrote:

> Even for that it's probably worth re-spinning. I think the math is pretty
> easy there. It will take me 30 minutes to fix and re-release versus
> potentially thousands of people spending 10-20 minutes. People on Macs
> using the default version of the WAR plugin is probably not a small number.
> Why even expose it.
>
> On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:
>
> >
> > On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
> >> But what version of the plugin are users going to get?
> >
> > If it's not locked down, they would get 2.3.  (maven 3.0.x users get
> 2.1.3 I think)
> >
> >
> > However, I want to be clear:
> >
> > * The issue ONLY affects Mac users.  Other platforms are OK.
> >
> > * The issue only affects users that use the war plugin.
> >
> > * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4
> is released).
> >
> > * Another work around: adding the -Djava.awt.headless=true flag to the
> MAVEN_OPTS.
> >
> > * The issue does NOT affect the output of the war plugin.  The plugin
> does exactly what it's supposed to do and produces a proper war.
> >
> >
> > The only "problem" is the Java Icon that would appear on the Mac Dock
> for the duration of the build.   It doesn't affect the actual build at all.
> >
> > So basically, it affects a relatively small number of maven users,
> doesn't affect the actual build at all, and has a relatively easy
> workaround for people that are annoyed by it.
> >
> >
> > Dan
> >
> >
> >
> >> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
> >>
> >>>
> >>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier 
> wrote:
> >>>
>  there is an issue opened about it ?
>  I didn't find it.
> >>>
> >>> No, Olivier and I spent a chunk of time yesterday on IRC trying to
> figure out what was going on.   Once we figured it out, he committed a fix
> before I could even login to JIRA.  :-)
> >>>
> >>>
> >>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1
> line
> >>> back tp xstream 1.4.2 to avoid
> http://jira.codehaus.org/browse/XSTR-709
> >>>
> >>>
> >>> Dan
> >>>
> >>>
> 
> 
>  On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp 
> wrote:
> 
> >
> > +1
> >
> > I've tested this with a few projects and it seems to work.
> >
> > I DON'T like that it updates the war plugin to 2.3 as that version
> has
> > issues on the Mac related to setting up an awt Toolkit.   However,
> there is
> > a simple workaround of locking the war version down to 2.2 in the
> project
> > pom (which is something the project in question should have done
> anyway).
> >
> > Dan
> >
> >
> >
> >> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Here is a link to Jira with 30 issues resolved:
> >>>
> >>>
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-073/
> >>>
> >>> The distributable binaries and sources for testing can be found
> here:
> >>>
> >>>
> >
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> >>>
> >>>
> >
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> >>>
> >>>
> >
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> >>>
> >>>
> >
> https://repository.apache.org/content/repositories/maven-073/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
> >>>
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev

Re: [VOTE] Maven 3.1.0

[Mark Derricutt]

I'd hazard a guess and say that this might actually be a rather large 
proportion of users.

If we're rolling new things, I'd prefer to see this rolled as a default since 
we're changing said default.

On 29/11/2012, at 6:54 AM, Daniel Kulp  wrote:

> * The issue ONLY affects Mac users.  Other platforms are OK.
> 
> * The issue only affects users that use the war plugin.   

Re: [VOTE] Maven 3.1.0

[Robert Scholte]

I agree with Arnaud: I'm still having trouble with a 3.1 due to the small  
number of really impressive changes, but the majority has decided to make  
it 3.1 [1]


-Robert

[1] http://markmail.org/message/7rvio4c5addzkmo4

Op Wed, 28 Nov 2012 17:35:02 +0100 schreef Jason van Zyl :

Note that I wasn't in favour of calling this 3.1.x. There are no user  
facing features per se but it is an important release, I believe,  
architecturally.


I think it's more important to get the momentum back. We were once  
releasing every six weeks and getting that swing back gets us more  
features for users. But I would be leery of trying to jam in a bunch  
user features when we have lost that momentum. There are still 700 or so  
bugs in JIRA, we lost one of the most important testing facilities in  
the embedded ITs, and I believe the ITs setup is generally flaky. I  
don't believe it's wise to try to provide higher level visibility in the  
form of new features when we have some lower level problems. Not  
releasing for 11 months is rather emblematic of that.


I, at the very least, plan to try and push out two or three more  
releases on a 6 week schedule.  With a primary focus on making the ITs  
run in less than a minute, by whatever means necessary and trying to  
drive the issue count down.


On Nov 28, 2012, at 11:04 AM, Arnaud Héritier   
wrote:



+0
I found no technical regression but I see really few interest in this
release for now.
It is a minor version (due to some technical changes like in 3.0) while
there are only few bug fixes and nothing new interesting for end users.
I'm not against bug fixes releases but in that case we may have tried  
to at

least include something more interesting for end users (like the colored
console from olamy's branch -
https://github.com/aheritier/maven-3/tree/log4j2 - or to fix some real
annoying issues like aether rejecting artifacts from the local  
repository

when we change the mirror id in settings or when a remote repo isn't
available anymore - like when you move artifacts betweens staging  
repos).

It's dead to justify this release in the name of the "release early,
release often strategy" after 11 months thus we may have waited more  
weeks

to have something more interesting.
Thus nothing against it, but nothing in favor of it and I find that sad  
for

end-users.

But anyway, thx for the release and to all people involved in it.

Cheers,

Arnaud


On Wed, Nov 28, 2012 at 3:32 PM, Tony Chemit   
wrote:



On Sun, 25 Nov 2012 22:24:00 -0800
Jason van Zyl  wrote:

+1 (nb)

Works fine on our projects (nuiton.org, chorem.org) and also on some
codehaus mojo.

thanks,

tony.


Hi,

Here is a link to Jira with 30 issues resolved:


https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967


Staging repo:
https://repository.apache.org/content/repositories/maven-073/

The distributable binaries and sources for testing can be found here:


https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip



https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz



https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip



https://repository.apache.org/content/repositories/maven-073/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





--
Tony Chemit

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

-

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Even for that it's probably worth re-spinning. I think the math is pretty easy 
there. It will take me 30 minutes to fix and re-release versus potentially 
thousands of people spending 10-20 minutes. People on Macs using the default 
version of the WAR plugin is probably not a small number. Why even expose it.

On Nov 28, 2012, at 12:54 PM, Daniel Kulp  wrote:

> 
> On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
>> But what version of the plugin are users going to get?
> 
> If it's not locked down, they would get 2.3.  (maven 3.0.x users get 2.1.3 I 
> think)
> 
> 
> However, I want to be clear:
> 
> * The issue ONLY affects Mac users.  Other platforms are OK.
> 
> * The issue only affects users that use the war plugin.   
> 
> * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is 
> released).  
> 
> * Another work around: adding the -Djava.awt.headless=true flag to the 
> MAVEN_OPTS.
> 
> * The issue does NOT affect the output of the war plugin.  The plugin does 
> exactly what it's supposed to do and produces a proper war.
> 
> 
> The only "problem" is the Java Icon that would appear on the Mac Dock for the 
> duration of the build.   It doesn't affect the actual build at all.   
> 
> So basically, it affects a relatively small number of maven users, doesn't 
> affect the actual build at all, and has a relatively easy workaround for 
> people that are annoyed by it.
> 
> 
> Dan
> 
> 
> 
>> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
>> 
>>> 
>>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:
>>> 
 there is an issue opened about it ?
 I didn't find it.
>>> 
>>> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure 
>>> out what was going on.   Once we figured it out, he committed a fix before 
>>> I could even login to JIRA.  :-)
>>> 
>>> 
>>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
>>> back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709
>>> 
>>> 
>>> Dan
>>> 
>>> 
 
 
 On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
 
> 
> +1
> 
> I've tested this with a few projects and it seems to work.
> 
> I DON'T like that it updates the war plugin to 2.3 as that version has
> issues on the Mac related to setting up an awt Toolkit.   However, there 
> is
> a simple workaround of locking the war version down to 2.2 in the project
> pom (which is something the project in question should have done anyway).
> 
> Dan
> 
> 
> 
>> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
>> 
>>> Hi,
>>> 
>>> Here is a link to Jira with 30 issues resolved:
>>> 
>>> 
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>>> 
> https://repository.apache.org/content/repositories/maven-073/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
>>> 
> 
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
 
 
 -- 
 -
 Arnaud Héritier
 06-89-76-64-24
 http://aheritier.net
 Mail/GTalk: aherit...@gmail.com
 Twitter/Skype : aheritier
>>> 
>>> -- 
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
>>> 
>>> -

Re: [VOTE] Maven 3.1.0

[Daniel Kulp]

On Nov 28, 2012, at 12:33 PM, Jason van Zyl  wrote:
> But what version of the plugin are users going to get?

If it's not locked down, they would get 2.3.  (maven 3.0.x users get 2.1.3 I 
think)


However, I want to be clear:

* The issue ONLY affects Mac users.  Other platforms are OK.

* The issue only affects users that use the war plugin.   

* There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is 
released).  

* Another work around: adding the -Djava.awt.headless=true flag to the 
MAVEN_OPTS.

* The issue does NOT affect the output of the war plugin.  The plugin does 
exactly what it's supposed to do and produces a proper war.


The only "problem" is the Java Icon that would appear on the Mac Dock for the 
duration of the build.   It doesn't affect the actual build at all.   

So basically, it affects a relatively small number of maven users, doesn't 
affect the actual build at all, and has a relatively easy workaround for people 
that are annoyed by it.


Dan



> On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:
> 
>> 
>> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:
>> 
>>> there is an issue opened about it ?
>>> I didn't find it.
>> 
>> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure 
>> out what was going on.   Once we figured it out, he committed a fix before I 
>> could even login to JIRA.  :-)
>> 
>> 
>> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
>> back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709
>> 
>> 
>> Dan
>> 
>> 
>>> 
>>> 
>>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
>>> 
 
 +1
 
 I've tested this with a few projects and it seems to work.
 
 I DON'T like that it updates the war plugin to 2.3 as that version has
 issues on the Mac related to setting up an awt Toolkit.   However, there is
 a simple workaround of locking the war version down to 2.2 in the project
 pom (which is something the project in question should have done anyway).
 
 Dan
 
 
 
> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
> 
>> Hi,
>> 
>> Here is a link to Jira with 30 issues resolved:
>> 
>> 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-073/
>> 
>> The distributable binaries and sources for testing can be found here:
>> 
>> 
 https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>> 
>> 
 https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>> 
>> 
 https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>> 
>> 
 https://repository.apache.org/content/repositories/maven-073/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
>> 
 
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
>>> 
>>> 
>>> -- 
>>> -
>>> Arnaud Héritier
>>> 06-89-76-64-24
>>> http://aheritier.net
>>> Mail/GTalk: aherit...@gmail.com
>>> Twitter/Skype : aheritier
>> 
>> -- 
>> Daniel Kulp
>> dk...@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>> 
>> 
>> -
>> 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
> -
> 
> I never make the mistake of arguing with people for whose opinions I have no 
> respect.
> 
> -- Edward Gibbon
> 
> 
> 
> 
> 

-- 
Daniel Kulp
dk...@apache.org - 

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

But what version of the plugin are users going to get?

On Nov 28, 2012, at 11:54 AM, Daniel Kulp  wrote:

> 
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:
> 
>> there is an issue opened about it ?
>> I didn't find it.
> 
> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out 
> what was going on.   Once we figured it out, he committed a fix before I 
> could even login to JIRA.  :-)
> 
> 
> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
> back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709
> 
> 
> Dan
> 
> 
>> 
>> 
>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
>> 
>>> 
>>> +1
>>> 
>>> I've tested this with a few projects and it seems to work.
>>> 
>>> I DON'T like that it updates the war plugin to 2.3 as that version has
>>> issues on the Mac related to setting up an awt Toolkit.   However, there is
>>> a simple workaround of locking the war version down to 2.2 in the project
>>> pom (which is something the project in question should have done anyway).
>>> 
>>> Dan
>>> 
>>> 
>>> 
 On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
 
> Hi,
> 
> Here is a link to Jira with 30 issues resolved:
> 
> 
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-073/
> 
> The distributable binaries and sources for testing can be found here:
> 
> 
>>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> 
> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> 
> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> 
> 
>>> https://repository.apache.org/content/repositories/maven-073/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
> 
>>> 
>>> --
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
>> 
>> -- 
>> -
>> Arnaud Héritier
>> 06-89-76-64-24
>> http://aheritier.net
>> Mail/GTalk: aherit...@gmail.com
>> Twitter/Skype : aheritier
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 
> -
> 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
-

I never make the mistake of arguing with people for whose opinions I have no 
respect.

-- Edward Gibbon

Re: [VOTE] Maven 3.1.0

[Olivier Lamy]

2012/11/28 Daniel Kulp :
>
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:
>
>> there is an issue opened about it ?
>> I didn't find it.
>
> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out 
> what was going on.   Once we figured it out, he committed a fix before I 
> could even login to JIRA.  :-)
>
my bad I missed the jira entry
done http://jira.codehaus.org/browse/MWAR-295
>
> r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
> back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709
>
>
> Dan
>
>
>>
>>
>> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
>>
>>>
>>> +1
>>>
>>> I've tested this with a few projects and it seems to work.
>>>
>>> I DON'T like that it updates the war plugin to 2.3 as that version has
>>> issues on the Mac related to setting up an awt Toolkit.   However, there is
>>> a simple workaround of locking the war version down to 2.2 in the project
>>> pom (which is something the project in question should have done anyway).
>>>
>>> Dan
>>>
>>>
>>>
 On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:

> Hi,
>
> Here is a link to Jira with 30 issues resolved:
>
>
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-073/
>
> The distributable binaries and sources for testing can be found here:
>
>
>>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>
>
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>
>
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>
>
>>> https://repository.apache.org/content/repositories/maven-073/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
>
>>>
>>> --
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>>
>> --
>> -
>> Arnaud Héritier
>> 06-89-76-64-24
>> http://aheritier.net
>> Mail/GTalk: aherit...@gmail.com
>> Twitter/Skype : aheritier
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> -
> 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

[Daniel Kulp]

On Nov 28, 2012, at 11:46 AM, Arnaud Héritier  wrote:

> there is an issue opened about it ?
> I didn't find it.

No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out 
what was going on.   Once we figured it out, he committed a fix before I could 
even login to JIRA.  :-)


r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line
back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709


Dan


> 
> 
> On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:
> 
>> 
>> +1
>> 
>> I've tested this with a few projects and it seems to work.
>> 
>> I DON'T like that it updates the war plugin to 2.3 as that version has
>> issues on the Mac related to setting up an awt Toolkit.   However, there is
>> a simple workaround of locking the war version down to 2.2 in the project
>> pom (which is something the project in question should have done anyway).
>> 
>> Dan
>> 
>> 
>> 
>>> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
>>> 
 Hi,
 
 Here is a link to Jira with 30 issues resolved:
 
 
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-073/
 
 The distributable binaries and sources for testing can be found here:
 
 
>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
 
 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
 
 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
 
 
>> https://repository.apache.org/content/repositories/maven-073/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
 
>> 
>> --
>> Daniel Kulp
>> dk...@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> -
> Arnaud Héritier
> 06-89-76-64-24
> http://aheritier.net
> Mail/GTalk: aherit...@gmail.com
> Twitter/Skype : aheritier

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.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

[Arnaud Héritier]

there is an issue opened about it ?
I didn't find it.


On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp  wrote:

>
> +1
>
> I've tested this with a few projects and it seems to work.
>
> I DON'T like that it updates the war plugin to 2.3 as that version has
> issues on the Mac related to setting up an awt Toolkit.   However, there is
> a simple workaround of locking the war version down to 2.2 in the project
> pom (which is something the project in question should have done anyway).
>
> Dan
>
>
>
> > On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
> >
> >> Hi,
> >>
> >> Here is a link to Jira with 30 issues resolved:
> >>
> >>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-073/
> >>
> >> The distributable binaries and sources for testing can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> >>
> >>
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-073/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
> >>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Well, if you think that's going to catch people out then that's reason to 
change it and spin it again.

I think it might be smarter to release new versions of the plugins and wait a 
cycle to integrate it into a release. This is assuming that we have more 
frequent releases.

It's no bother to spin again so if the compiler and war plugins are causing 
problems that's pretty significant.

On Nov 28, 2012, at 11:33 AM, Daniel Kulp  wrote:

> 
> +1
> 
> I've tested this with a few projects and it seems to work.
> 
> I DON'T like that it updates the war plugin to 2.3 as that version has issues 
> on the Mac related to setting up an awt Toolkit.   However, there is a simple 
> workaround of locking the war version down to 2.2 in the project pom (which 
> is something the project in question should have done anyway).   
> 
> Dan
> 
> 
> 
>> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
>> 
>>> Hi,
>>> 
>>> Here is a link to Jira with 30 issues resolved:
>>> 
>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>>> https://repository.apache.org/content/repositories/maven-073/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
>>> 
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 
> -
> 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
-

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

Re: [VOTE] Maven 3.1.0

[Jason van Zyl]

Note that I wasn't in favour of calling this 3.1.x. There are no user facing 
features per se but it is an important release, I believe, architecturally.

I think it's more important to get the momentum back. We were once releasing 
every six weeks and getting that swing back gets us more features for users. 
But I would be leery of trying to jam in a bunch user features when we have 
lost that momentum. There are still 700 or so bugs in JIRA, we lost one of the 
most important testing facilities in the embedded ITs, and I believe the ITs 
setup is generally flaky. I don't believe it's wise to try to provide higher 
level visibility in the form of new features when we have some lower level 
problems. Not releasing for 11 months is rather emblematic of that.

I, at the very least, plan to try and push out two or three more releases on a 
6 week schedule.  With a primary focus on making the ITs run in less than a 
minute, by whatever means necessary and trying to drive the issue count down.

On Nov 28, 2012, at 11:04 AM, Arnaud Héritier  wrote:

> +0
> I found no technical regression but I see really few interest in this
> release for now.
> It is a minor version (due to some technical changes like in 3.0) while
> there are only few bug fixes and nothing new interesting for end users.
> I'm not against bug fixes releases but in that case we may have tried to at
> least include something more interesting for end users (like the colored
> console from olamy's branch -
> https://github.com/aheritier/maven-3/tree/log4j2 - or to fix some real
> annoying issues like aether rejecting artifacts from the local repository
> when we change the mirror id in settings or when a remote repo isn't
> available anymore - like when you move artifacts betweens staging repos).
> It's dead to justify this release in the name of the "release early,
> release often strategy" after 11 months thus we may have waited more weeks
> to have something more interesting.
> Thus nothing against it, but nothing in favor of it and I find that sad for
> end-users.
> 
> But anyway, thx for the release and to all people involved in it.
> 
> Cheers,
> 
> Arnaud
> 
> 
> On Wed, Nov 28, 2012 at 3:32 PM, Tony Chemit  wrote:
> 
>> On Sun, 25 Nov 2012 22:24:00 -0800
>> Jason van Zyl  wrote:
>> 
>> +1 (nb)
>> 
>> Works fine on our projects (nuiton.org, chorem.org) and also on some
>> codehaus mojo.
>> 
>> thanks,
>> 
>> tony.
>> 
>>> Hi,
>>> 
>>> Here is a link to Jira with 30 issues resolved:
>>> 
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-073/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> 
>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>>> 
>> https://repository.apache.org/content/repositories/maven-073/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
>>> 
>> 
>> 
>> 
>> --
>> Tony Chemit
>> 
>> tél: +33 (0) 2 40 50 29 28
>> email: che...@codelutin.com
>> http://www.codelutin.com
>> 
>> --

Re: [VOTE] Maven 3.1.0

[Daniel Kulp]

+1

I've tested this with a few projects and it seems to work.

I DON'T like that it updates the war plugin to 2.3 as that version has issues 
on the Mac related to setting up an awt Toolkit.   However, there is a simple 
workaround of locking the war version down to 2.2 in the project pom (which is 
something the project in question should have done anyway).   

Dan



> On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl  wrote:
> 
>> Hi,
>> 
>> Here is a link to Jira with 30 issues resolved:
>> 
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-073/
>> 
>> The distributable binaries and sources for testing can be found here:
>> 
>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>> 
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>> 
>> https://repository.apache.org/content/repositories/maven-073/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
>> 

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.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

[Benson Margulies]

+1 (binding)

On Wed, Nov 28, 2012 at 11:04 AM, Arnaud Héritier  wrote:
> +0
> I found no technical regression but I see really few interest in this
> release for now.
> It is a minor version (due to some technical changes like in 3.0) while
> there are only few bug fixes and nothing new interesting for end users.
> I'm not against bug fixes releases but in that case we may have tried to at
> least include something more interesting for end users (like the colored
> console from olamy's branch -
> https://github.com/aheritier/maven-3/tree/log4j2 - or to fix some real
> annoying issues like aether rejecting artifacts from the local repository
> when we change the mirror id in settings or when a remote repo isn't
> available anymore - like when you move artifacts betweens staging repos).
> It's dead to justify this release in the name of the "release early,
> release often strategy" after 11 months thus we may have waited more weeks
> to have something more interesting.
> Thus nothing against it, but nothing in favor of it and I find that sad for
> end-users.
>
> But anyway, thx for the release and to all people involved in it.
>
> Cheers,
>
> Arnaud
>
>
> On Wed, Nov 28, 2012 at 3:32 PM, Tony Chemit  wrote:
>
>> On Sun, 25 Nov 2012 22:24:00 -0800
>> Jason van Zyl  wrote:
>>
>> +1 (nb)
>>
>> Works fine on our projects (nuiton.org, chorem.org) and also on some
>> codehaus mojo.
>>
>> thanks,
>>
>> tony.
>>
>> > Hi,
>> >
>> > Here is a link to Jira with 30 issues resolved:
>> >
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>> >
>> > Staging repo:
>> > https://repository.apache.org/content/repositories/maven-073/
>> >
>> > The distributable binaries and sources for testing can be found here:
>> >
>> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
>> >
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
>> >
>> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
>> >
>> https://repository.apache.org/content/repositories/maven-073/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
>> >
>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> -
> Arnaud Héritier
> 06-89-76-64-24
> http://aheritier.net
> Mail/GTalk: aherit...@gmail.com
> Twitter/Skype : aheritier

-
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

[Arnaud Héritier]

+0
I found no technical regression but I see really few interest in this
release for now.
It is a minor version (due to some technical changes like in 3.0) while
there are only few bug fixes and nothing new interesting for end users.
I'm not against bug fixes releases but in that case we may have tried to at
least include something more interesting for end users (like the colored
console from olamy's branch -
https://github.com/aheritier/maven-3/tree/log4j2 - or to fix some real
annoying issues like aether rejecting artifacts from the local repository
when we change the mirror id in settings or when a remote repo isn't
available anymore - like when you move artifacts betweens staging repos).
It's dead to justify this release in the name of the "release early,
release often strategy" after 11 months thus we may have waited more weeks
to have something more interesting.
Thus nothing against it, but nothing in favor of it and I find that sad for
end-users.

But anyway, thx for the release and to all people involved in it.

Cheers,

Arnaud


On Wed, Nov 28, 2012 at 3:32 PM, Tony Chemit  wrote:

> On Sun, 25 Nov 2012 22:24:00 -0800
> Jason van Zyl  wrote:
>
> +1 (nb)
>
> Works fine on our projects (nuiton.org, chorem.org) and also on some
> codehaus mojo.
>
> thanks,
>
> tony.
>
> > Hi,
> >
> > Here is a link to Jira with 30 issues resolved:
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-073/
> >
> > The distributable binaries and sources for testing can be found here:
> >
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> >
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> >
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> >
> https://repository.apache.org/content/repositories/maven-073/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
> >
>
>
>
> --
> 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
>
>


-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: [VOTE] Maven 3.1.0

[Tony Chemit]

On Sun, 25 Nov 2012 22:24:00 -0800
Jason van Zyl  wrote:

+1 (nb)

Works fine on our projects (nuiton.org, chorem.org) and also on some codehaus 
mojo.

thanks,

tony.

> Hi,
> 
> Here is a link to Jira with 30 issues resolved:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-073/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
> https://repository.apache.org/content/repositories/maven-073/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
> 



-- 
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

[Igor Fedorenko]

+1 (non binding). Tried nexus and m2e builds, both worked without
problems. Also checked that 3.1.0 can be used in m2e as external maven
installation.

--
Regards,
Igor

On 12-11-26 1:24 AM, Jason van Zyl wrote:

Hi,

Here is a link to Jira with 30 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967

Staging repo:
https://repository.apache.org/content/repositories/maven-073/

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-073/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-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip
https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz
https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip
https://repository.apache.org/content/repositories/maven-073/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