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
Hi,
check SHASUM Ok.
Unfortunately the release package does not work
Checked with Maven 2.2.1, 3.0.5 and failed with the same...
Results :
Tests in error:
ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
/Users/kama/Downloads/maven...
ReadWorkspaceLocationsTest.setUp:57 » FileNotFound
Right, the future proof source for Maven distros should be the central
repo. Primarily because the coordinates will not change.
Den 23 maj 2015 18:53 skrev Hervé BOUTEMY herve.bout...@free.fr:
notice that with Maven 4, in xxx monthes/years..., we probably will have
another /dist/ directory, but
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
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 i...@ifedorenko.com wrote:
I had to troubleshoot a large multithreaded build last week and
Good catch, Karl!
I just checked the previous release (2.9) and it shows a similar problem.
Apperently the .metadata directories don't end up in the sources-zip file.
I've created a JIRA issue for this problem:
https://issues.apache.org/jira/browse/MECLIPSE-760
I'd say it would be sufficient to
Agreed. Fix it and get it out asap ;-)
Andreas Gudian wrote on 25.05.2015 11:00:
Good catch, Karl!
I just checked the previous release (2.9) and it shows a similar problem.
Apperently the .metadata directories don't end up in the sources-zip file.
I've created a JIRA issue for this
