Re: logging during multithreaded builds
I know it's not directly related, but any general purpose algorithm that captures to memory buffers needs an overflow to disk mechanism - every time a ByteArrayOutputStream is used for this, some guy with a *huge* output from his build gets an OOM. It's nice you're looking into this issue. As for the actual question of logger implementations, I prefer trivial problems like trying to determine that P=NP. Kristian 2015-05-28 8:39 GMT+02:00 Anders Hammar : > I agree with Jason, it would be better to keep this outside of core (the > core distro). > > /Anders > > On Thu, May 28, 2015 at 5:21 AM, Jason van Zyl wrote: > > > I honestly don't think an optional feature relying on an optional > > dependency belongs in the core itself. > > > > On May 27, 2015, at 10:34 PM, Igor Fedorenko > wrote: > > > > > There are three semi-related parts to my implementation > > > > > > 1. SLF4J MDC management, basically setting and removing project > > > attributes in a thread-local map. Truly reliable implementation will > > > need to be coded in all Builders. Alternatively, it should be possible > > > to use existing lifecycle callbacks to implement mostly reliable > lib/ext > > > extension. > > > > > > 2. Install and configure System out/err and java.util.logging bridges. > > > This can be implemented as lib/ext extension using existing callbacks > > > > > > 3. Custom logback appenders and configuration that provide > "interesting" > > > behaviour using SLF4J MDC. These too can be implemented of the core. > > > > > > Keeping all this in the core will allow marginally more reliable SLF4J > > > MDC management implementation and I also think will make it more likely > > > for other developers to help with the implementation. It will also > serve > > > as a working example for adding support for other logging framework. > But > > > I agree, this does not have to be implemented in the core so I'll try > to > > > rework my implementation as lib/ext extension. > > > > > > -- > > > Regards, > > > Igor > > > > > > On Wed, May 27, 2015, at 06:40 PM, Jason van Zyl wrote: > > >> > > >> On May 27, 2015, at 3:55 PM, Igor Fedorenko > > wrote: > > >> > > >>> So I went ahead and implemented these changes, including working (but > > >>> not terribly well tested) logback appenders to buffer-and-group > project > > >>> console log messages and create per-project build.log files. > > >>> > > >> > > >> What changes were required in the core? > > >> > > >>> Does anyone see a problem if I check in these appenders in maven core > > >>> source tree or you prefer me to keep them elsewhere? > > >>> > > >> > > >> If it's required to alter the distribution to install logback in order > > to > > >> use the appenders then I think elsewhere is more appropriate. As they > > >> won't be used by the standard version of Maven so I don't think it > > >> belongs in core along with the other modules. Maven shared is probably > > >> fine. > > >> > > >>> Just to be clear, I do not propose to "hardware" maven to logback > and I > > >>> do not propose to include logback support in maven distribution. I > want > > >>> to introduce new maven-ext-logback module, which users will be able > to > > >>> use to customize their maven distributions very much the same way > they > > >>> need to do it now to use any of the advanced logging frameworks. > > >>> > > >>> -- > > >>> Regards, > > >>> Igor > > >>> > > >>> On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote: > > I spent some time looking into this, and I think project-level > logging > > will require several semi-related changes. > > > > * As Ralph pointed out, Maven needs to use SLF4J MDC to associate > log > > messages with individual projects being built. This is required to > > enable any project-related logging approach and I plan to submit > this > > change in next couple of days. > > > > * Another problem is use of non-slf4j logging techniques by Maven > > plugins. Direct use of System out/err and java.util.logging are two > > obvious problems and I plan to change maven to "bridge" these to > > slf4j. > > > > * The old log4j 1.x logging and commons-logging need to be bridged > to > > slf4j too. I can make this change in maven, but this is not strictly > > necessary because it can be done from lib/ext extension too. > > > > The rest really depends on whether we can agree on single "advanced" > > logging backend and if we need to support several logging > > configurations. I think we've found three viable project-level > logging > > approaches: buffered console output, better logging pattern and my > > original target/build.log idea. Unless somebody really wants to > > restart > > logback-vs-log4j discussion, I suggest we postpone this decision and > > instead implement project-level logging as out-of-core extensions. > > > > Does this make sense? > > > > -- > > Regards
Re: [ANNOUNCEMENT] End Of Life of Maven 2.2.1 - Plugins / JDK Roadmap
Hi to all, we have accomplished the whole release line which means all plugins are now at minium of Maven 2.2.1 (inkl. Java 1.5) except the known exceptions... https://builds.apache.org/view/All/job/dist-tool-plugin/site/dist-tool-prerequisites.html Congrats to all who supported and helped here. Kind regards Karl Heinz marbaise On 3/20/15 10:39 PM, Karl Heinz Marbaise wrote: Dear Maven Users, based on the End of Life of Maven 2.2.1 (a year ago) now the time has come to make the final releases of Apache Maven Plugins which support Maven 2.X. If you continue to use Maven 2.2.1 or earlier you have to be aware of using an completely unsupported Maven version as well as unsupported Maven plugins for the future. If you want to have access to new features and bug fixes it is really necessary to update to new Maven versions. The next Maven version which will go the same way as Maven 2.2.1 will be Maven 3.0.5. We have documented the final releases of plugins which support Maven 2.2.1 in relationship with JDK 1.5. The complete list can be found here: http://maven.apache.org/maven-2.x-eol.html The next step on our roadmap is to lift all plugin versions to 3.0.0 to make clear those plugins will only work with Maven 3.0+ furthermore the Java minimum requirement will be lifted to JDK 1.6 as well. No "rule" without exceptions. Here they come: * maven-site-plugin (Version 3.4) See the docs of the plugin for usage in Maven 2.X * maven-compiler-plugin (Version 3.2) which works with Maven 2.2.1. * maven-plugin-plugin (Version 3.4) which works with Maven 2.2.1 * maven-pmd-plugin (Version 3.4) which works with Maven 2.2.1 but needs JDK 1.6 The following plugins already have the Maven 3.0+ requirement: * maven-scm-publish-plugin (Version 1.1) * maven-shade-plugin (Version 2.3) Currently the plan is to make those plugins which are already at 3.X being lifted to version 3.5.0 for Maven 3.X only: * maven-site-plugin (Version 3.5.0) * maven-compiler-plugin (Version 3.5.0) * maven-plugin-plugin (Version 3.5.0) * maven-pmd-plugin (Version 3.5.0) All other plugins will get a version 3.0.0 to identify Maven 3.X only plugins and the JDK minimum will be 1.6. Example: So to make things more clearer here is an example: Currently we have the maven-clean-plugin with version 2.6.1. This plugin supports Maven 2.2.1 and JDK 1.5 minimum. This plugin will get a new major release with version 3.0.0 which has the Maven minimum 3.0 AND Java minimum 1.6. Kind regards - The Apache Maven Team - 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: logging during multithreaded builds
I agree with Jason, it would be better to keep this outside of core (the
core distro).
/Anders
On Thu, May 28, 2015 at 5:21 AM, Jason van Zyl wrote:
> I honestly don't think an optional feature relying on an optional
> dependency belongs in the core itself.
>
> On May 27, 2015, at 10:34 PM, Igor Fedorenko wrote:
>
> > There are three semi-related parts to my implementation
> >
> > 1. SLF4J MDC management, basically setting and removing project
> > attributes in a thread-local map. Truly reliable implementation will
> > need to be coded in all Builders. Alternatively, it should be possible
> > to use existing lifecycle callbacks to implement mostly reliable lib/ext
> > extension.
> >
> > 2. Install and configure System out/err and java.util.logging bridges.
> > This can be implemented as lib/ext extension using existing callbacks
> >
> > 3. Custom logback appenders and configuration that provide "interesting"
> > behaviour using SLF4J MDC. These too can be implemented of the core.
> >
> > Keeping all this in the core will allow marginally more reliable SLF4J
> > MDC management implementation and I also think will make it more likely
> > for other developers to help with the implementation. It will also serve
> > as a working example for adding support for other logging framework. But
> > I agree, this does not have to be implemented in the core so I'll try to
> > rework my implementation as lib/ext extension.
> >
> > --
> > Regards,
> > Igor
> >
> > On Wed, May 27, 2015, at 06:40 PM, Jason van Zyl wrote:
> >>
> >> On May 27, 2015, at 3:55 PM, Igor Fedorenko
> wrote:
> >>
> >>> So I went ahead and implemented these changes, including working (but
> >>> not terribly well tested) logback appenders to buffer-and-group project
> >>> console log messages and create per-project build.log files.
> >>>
> >>
> >> What changes were required in the core?
> >>
> >>> Does anyone see a problem if I check in these appenders in maven core
> >>> source tree or you prefer me to keep them elsewhere?
> >>>
> >>
> >> If it's required to alter the distribution to install logback in order
> to
> >> use the appenders then I think elsewhere is more appropriate. As they
> >> won't be used by the standard version of Maven so I don't think it
> >> belongs in core along with the other modules. Maven shared is probably
> >> fine.
> >>
> >>> Just to be clear, I do not propose to "hardware" maven to logback and I
> >>> do not propose to include logback support in maven distribution. I want
> >>> to introduce new maven-ext-logback module, which users will be able to
> >>> use to customize their maven distributions very much the same way they
> >>> need to do it now to use any of the advanced logging frameworks.
> >>>
> >>> --
> >>> Regards,
> >>> Igor
> >>>
> >>> On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
> I spent some time looking into this, and I think project-level logging
> will require several semi-related changes.
>
> * As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
> messages with individual projects being built. This is required to
> enable any project-related logging approach and I plan to submit this
> change in next couple of days.
>
> * Another problem is use of non-slf4j logging techniques by Maven
> plugins. Direct use of System out/err and java.util.logging are two
> obvious problems and I plan to change maven to "bridge" these to
> slf4j.
>
> * The old log4j 1.x logging and commons-logging need to be bridged to
> slf4j too. I can make this change in maven, but this is not strictly
> necessary because it can be done from lib/ext extension too.
>
> The rest really depends on whether we can agree on single "advanced"
> logging backend and if we need to support several logging
> configurations. I think we've found three viable project-level logging
> approaches: buffered console output, better logging pattern and my
> original target/build.log idea. Unless somebody really wants to
> restart
> logback-vs-log4j discussion, I suggest we postpone this decision and
> instead implement project-level logging as out-of-core extensions.
>
> Does this make sense?
>
> --
> Regards,
> Igor
>
> On Tue, May 26, 2015, at 01:13 PM, Ralph Goers wrote:
> > If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x
> and
> > 2.x - you can include anything stored in the MDC on every line of log
> > output. Just use %X to include all MDC items or %MDC{key} to
> include the
> > specific key. This would require storing the value(s) at the
> beginning
> > of every thread.
> >
> > If you include %t in the pattern than every log line should include
> the
> > threadId.
> >
> > If you are saying that the log lines include newlines in them that
> should
> > still be OK. The only way the lines should be mangled
Re: logging during multithreaded builds
I honestly don't think an optional feature relying on an optional dependency
belongs in the core itself.
On May 27, 2015, at 10:34 PM, Igor Fedorenko wrote:
> There are three semi-related parts to my implementation
>
> 1. SLF4J MDC management, basically setting and removing project
> attributes in a thread-local map. Truly reliable implementation will
> need to be coded in all Builders. Alternatively, it should be possible
> to use existing lifecycle callbacks to implement mostly reliable lib/ext
> extension.
>
> 2. Install and configure System out/err and java.util.logging bridges.
> This can be implemented as lib/ext extension using existing callbacks
>
> 3. Custom logback appenders and configuration that provide "interesting"
> behaviour using SLF4J MDC. These too can be implemented of the core.
>
> Keeping all this in the core will allow marginally more reliable SLF4J
> MDC management implementation and I also think will make it more likely
> for other developers to help with the implementation. It will also serve
> as a working example for adding support for other logging framework. But
> I agree, this does not have to be implemented in the core so I'll try to
> rework my implementation as lib/ext extension.
>
> --
> Regards,
> Igor
>
> On Wed, May 27, 2015, at 06:40 PM, Jason van Zyl wrote:
>>
>> On May 27, 2015, at 3:55 PM, Igor Fedorenko wrote:
>>
>>> So I went ahead and implemented these changes, including working (but
>>> not terribly well tested) logback appenders to buffer-and-group project
>>> console log messages and create per-project build.log files.
>>>
>>
>> What changes were required in the core?
>>
>>> Does anyone see a problem if I check in these appenders in maven core
>>> source tree or you prefer me to keep them elsewhere?
>>>
>>
>> If it's required to alter the distribution to install logback in order to
>> use the appenders then I think elsewhere is more appropriate. As they
>> won't be used by the standard version of Maven so I don't think it
>> belongs in core along with the other modules. Maven shared is probably
>> fine.
>>
>>> Just to be clear, I do not propose to "hardware" maven to logback and I
>>> do not propose to include logback support in maven distribution. I want
>>> to introduce new maven-ext-logback module, which users will be able to
>>> use to customize their maven distributions very much the same way they
>>> need to do it now to use any of the advanced logging frameworks.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
I spent some time looking into this, and I think project-level logging
will require several semi-related changes.
* As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
messages with individual projects being built. This is required to
enable any project-related logging approach and I plan to submit this
change in next couple of days.
* Another problem is use of non-slf4j logging techniques by Maven
plugins. Direct use of System out/err and java.util.logging are two
obvious problems and I plan to change maven to "bridge" these to slf4j.
* The old log4j 1.x logging and commons-logging need to be bridged to
slf4j too. I can make this change in maven, but this is not strictly
necessary because it can be done from lib/ext extension too.
The rest really depends on whether we can agree on single "advanced"
logging backend and if we need to support several logging
configurations. I think we've found three viable project-level logging
approaches: buffered console output, better logging pattern and my
original target/build.log idea. Unless somebody really wants to restart
logback-vs-log4j discussion, I suggest we postpone this decision and
instead implement project-level logging as out-of-core extensions.
Does this make sense?
--
Regards,
Igor
On Tue, May 26, 2015, at 01:13 PM, Ralph Goers wrote:
> If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and
> 2.x - you can include anything stored in the MDC on every line of log
> output. Just use %X to include all MDC items or %MDC{key} to include the
> specific key. This would require storing the value(s) at the beginning
> of every thread.
>
> If you include %t in the pattern than every log line should include the
> threadId.
>
> If you are saying that the log lines include newlines in them that should
> still be OK. The only way the lines should be mangled is if each thread
> somehow has its own instance of the logging framework and they are all
> configured to write to the same file.
>
> Ralph
>
>
>
>> On May 25, 2015, at 7:28 AM, Igor Fedorenko wrote:
>>
>> Yes, thread-id will help to some degree, but maven uses multiline log
>> messages quite
Re: logging during multithreaded builds
There are three semi-related parts to my implementation
1. SLF4J MDC management, basically setting and removing project
attributes in a thread-local map. Truly reliable implementation will
need to be coded in all Builders. Alternatively, it should be possible
to use existing lifecycle callbacks to implement mostly reliable lib/ext
extension.
2. Install and configure System out/err and java.util.logging bridges.
This can be implemented as lib/ext extension using existing callbacks
3. Custom logback appenders and configuration that provide "interesting"
behaviour using SLF4J MDC. These too can be implemented of the core.
Keeping all this in the core will allow marginally more reliable SLF4J
MDC management implementation and I also think will make it more likely
for other developers to help with the implementation. It will also serve
as a working example for adding support for other logging framework. But
I agree, this does not have to be implemented in the core so I'll try to
rework my implementation as lib/ext extension.
--
Regards,
Igor
On Wed, May 27, 2015, at 06:40 PM, Jason van Zyl wrote:
>
> On May 27, 2015, at 3:55 PM, Igor Fedorenko wrote:
>
> > So I went ahead and implemented these changes, including working (but
> > not terribly well tested) logback appenders to buffer-and-group project
> > console log messages and create per-project build.log files.
> >
>
> What changes were required in the core?
>
> > Does anyone see a problem if I check in these appenders in maven core
> > source tree or you prefer me to keep them elsewhere?
> >
>
> If it's required to alter the distribution to install logback in order to
> use the appenders then I think elsewhere is more appropriate. As they
> won't be used by the standard version of Maven so I don't think it
> belongs in core along with the other modules. Maven shared is probably
> fine.
>
> > Just to be clear, I do not propose to "hardware" maven to logback and I
> > do not propose to include logback support in maven distribution. I want
> > to introduce new maven-ext-logback module, which users will be able to
> > use to customize their maven distributions very much the same way they
> > need to do it now to use any of the advanced logging frameworks.
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
> >> I spent some time looking into this, and I think project-level logging
> >> will require several semi-related changes.
> >>
> >> * As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
> >> messages with individual projects being built. This is required to
> >> enable any project-related logging approach and I plan to submit this
> >> change in next couple of days.
> >>
> >> * Another problem is use of non-slf4j logging techniques by Maven
> >> plugins. Direct use of System out/err and java.util.logging are two
> >> obvious problems and I plan to change maven to "bridge" these to slf4j.
> >>
> >> * The old log4j 1.x logging and commons-logging need to be bridged to
> >> slf4j too. I can make this change in maven, but this is not strictly
> >> necessary because it can be done from lib/ext extension too.
> >>
> >> The rest really depends on whether we can agree on single "advanced"
> >> logging backend and if we need to support several logging
> >> configurations. I think we've found three viable project-level logging
> >> approaches: buffered console output, better logging pattern and my
> >> original target/build.log idea. Unless somebody really wants to restart
> >> logback-vs-log4j discussion, I suggest we postpone this decision and
> >> instead implement project-level logging as out-of-core extensions.
> >>
> >> Does this make sense?
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Tue, May 26, 2015, at 01:13 PM, Ralph Goers wrote:
> >>> If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and
> >>> 2.x - you can include anything stored in the MDC on every line of log
> >>> output. Just use %X to include all MDC items or %MDC{key} to include the
> >>> specific key. This would require storing the value(s) at the beginning
> >>> of every thread.
> >>>
> >>> If you include %t in the pattern than every log line should include the
> >>> threadId.
> >>>
> >>> If you are saying that the log lines include newlines in them that should
> >>> still be OK. The only way the lines should be mangled is if each thread
> >>> somehow has its own instance of the logging framework and they are all
> >>> configured to write to the same file.
> >>>
> >>> Ralph
> >>>
> >>>
> >>>
> On May 25, 2015, at 7:28 AM, Igor Fedorenko wrote:
>
> Yes, thread-id will help to some degree, but maven uses multiline log
> messages quite often and these will still be mangled and unreadable.
> Per-project build log files is the only solution I found to preserve
> readable logs. Also, each project build is mostly independent from the
> rest and I
Re: logging during multithreaded builds
On May 27, 2015, at 3:55 PM, Igor Fedorenko wrote:
> So I went ahead and implemented these changes, including working (but
> not terribly well tested) logback appenders to buffer-and-group project
> console log messages and create per-project build.log files.
>
What changes were required in the core?
> Does anyone see a problem if I check in these appenders in maven core
> source tree or you prefer me to keep them elsewhere?
>
If it's required to alter the distribution to install logback in order to use
the appenders then I think elsewhere is more appropriate. As they won't be used
by the standard version of Maven so I don't think it belongs in core along with
the other modules. Maven shared is probably fine.
> Just to be clear, I do not propose to "hardware" maven to logback and I
> do not propose to include logback support in maven distribution. I want
> to introduce new maven-ext-logback module, which users will be able to
> use to customize their maven distributions very much the same way they
> need to do it now to use any of the advanced logging frameworks.
>
> --
> Regards,
> Igor
>
> On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
>> I spent some time looking into this, and I think project-level logging
>> will require several semi-related changes.
>>
>> * As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
>> messages with individual projects being built. This is required to
>> enable any project-related logging approach and I plan to submit this
>> change in next couple of days.
>>
>> * Another problem is use of non-slf4j logging techniques by Maven
>> plugins. Direct use of System out/err and java.util.logging are two
>> obvious problems and I plan to change maven to "bridge" these to slf4j.
>>
>> * The old log4j 1.x logging and commons-logging need to be bridged to
>> slf4j too. I can make this change in maven, but this is not strictly
>> necessary because it can be done from lib/ext extension too.
>>
>> The rest really depends on whether we can agree on single "advanced"
>> logging backend and if we need to support several logging
>> configurations. I think we've found three viable project-level logging
>> approaches: buffered console output, better logging pattern and my
>> original target/build.log idea. Unless somebody really wants to restart
>> logback-vs-log4j discussion, I suggest we postpone this decision and
>> instead implement project-level logging as out-of-core extensions.
>>
>> Does this make sense?
>>
>> --
>> Regards,
>> Igor
>>
>> On Tue, May 26, 2015, at 01:13 PM, Ralph Goers wrote:
>>> If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and
>>> 2.x - you can include anything stored in the MDC on every line of log
>>> output. Just use %X to include all MDC items or %MDC{key} to include the
>>> specific key. This would require storing the value(s) at the beginning
>>> of every thread.
>>>
>>> If you include %t in the pattern than every log line should include the
>>> threadId.
>>>
>>> If you are saying that the log lines include newlines in them that should
>>> still be OK. The only way the lines should be mangled is if each thread
>>> somehow has its own instance of the logging framework and they are all
>>> configured to write to the same file.
>>>
>>> Ralph
>>>
>>>
>>>
On May 25, 2015, at 7:28 AM, Igor Fedorenko wrote:
Yes, thread-id will help to some degree, but maven uses multiline log
messages quite often and these will still be mangled and unreadable.
Per-project build log files is the only solution I found to preserve
readable logs. Also, each project build is mostly independent from the
rest and I find reading self-contain per-project log files much easier.
--
Regards,
Igor
On Mon, May 25, 2015, at 10:21 AM, Sean Busbey wrote:
> In multithreaded builds we could add a thread ID to each output line.
> That
> would make it easier to read and filter in different files in post
> processing.
>
> --
> Sean
> On May 25, 2015 6:30 AM, "Igor Fedorenko" wrote:
>
>> I had to troubleshoot a large multithreaded build last week and that
>> proved to be rather difficult mostly because build log was a jumble of
>> messages produced by concurrently running threads. It was not possible
>> to tell which message came from which thread, which made the build log
>> more or less useless.
>>
>> What I ended up doing was to write per-module log message to individual
>> ${project.build.directory}/build.log log files.
>>
>> That was kinda tricky to implement because log files were opened very
>> early during module build and were subsequently deleted by
>> maven-clean-plugin (I tried on Linux and OSX, and I assume the build
>> will fail on Windows). I had to modify maven-clean-plugin configuration
>> in the project pom.xml to retain ${project.build.directory
[ANN] Apache Maven Eclipse Plugin 2.10 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Eclipse Plugin, version 2.10 This plugin is used to generate Eclipse IDE files (*.classpath, *.project, *.wtpmodules and the .settings folder) for use with a project - if the M2E Eclipse-Plugin does not fit you. This release is the last one supporting Maven 2. http://maven.apache.org/plugins/maven-eclipse-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-eclipse-plugin 2.10 Release Notes - Maven Eclipse Plugin - Version 2.10 ** Bug * [MECLIPSE-731] - eclipse:clean not deleting ./settings folder that it creates * [MECLIPSE-738] - NullPointerException in LinkedResource if is present in .project ** Improvement * [MECLIPSE-697] - Delete deprecated code * [MECLIPSE-721] - Improve documentation to explain why Eclipse sometimes does not import projects with correct project names. * [MECLIPSE-754] - UPdate plexus-archiver to 2.9,plexus-utils to 3.0.18 and maven-archiver to 2.5 * [MECLIPSE-756] - Fix RAT Report * [MECLIPSE-757] - Add proper classpath entry names for Java 7 / 8 * [MECLIPSE-758] - Use mojo annotations ** New Feature * [MECLIPSE-759] - Add goal to resolve dependencies in .classpath files of a workspace Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Eclipse Plugin version 2.10
Hi, The vote has passed with the following result: +1 (binding): Karl Heinz Marbaise, Jason van Zyl, Hervé Boutemy +1 (non binding): Andreas Gudian Thank you guys for the votes! I will promote the artifacts to the central repo. 2015-05-27 21:44 GMT+02:00 Andreas Gudian : > Here's my own +1. > > 2015-05-26 23:10 GMT+02:00 Hervé BOUTEMY : > >> +1 >> >> Regards, >> >> Hervé >> >> Le dimanche 24 mai 2015 22:04:52 Andreas Gudian a écrit : >> > Hi, >> > >> > this will be the last Maven 2 compatible release of this plugin. >> > >> > We solved 9 issues: >> > >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423&ve >> > rsion=12330751 >> > >> > There are still a couple of issues left in JIRA: >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20 >> > status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC >> > >> > Staging repo: >> > https://repository.apache.org/content/repositories/maven-1187/ >> > >> https://repository.apache.org/content/repositories/maven-1187/org/apache/mav >> > >> en/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-releas >> > e.zip >> > >> > Source release checksum(s): >> > maven-eclipse-plugin-2.10-source-release.zip sha1: >> > 691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b >> > >> > Staging site: >> > http://maven.apache.org/plugins-archives/maven-eclipse-plugin-LATEST/ >> > >> > Guide to testing staged releases: >> > http://maven.apache.org/guides/development/guide-testing-releases.html >> > >> > Vote open for 72 hours. >> > >> > [ ] +1 >> > [ ] +0 >> > [ ] -1 >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
Re: logging during multithreaded builds
So I went ahead and implemented these changes, including working (but
not terribly well tested) logback appenders to buffer-and-group project
console log messages and create per-project build.log files.
Does anyone see a problem if I check in these appenders in maven core
source tree or you prefer me to keep them elsewhere?
Just to be clear, I do not propose to "hardware" maven to logback and I
do not propose to include logback support in maven distribution. I want
to introduce new maven-ext-logback module, which users will be able to
use to customize their maven distributions very much the same way they
need to do it now to use any of the advanced logging frameworks.
--
Regards,
Igor
On Tue, May 26, 2015, at 03:38 PM, Igor Fedorenko wrote:
> I spent some time looking into this, and I think project-level logging
> will require several semi-related changes.
>
> * As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
> messages with individual projects being built. This is required to
> enable any project-related logging approach and I plan to submit this
> change in next couple of days.
>
> * Another problem is use of non-slf4j logging techniques by Maven
> plugins. Direct use of System out/err and java.util.logging are two
> obvious problems and I plan to change maven to "bridge" these to slf4j.
>
> * The old log4j 1.x logging and commons-logging need to be bridged to
> slf4j too. I can make this change in maven, but this is not strictly
> necessary because it can be done from lib/ext extension too.
>
> The rest really depends on whether we can agree on single "advanced"
> logging backend and if we need to support several logging
> configurations. I think we've found three viable project-level logging
> approaches: buffered console output, better logging pattern and my
> original target/build.log idea. Unless somebody really wants to restart
> logback-vs-log4j discussion, I suggest we postpone this decision and
> instead implement project-level logging as out-of-core extensions.
>
> Does this make sense?
>
> --
> Regards,
> Igor
>
> On Tue, May 26, 2015, at 01:13 PM, Ralph Goers wrote:
> > If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and
> > 2.x - you can include anything stored in the MDC on every line of log
> > output. Just use %X to include all MDC items or %MDC{key} to include the
> > specific key. This would require storing the value(s) at the beginning
> > of every thread.
> >
> > If you include %t in the pattern than every log line should include the
> > threadId.
> >
> > If you are saying that the log lines include newlines in them that should
> > still be OK. The only way the lines should be mangled is if each thread
> > somehow has its own instance of the logging framework and they are all
> > configured to write to the same file.
> >
> > Ralph
> >
> >
> >
> > > On May 25, 2015, at 7:28 AM, Igor Fedorenko wrote:
> > >
> > > Yes, thread-id will help to some degree, but maven uses multiline log
> > > messages quite often and these will still be mangled and unreadable.
> > > Per-project build log files is the only solution I found to preserve
> > > readable logs. Also, each project build is mostly independent from the
> > > rest and I find reading self-contain per-project log files much easier.
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On Mon, May 25, 2015, at 10:21 AM, Sean Busbey wrote:
> > >> In multithreaded builds we could add a thread ID to each output line.
> > >> That
> > >> would make it easier to read and filter in different files in post
> > >> processing.
> > >>
> > >> --
> > >> Sean
> > >> On May 25, 2015 6:30 AM, "Igor Fedorenko" wrote:
> > >>
> > >>> I had to troubleshoot a large multithreaded build last week and that
> > >>> proved to be rather difficult mostly because build log was a jumble of
> > >>> messages produced by concurrently running threads. It was not possible
> > >>> to tell which message came from which thread, which made the build log
> > >>> more or less useless.
> > >>>
> > >>> What I ended up doing was to write per-module log message to individual
> > >>> ${project.build.directory}/build.log log files.
> > >>>
> > >>> That was kinda tricky to implement because log files were opened very
> > >>> early during module build and were subsequently deleted by
> > >>> maven-clean-plugin (I tried on Linux and OSX, and I assume the build
> > >>> will fail on Windows). I had to modify maven-clean-plugin configuration
> > >>> in the project pom.xml to retain ${project.build.directory}/build.log
> > >>> files.
> > >>>
> > >>> I felt my solution required too my effort and I wonder what others do to
> > >>> capture logs during multithreaded builds. Can we come up with a
> > >>> "recommended" way of doing this?
> > >>>
> > >>> --
> > >>> Regards,
> > >>> Igor
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven
Re: [VOTE] Release Apache Maven Eclipse Plugin version 2.10
Here's my own +1. 2015-05-26 23:10 GMT+02:00 Hervé BOUTEMY : > +1 > > Regards, > > Hervé > > Le dimanche 24 mai 2015 22:04:52 Andreas Gudian a écrit : > > Hi, > > > > this will be the last Maven 2 compatible release of this plugin. > > > > We solved 9 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317423&ve > > rsion=12330751 > > > > There are still a couple of issues left in JIRA: > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MECLIPSE%20AND%20 > > status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1187/ > > > https://repository.apache.org/content/repositories/maven-1187/org/apache/mav > > > en/plugins/maven-eclipse-plugin/2.10/maven-eclipse-plugin-2.10-source-releas > > e.zip > > > > Source release checksum(s): > > maven-eclipse-plugin-2.10-source-release.zip sha1: > > 691ad83cb0b731c8c0ab5a6c5f105a25cd34f73b > > > > Staging site: > > http://maven.apache.org/plugins-archives/maven-eclipse-plugin-LATEST/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
