Displaying #maven-dev/2017-01-15.log:

Sun Jan 15 08:19:09 2017  tibor_:Joined the channel
Sun Jan 15 09:20:26 2017  hboutemy:tibor_: Hi Tibor
Sun Jan 15 09:20:28 2017  hboutemy:great
Sun Jan 15 09:21:07 2017  hboutemy:I'm currently working on a branch for Aether/Maven Resolver, and it is cool to rework history
Sun Jan 15 09:21:17 2017  tibor_:@hboutemy: you have read my message from yesterday?
Sun Jan 15 09:22:06 2017  hboutemy:I don't know which message you're reffering to
Sun Jan 15 09:22:25 2017  hboutemy:you mean on IRC or an email?
Sun Jan 15 09:22:49 2017  hboutemy:because I have your last 2 messages on IRC from yeserday, yes
Sun Jan 15 09:23:20 2017  tibor_:I checked Oracle JRE implementation and classes FileWriter, OutputStreamWriter have bug because close() does not flush underlying stream. They write remaining or pending data which is kind of flush.
Sun Jan 15 09:23:32 2017  tibor_:IRC
Sun Jan 15 09:23:58 2017  hboutemy:ah, the subtle difference between doing the job and calling the method
Sun Jan 15 09:24:05 2017  tibor_:so, one thing is Javadoc and another is reality
Sun Jan 15 09:24:15 2017  hboutemy:which makes a difference if you extend and override flush
Sun Jan 15 09:24:41 2017  hboutemy:sharing such analysis is interesting
Sun Jan 15 09:24:57 2017  hboutemy:notice that in the case of flush vs close, I'm pragmatic
Sun Jan 15 09:25:15 2017  hboutemy:if we have any fear, just do the explicit fluxh(): this does not cause much harm
Sun Jan 15 09:25:17 2017  hboutemy::)
Sun Jan 15 09:25:26 2017  tibor_:Oracle made a fault because close() is doing two operations
Sun Jan 15 09:25:36 2017  hboutemy:there are other changes that have more consequences
Sun Jan 15 09:26:06 2017  hboutemy:but at least, sharing such analysis can make the team see how supposedly simple things are not that simple
Sun Jan 15 09:26:23 2017  tibor_:exactly flush() does not harm and we are on safe side, but a comment in Maven should be written
Sun Jan 15 09:26:43 2017  tibor_:https://github.com/Tibor17/Java-IO-Research
Sun Jan 15 09:26:51 2017  hboutemy:that's why we need discussion, shared analyses, different eyes, different opinions
Sun Jan 15 09:27:01 2017  hboutemy:then build common analysis and consensus
Sun Jan 15 09:27:02 2017  tibor_:It is not finished yet. Still in my notpad :)
Sun Jan 15 09:27:15 2017  tibor_:yes consensus soon
Sun Jan 15 09:27:27 2017  hboutemy:remember to share little things
Sun Jan 15 09:27:44 2017  tibor_:yes I will
Sun Jan 15 09:28:14 2017  hboutemy:because there are so machy questions in the Surefire case that I rapidly became over-whelmed by too many aspects
Sun Jan 15 09:28:54 2017  hboutemy:I think there are many valid points in every opinion, we "just" need to discuss each separately
Sun Jan 15 09:29:18 2017  tibor_:understand
Sun Jan 15 09:29:39 2017  hboutemy:and what I'm learning from Aether case is that with git, branches can be our best firends to do shared work
Sun Jan 15 09:29:50 2017  hboutemy:before merging into master
Sun Jan 15 09:30:13 2017  hboutemy:people already said it, it is a well known fact, but we didn't do it
Sun Jan 15 09:30:33 2017  tibor_:yeah but the ugly thing with too many branhes is that you have to merge with master
Sun Jan 15 09:30:58 2017  tibor_:committing directly to master is not good
Sun Jan 15 09:30:58 2017  hboutemy:in fact, that's where we must to make our experience to avoid that
Sun Jan 15 09:31:13 2017  hboutemy:branches are not meant to stay for monthes
Sun Jan 15 09:31:27 2017  hboutemy:just for something like 1 week while working with the team
Sun Jan 15 09:31:38 2017  hboutemy:it's another form of what you asked as PR
Sun Jan 15 09:31:41 2017  tibor_:only for very short time and easy changes
Sun Jan 15 09:32:10 2017  hboutemy:in fact, we need to be careful on the definition of "easy" changes
Sun Jan 15 09:32:18 2017  tibor_:PR or branch is similar, maybe matter of taste
Sun Jan 15 09:32:26 2017  hboutemy:how many times I started with a commit and finally did 3 to fix...
Sun Jan 15 09:32:37 2017  hboutemy:PR is github specific
Sun Jan 15 09:32:43 2017  hboutemy:then we need branches
Sun Jan 15 09:33:16 2017  tibor_:ok branch, I will advice CHristan Schulte
Sun Jan 15 09:33:19 2017  hboutemy:and I have no experience with review processes, tooling, apart from github PRs...
Sun Jan 15 09:33:37 2017  tibor_:I usually use GitHub directly
Sun Jan 15 09:33:41 2017  hboutemy:did you have opportunity to chat with him (IRC or anything else)?
Sun Jan 15 09:34:11 2017  hboutemy:or only emails?
Sun Jan 15 09:34:17 2017  tibor_:I was busy this week from my job
Sun Jan 15 09:34:24 2017  hboutemy:yes, that happens :)
Sun Jan 15 09:34:31 2017  tibor_:I came at 8 pm and dead
Sun Jan 15 09:34:59 2017  hboutemy:this WE is the first time for a long time where I am able to code: it's good
Sun Jan 15 09:35:04 2017  tibor_:happens that I wake up in the mornign seen PC running or television
Sun Jan 15 09:35:19 2017  hboutemy:lately, the time I had was busy on managing diverse issues, not funny
Sun Jan 15 09:36:04 2017  hboutemy:I'm like you: I'm in a period when I can wake at 2AM and code until 4AM :)
Sun Jan 15 09:36:18 2017  hboutemy:(code or manage issues...)
Sun Jan 15 09:37:18 2017  hboutemy:I'm happy, I just managed to cherry pick Aether to Maven Resolver renaming
Sun Jan 15 09:37:39 2017  hboutemy:I now just need to do some squashing
Sun Jan 15 09:37:50 2017  hboutemy:but the situation looks stable
Sun Jan 15 09:37:58 2017  tibor_:regarding diverse issues, I am not much coding like others because in the job I am more and more making research or advocate to other's decisions and the work with people and their views is hard and different from pure coding
Sun Jan 15 09:38:06 2017  hboutemy:we should be able to release Maven Resolver 1.0.3 this week
Sun Jan 15 09:38:40 2017  hboutemy:my day work is like you: no coding at all (for years in my case), but advocating
Sun Jan 15 09:40:38 2017  hboutemy:consensus building in a classical enterprise, even if usually F2F, is as hard as consensus at Apache through emails and no common employer :
Sun Jan 15 09:40:42 2017  tibor_:you need a peace while making cherry pick Aether
Sun Jan 15 09:41:03 2017  hboutemy:yes, I need to be sure to have a good number of hours free
Sun Jan 15 09:41:16 2017  hboutemy:I found the hours, it's now quite ready
Sun Jan 15 09:41:39 2017  tibor_:cool
Sun Jan 15 09:42:06 2017  hboutemy:and the renaming step, with so many files renamed, stressed git: I had to do it with command line, because Eclipse git gui could not manage it
Sun Jan 15 09:42:07 2017  tibor_:I will vote for MR 1.0.3
Sun Jan 15 09:42:19 2017  hboutemy:please take time to review
Sun Jan 15 09:42:28 2017  hboutemy:if I did not inject unwanted modifs
Sun Jan 15 09:43:30 2017  hboutemy:since the initial branch where I did the initial changes had in fact already a lot of refactorings in it: Benjamin Bentmann had already worked seriously for 1.1.0-SNAPSHOT
Sun Jan 15 09:46:01 2017  tibor_:If you need us to make a review then please ask the team in ML with a link to the branch.
Sun Jan 15 09:46:29 2017  hboutemy:yes, that's the plan
Sun Jan 15 09:46:44 2017  hboutemy:I'm just teasing you since I have you on IRC ;)
Sun Jan 15 09:47:17 2017  hboutemy:and that's something I feel could be used often
Sun Jan 15 09:47:27 2017  tibor_:exactly
Sun Jan 15 09:47:32 2017  tibor_:let me have a look now
Sun Jan 15 09:47:42 2017  hboutemy:I didn't push yet
Sun Jan 15 09:48:32 2017  hboutemy:I'll do it soon: still want to do some squashing on parts that are not so easy to squash (because of many file renames)
Sun Jan 15 09:48:54 2017  tibor_:https://github.com/apache/maven-resolver does not have your branch yet
Sun Jan 15 09:49:14 2017  tibor_:ok so we will wait, ok?
Sun Jan 15 09:49:19 2017  hboutemy:yes
Sun Jan 15 09:49:22 2017  tibor_:ok
Sun Jan 15 09:49:28 2017  hboutemy:I'll ping you on IRC when I push, if you're here
Sun Jan 15 09:49:35 2017  tibor_:no problem
Sun Jan 15 10:09:33 2017  hboutemy:tibor_: thinking at flush vs close topic while taking a shower...
Sun Jan 15 10:10:10 2017  hboutemy:the fact that flush() method is not called in close() but code to flush internal buffer is copied may be an optimisation
Sun Jan 15 10:10:42 2017  hboutemy:in fact, if I call close() without calling flush(), I can't expect to loose data
Sun Jan 15 10:12:10 2017  hboutemy:the more I think at it, the more I think that calling explicitely flush() does not really make sense: it does not really harm in general (maybe if the stream was on a network with lag, it would not have the same impact)
Sun Jan 15 10:13:16 2017  hboutemy:then I'm not really ok with "Oracle JRE implementation and classes FileWriter, OutputStreamWriter have bug because close() does not flush underlying stream. They write remaining or pending data which is kind of flush"
Sun Jan 15 10:13:33 2017  hboutemy:IMHO, it's not a bug, it's the intent of the API
Sun Jan 15 10:14:05 2017  hboutemy:in fact, if we had access to the TCK, perhaps this would be more explicit
Sun Jan 15 10:15:08 2017  hboutemy:general notice: when looking at something largely used and finding something surprising, I learned to avoid calling it "a bug" but start thinking at "what did I miss?"
Sun Jan 15 10:18:17 2017  hboutemy:notice that with the new Closeable interface, that has close() but no flush(), this looks consistent
Sun Jan 15 10:18:45 2017  hboutemy:not loosing anything kept internal when doing close() is implicit
Sun Jan 15 10:19:26 2017  hboutemy:doing explicit "additionnal" flush() is another feature
Sun Jan 15 10:19:57 2017  hboutemy:in our case, where we in general know which classes we are using, accessing local filesystem, this does not really make difference
Sun Jan 15 10:20:32 2017  hboutemy:but once again, if cost of flush() is important (to sloppy network for exemple), this makes a difference
Sun Jan 15 10:21:29 2017  hboutemy:then after thinking more at it, I would not do "out.flush(); out.close();" but simply "out.close();"
Sun Jan 15 10:21:59 2017  hboutemy:and IIRC, without thinking at it for years, I do like everybody else IMHO: simply out.close()
Sun Jan 15 10:22:09 2017  hboutemy:and that seems reasonable
Sun Jan 15 10:23:01 2017  hboutemy:adding explicit flush() adds 1 line of code (I don't care) and adds a call that may cause performance issues in extreme conditions
Sun Jan 15 10:23:14 2017  hboutemy:I never worked in such extreme conditions :)
Sun Jan 15 10:23:33 2017  hboutemy:but KISS seems reasonable
Sun Jan 15 10:38:51 2017  rfscholte:Joined the channel
Sun Jan 15 11:13:32 2017  tibor_:@hboutemy: Let's wait for my research result. Javadoc of java.io.Writer expressed flush within close() but it is only Writer, but not every implementation of Writer says in Javadoc that close preforms flushing. The implementation does the same like mentioned in Javadoc except for OutputStreamWriter and FileWriter.
Sun Jan 15 11:14:48 2017  tibor_:@hboutemy: becuase of java.io is inconsistent there should not be generic solution.
Sun Jan 15 11:15:35 2017  tibor_:@hboutemy: I mean it is not our fault that some Java IO classes preform close in close() method and some other perform flush+close in close()
Sun Jan 15 11:21:42 2017  tibor_:@hboutemy: Herve, we have another alternative and switch to Java 7 in plugins and avoid all these problem with using Java7 feature called try-with-resources and Java NIO Files for reading and writing in one Java code line http://www.adam-bien.com/roller/abien/entry/java_7_writing_a_string
Sun Jan 15 13:55:27 2017  hboutemy:hboutemy: Java 7 try is using Closable
Sun Jan 15 13:56:05 2017  hboutemy:tibor_: and with Closable, the discussion ends: Closable does not provide flush()
Sun Jan 15 13:56:29 2017  hboutemy:then close() has to do the flush, either explicitely through flush() method either implicitely
Sun Jan 15 13:57:18 2017  hboutemy:(lfew, I cooked a Tartiflette then ate with a "few" glasses of white wine)
Sun Jan 15 13:57:30 2017  hboutemy:(being french is great ;) )
Sun Jan 15 14:14:48 2017  hboutemy:rfscholte: you had issue with your old car? or just wanted to have a great new one now that you're free? ;)
Sun Jan 15 14:33:24 2017  tibor_:Joined the channel
Sun Jan 15 14:38:26 2017  rfscholte:hboutemy: my previous one was a leasecar from the company. Now that I'm a freelancer I need a new one
Sun Jan 15 14:40:42 2017  rfscholte:hboutemy: hmm, can't edit the ASF FOSDEM page
Sun Jan 15 14:41:58 2017  rfscholte:hboutemy: did you see http://maven.markmail.org/thread/5x2dpmy3szzfiv5k ? (adjustment SImpleLogger)
Sun Jan 15 14:46:50 2017  tibor_:@rfscholte: >>He feels that this can interfere in test where System.out is modified in order to capture log output.
Sun Jan 15 14:47:25 2017  tibor_:@rfscholte: This is true if test are running in Maven process (forkCount=0 or forkMode=never)
Sun Jan 15 14:48:18 2017  tibor_:forkCount=0 or forkMode=never should not betherefore used in parallel build => -T 2C
Sun Jan 15 14:50:29 2017  rfscholte:assuming surefire is one of the few capturing System.out, this is something you can verify?
Sun Jan 15 14:57:23 2017  tibor_:Is the email talking about forked jvm in surefire or Maven process? Correcting: the in-plugin VM does not use System.out. The only problem could be in forked JVM.
Sun Jan 15 14:59:26 2017  tibor_:System.out is overridden by ForwardingPrintStream. There is another way when one can access origin of std/out like this: https://docs.oracle.com/javase/7/docs/api/java/io/FileDescriptor.html#out
Sun Jan 15 15:01:11 2017  tibor_:With Kristian Roselvold we were thinking about different approach and avoid transfering commands via std/out. File system is the option byt SecurityManager in JUnit3 fails if using file IO.
Sun Jan 15 15:03:17 2017  rfscholte:Maybe this is a moment to reconsider that option
Sun Jan 15 15:05:06 2017  tibor_:The last fix in 2.19.2 changes the format of the stream. This avoids lines which corrupt the stream. If I recognize magic-number ":maven:surefire:std:out" then I process it; otherwise it goes to dump file.
Sun Jan 15 15:06:02 2017  tibor_:This way we are able to distinguish between our commands or corrupted origin by user.
Sun Jan 15 15:06:37 2017  tibor_:Arquallian had this problem and they avoided using FileDescriptor#out, the link above and used pure System.out
Sun Jan 15 15:06:59 2017  tibor_:So it is usually user fault
Sun Jan 15 15:07:10 2017  rfscholte::)
Sun Jan 15 15:07:14 2017  tibor_::)
Sun Jan 15 15:08:27 2017  tibor_:We must work with file system and be as fast as std/out
Sun Jan 15 15:08:36 2017  rfscholte:agree
Sun Jan 15 15:09:07 2017  tibor_:must flush commands immediatelly
Sun Jan 15 15:09:21 2017  tibor_:otherwise the plugin will hang
Sun Jan 15 15:10:01 2017  tibor_:Arquillian fixed this issue half year ago or so
Sun Jan 15 15:12:20 2017  tibor_:We had a Jira issue but Kriastian did not want to use File system nor Socket. But later he told us that file system is better from two bad options and because of SecurityManager in JUnit3 the file stream would have to be open in the begining of ForkBooter.java
Sun Jan 15 15:13:19 2017  tibor_:So we should write Unit tests with streaming the commands to file system and replace the std/out
Sun Jan 15 15:15:18 2017  tibor_:@rfscholte: ping
Sun Jan 15 15:16:31 2017  rfscholte:yesd
Sun Jan 15 15:17:11 2017  rfscholte:are you still having contact with Kristian about this?
Sun Jan 15 15:18:16 2017  tibor_:cca 3 days ago we talked but only personally, nothing about Maven
Sun Jan 15 15:18:32 2017  tibor_:He wants to retire
Sun Jan 15 15:20:08 2017  rfscholte:he hasn't been that active lately, which often results in a retirement :|
Sun Jan 15 15:20:30 2017  tibor_:yeah I know, but will miss him anyway :)
Sun Jan 15 15:20:40 2017  rfscholte:very true
Sun Jan 15 15:21:50 2017  tibor_:Is this urgent?
Sun Jan 15 15:22:04 2017  tibor_:Did it affect Maven core?
Sun Jan 15 15:22:49 2017  rfscholte:That's why I wanted to ask Hervé. He probably knows best about logging in core.
Sun Jan 15 15:23:32 2017  rfscholte:as long as we don't update SLF4J there's no issue, but if we do, we must be aware of this possible side effect
Sun Jan 15 15:25:03 2017  tibor_:Robert, can you ask Ceki Gülcü which version of SLF4J is not caching System.out ?
Sun Jan 15 15:25:28 2017  tibor_:Did they have it since begining?
Sun Jan 15 15:25:47 2017  rfscholte:you can ask him yourself ;) Just reply to his message
Sun Jan 15 15:33:35 2017  tibor_:I logged in MarkMail but it does not show me the email again
Sun Jan 15 15:34:21 2017  tibor_:Anyway http://jira.qos.ch/browse/SLF4J-389 fixed this issue and it means that the cach was removed in unreleased version 1.7.23
Sun Jan 15 15:34:25 2017  rfscholte:don't you have a mailclient for all the mailing lsits?
Sun Jan 15 15:34:57 2017  tibor_:I have for for maven-dev
Sun Jan 15 15:35:36 2017  rfscholte:message was sent do dev-list last Wednesday
Sun Jan 15 18:58:47 2017  tibor_:Joined the channel
Sun Jan 15 19:17:05 2017  tibor_:@rfscholte: I was away. Did you speak with Herve? The logger version will be changed?
Sun Jan 15 19:36:53 2017  olamy:Joined the channel
Sun Jan 15 19:41:46 2017  hboutemy:tibor_: rfscholte: I must tell that I don't know what is the impact of this change
Sun Jan 15 19:42:07 2017  hboutemy:in fact, AFAIK, plugins may change System.out, but not Maven core
Sun Jan 15 19:42:26 2017  hboutemy:then I suppose Surefire is the most critical part to fear :)
Sun Jan 15 19:43:21 2017  tibor_:surefire has a proxy around system.out only in forked jvm
Sun Jan 15 19:43:58 2017  hboutemy:notice that you can reply to Ceki through Ponymail: https://lists.apache.org/thread.html/29f5905906d9d6a7f6007d3c5bf834af0586d0be3f8c38004753b31a@%3Cdev.maven.apache.org%3E
Sun Jan 15 19:44:01 2017  tibor_:and there the slf4j is not used from maven-core
Sun Jan 15 19:44:29 2017  hboutemy:I don't understand why you tell that slf4j is not used from Maven core
Sun Jan 15 19:46:44 2017  tibor_:Surefire should not influence maven-core because of slf4j
Sun Jan 15 19:46:59 2017  tibor_:Why should we fear?
Sun Jan 15 19:47:44 2017  hboutemy:by "should not", you mean you're sure it won't or you mean "if it does, it's a bug"?
Sun Jan 15 19:48:16 2017  hboutemy:in fact, I'm lost by all this and I don't really get the impact
Sun Jan 15 19:48:49 2017  tibor_:I am lost as well. We should have some proofs and no doubts.
Sun Jan 15 19:49:03 2017  hboutemy:IIUC, before SLF4J-389, SimpleLogger pick System.out value at start then never changes used stream
Sun Jan 15 19:49:33 2017  hboutemy:IIUC, this has never caused any issue to us
Sun Jan 15 19:49:34 2017  tibor_:This is my understanding as well.
Sun Jan 15 19:49:42 2017  tibor_:right
Sun Jan 15 19:49:48 2017  hboutemy:I don't know if some plugin changes System.out value
Sun Jan 15 19:50:17 2017  hboutemy:but before SLF4J-389, this does not change message rendering
Sun Jan 15 19:50:38 2017  tibor_:right
Sun Jan 15 19:50:50 2017  hboutemy:or if some unit tests do such System.out change
Sun Jan 15 19:51:23 2017  hboutemy:with SLF4J-389, if someone changes System.out value, SimpleLogger picks it, then Maven message change destination
Sun Jan 15 19:52:32 2017  tibor_:right
Sun Jan 15 19:53:19 2017  hboutemy:unit tests may change System.out
Sun Jan 15 19:53:31 2017  hboutemy:then this will impact Maven messages
Sun Jan 15 19:53:40 2017  hboutemy:I don't like it...
Sun Jan 15 19:54:21 2017  hboutemy:but I can't prove a precise case currently
Sun Jan 15 19:55:12 2017  hboutemy:does Surefire sometime change System.out value of Maven VM?
Sun Jan 15 19:55:56 2017  hboutemy:(I suppose we don't care about forked VM, because forked VM is fully managed by Surefire monitoring process)
Sun Jan 15 19:56:33 2017  tibor_:I have checked the code in Surefire Providers
Sun Jan 15 19:56:35 2017  tibor_:ConsoleOutputCapture.startCapture( (ConsoleOutputReceiver) reporter );
Sun Jan 15 19:56:56 2017  tibor_:in order to record logs per test
Sun Jan 15 19:57:18 2017  tibor_:It does not harm the Maven nor Surefire
Sun Jan 15 19:57:30 2017  tibor_:but currently
Sun Jan 15 19:57:30 2017  hboutemy:"it" = what?
Sun Jan 15 19:57:47 2017  tibor_:it = changes to slf4j
Sun Jan 15 19:58:09 2017  hboutemy:how does ConsoleOutputCapture.startCapture() work?
Sun Jan 15 19:58:30 2017  tibor_:but currently we may loose slf4j logs if running with forkCount=0 or forkMode=never
Sun Jan 15 19:58:58 2017  tibor_:Not very usual because in-plugin tests running are not set by default
Sun Jan 15 19:59:04 2017  hboutemy:"slf4j logs" = Maven messages
Sun Jan 15 19:59:35 2017  hboutemy:by default, Surefire forks a VM?
Sun Jan 15 19:59:41 2017  tibor_:yes
Sun Jan 15 19:59:47 2017  tibor_:but anyway
Sun Jan 15 19:59:54 2017  tibor_:should not be critical
Sun Jan 15 19:59:56 2017  tibor_:because
Sun Jan 15 20:00:06 2017  tibor_:when the plugin starts
Sun Jan 15 20:00:15 2017  tibor_:it creates extra classloader
Sun Jan 15 20:00:17 2017  tibor_:and
Sun Jan 15 20:00:25 2017  tibor_:even if user used slf4j
Sun Jan 15 20:00:37 2017  tibor_:then it is another SimpleLogger instance
Sun Jan 15 20:00:51 2017  tibor_:so the user will always see his logs in report
Sun Jan 15 20:01:36 2017  hboutemy:the issue is not that content is not captured: the issue is that Maven messages may go to the capture instead of normal messages output
Sun Jan 15 20:01:49 2017  hboutemy:"may" = "will"
Sun Jan 15 20:01:56 2017  tibor_:I doubt Maven prints logs meanwhile Surefire tests are runnign which will be lost, but this will not happen and surefire reports will not see Maven's logs in report
Sun Jan 15 20:03:06 2017  hboutemy:there is never any debug message?
Sun Jan 15 20:03:21 2017  tibor_:in surefire?
Sun Jan 15 20:03:26 2017  hboutemy:yes
Sun Jan 15 20:03:30 2017  tibor_:minimum
Sun Jan 15 20:03:34 2017  tibor_:not usual
Sun Jan 15 20:03:56 2017  hboutemy:I mean: debug messages that will be rendered while in capture mode
Sun Jan 15 20:04:04 2017  tibor_:when plugin starts and when provider starts
Sun Jan 15 20:04:23 2017  tibor_:no
Sun Jan 15 20:04:37 2017  hboutemy:and you're sure you never intend to add?
Sun Jan 15 20:04:50 2017  tibor_:I can check
Sun Jan 15 20:05:12 2017  hboutemy:debug mesage before launching each JUnit test
Sun Jan 15 20:06:30 2017  hboutemy:for Maven , IMHO, having a static destination for slf4j messages was IMHO more a feature than a limitation, since we're sure that plugins or unit tests won't interfere
Sun Jan 15 20:07:10 2017  hboutemy:having slf4j Simple Logger follow changes to System.out IMHO adds ability to interfere
Sun Jan 15 20:07:43 2017  hboutemy:IIUC, you're quite confident that Surefire itself won't interfere
Sun Jan 15 20:08:19 2017  tibor_:log.debug( bootClasspath.getLogMessage( "boot" ) ); log.debug( bootClasspath.getCompactLogMessage( "boot(compact)" ) );
Sun Jan 15 20:08:27 2017  tibor_:log.debug( "Forking command line: " + cli );
Sun Jan 15 20:08:48 2017  tibor_:This is printed before and after forked JVM
Sun Jan 15 20:08:50 2017  tibor_:So yes
Sun Jan 15 20:09:22 2017  hboutemy:no WARN or no ERROR also?
Sun Jan 15 20:09:46 2017  tibor_:If you run several JVMs in parallel then you can see debug maven's log between two forks
Sun Jan 15 20:10:02 2017  tibor_:let me check
Sun Jan 15 20:14:14 2017  tibor_:warning or error if std/out in forked jvm was corrupted
Sun Jan 15 20:17:19 2017  hboutemy:when I see surefire-api/src/main/java/org/apache/maven/surefire/report/ConsoleOutputCapture.java:import static java.lang.System.setOut;
Sun Jan 15 20:18:14 2017  hboutemy:this is the type of System.out change that will cause Maven messages to follow the change
Sun Jan 15 20:18:45 2017  tibor_:and this is called in the begin of provider starts up
Sun Jan 15 20:19:40 2017  hboutemy:or ./shared/maven-verifier/src/main/java/org/apache/maven/it/Verifier.java: System.setOut( originalOut );
Sun Jan 15 20:19:40 2017  hboutemy:./shared/maven-verifier/src/main/java/org/apache/maven/it/Verifier.java: System.setOut( new PrintStream( outStream ) );
Sun Jan 15 20:19:50 2017  tibor_:the maven calls to system.out always go to the origin System.out
Sun Jan 15 20:20:29 2017  hboutemy:IIUC, SLF4J-389 will change that
Sun Jan 15 20:21:02 2017  tibor_:do they call System.setOut() ?
Sun Jan 15 20:21:33 2017  hboutemy:"they" = code in trunks
Sun Jan 15 20:21:38 2017  hboutemy:I did a find . -name "*.java" -exec grep -H "System.setOut" {} \;
Sun Jan 15 20:21:46 2017  tibor_:they = SLF4J-389
Sun Jan 15 20:22:25 2017  hboutemy:IIUC (but I'm not sure), SLF4J-389 is not about changing JVM's System.out
Sun Jan 15 20:22:39 2017  hboutemy:it's about SimpleLogger to follow System.out setting
Sun Jan 15 20:23:08 2017  hboutemy:instead of catching initial value and keeping it whatever happens to Sytem.out after
Sun Jan 15 20:23:59 2017  tibor_:I cloned slf4j and did not find "setout"
Sun Jan 15 20:24:31 2017  hboutemy:http://jira.qos.ch/browse/SLF4J-389
Sun Jan 15 20:24:36 2017  tibor_:I see
Sun Jan 15 20:25:22 2017  tibor_:One way or another, if they call.System.out.println() the message must go to the JVM's stream. Right?
Sun Jan 15 20:26:00 2017  tibor_:If they cache it or not the result will be the same. Right?
Sun Jan 15 20:26:08 2017  hboutemy:they = who?
Sun Jan 15 20:26:17 2017  tibor_:SLF4J
Sun Jan 15 20:26:46 2017  hboutemy:the questionis not there
Sun Jan 15 20:27:13 2017  hboutemy:the question is that with SLF4J-389, Maven messages follow System.out
Sun Jan 15 20:27:50 2017  hboutemy:before, initial System.out value was used for the whole life of the build
Sun Jan 15 20:28:41 2017  tibor_:Is Maven setting setOut ?
Sun Jan 15 20:28:49 2017  tibor_:with colors
Sun Jan 15 20:29:00 2017  hboutemy:no
Sun Jan 15 20:29:57 2017  hboutemy:color is just normal display, just escape codes
Sun Jan 15 20:30:15 2017  hboutemy:(and additional magic on Windows...)
Sun Jan 15 20:31:49 2017  tibor_:It should be tried; otherwise I don't see a problem.
Sun Jan 15 20:32:13 2017  tibor_:I am thinking..
Sun Jan 15 20:34:31 2017  tibor_:With SLF4J-389 the writes to immediate System.out will bypass ConsoleOutputCapture but the logs finally appear on console.
Sun Jan 15 20:35:19 2017  tibor_:Surefire's debug/error/warn logs go to console which is the purpose and the purpose is not to have own debug/error/warn in reports.
Sun Jan 15 20:37:13 2017  tibor_:Hey a moment. If user has 1.7.23 and has forkMode=never then it is a problem.
Sun Jan 15 20:38:15 2017  tibor_:because the user may want to redirect the logs from test method to a file and 1.7.23 may break this feature in Surefire.
Sun Jan 15 20:39:56 2017  tibor_:No, oposite. With older versions than 1.7.23 now the surefire should not work.
Sun Jan 15 20:40:00 2017  tibor_:We should try.
Sun Jan 15 20:41:41 2017  tibor_:@hboutemy: are you here?
Sun Jan 15 20:41:48 2017  hboutemy:yes
Sun Jan 15 20:43:03 2017  hboutemy:tibor_: yes
Sun Jan 15 20:43:04 2017  tibor_:The point is that SLF4J must print to immediate std/out because there we are able to redirect user's SLJ4F logs from console to a file.
Sun Jan 15 20:43:35 2017  tibor_:So SLF4J-389 looks to me as a good change. WDYT?
Sun Jan 15 20:44:04 2017  hboutemy:it worked before SLF4J-389, then we don't need the change
Sun Jan 15 20:44:11 2017  tibor_:ah
Sun Jan 15 20:44:14 2017  tibor_:but
Sun Jan 15 20:44:24 2017  tibor_:usually you use forked mode
Sun Jan 15 20:44:31 2017  hboutemy:MavenCli does the System.out change before slf4j init
Sun Jan 15 20:44:33 2017  tibor_:when do you set this
Sun Jan 15 20:44:43 2017  tibor_:forkMode=never or forkCount=0
Sun Jan 15 20:46:28 2017  hboutemy:for sure, Surefire when forkMode=never make user code being able to interfere with Maven messages
Sun Jan 15 20:46:42 2017  hboutemy:redirect them
Sun Jan 15 20:46:49 2017  hboutemy:when previously, it could not
Sun Jan 15 20:48:11 2017  tibor_:so?
Sun Jan 15 20:51:03 2017  hboutemy:if some code (plugin or unit test in forkMode=never) changes System.out to a personal file
Sun Jan 15 20:51:13 2017  hboutemy:then you loose Mave messages
Sun Jan 15 20:51:49 2017  tibor_:No I do not think so.
Sun Jan 15 20:52:15 2017  tibor_:Normally Maven does not print meanwhile test is running.
Sun Jan 15 20:52:29 2017  hboutemy:you're only thinking at Surefire
Sun Jan 15 20:52:34 2017  hboutemy:I'm thinking at any plugin
Sun Jan 15 20:53:08 2017  hboutemy:a plugin that redirects System.out then uses Maven API (that logs debugs, warnings)
Sun Jan 15 20:53:09 2017  tibor_:If the code which calls setOut and if the code guarantees that claaing setOut with previous origin then the Maven goes no.
Sun Jan 15 20:53:49 2017  hboutemy:then perfectly reset System.out, ok: let's make it clean :)
Sun Jan 15 20:54:03 2017  tibor_:this is done in surefire
Sun Jan 15 20:54:07 2017  hboutemy:but during the changed System.out, messages are lost
Sun Jan 15 20:54:17 2017  hboutemy:(or redirected)
Sun Jan 15 20:54:18 2017  tibor_:but of course if user harms the build, then it is his fault
Sun Jan 15 20:54:35 2017  hboutemy:until now, the user did not harm the build
Sun Jan 15 20:55:14 2017  hboutemy:since SimpleLogger destination was independant of effective System.out value: it had been cached
Sun Jan 15 20:55:30 2017  tibor_:yes, during the change the logs are lost. But this is an exception in Surefire becuase this happens with non-default setting forkMode=never => very unusual.
Sun Jan 15 20:55:59 2017  hboutemy:ok, I understand that Unit tests should not be an issue
Sun Jan 15 20:56:20 2017  hboutemy:but there is still if a plugin does such thing
Sun Jan 15 20:57:04 2017  hboutemy:maven-script-interpreter/src/main/java/org/apache/maven/shared/scriptinterpreter/GroovyScriptInterpreter.java: System.setOut( scriptOutput );
Sun Jan 15 20:57:31 2017  hboutemy:looks like System.out is redirected while executing a Groovy script
Sun Jan 15 20:57:49 2017  hboutemy:notice that in this case, there should not be any Maven API call...
Sun Jan 15 20:58:04 2017  tibor_:right
Sun Jan 15 20:58:05 2017  hboutemy:(or if there is, it could be changed)
Sun Jan 15 20:58:27 2017  tibor_:but here is a problem becaus ethe Maven parallel build -T 2C
Sun Jan 15 20:58:33 2017  hboutemy:because until now, the plugin didn't try to make the System.out swap as late as possible
Sun Jan 15 20:59:01 2017  hboutemy:yes, in Maven core, parallel build is the other location where there is a System.setOut()
Sun Jan 15 20:59:16 2017  tibor_::)
Sun Jan 15 20:59:17 2017  hboutemy:maven/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/ThreadOutputMuxer.java: System.setOut( new ThreadBoundPrintStream( this.originalSystemOUtStream ) );
Sun Jan 15 20:59:19 2017  tibor_:concurrency
Sun Jan 15 21:00:34 2017  tibor_:kind of ThreadLocal as it seem, then okay
Sun Jan 15 21:12:05 2017  tibor_:@hboutemy: In parallel build it will be worse. We need to have the first System.out, whatever the plugins override to. wdyt?
Sun Jan 15 21:29:41 2017  tibor_:It looks like users with SLF4J:1.7.23 would have expected behavior of Surefire (forkMode=never & redirect). Worse for Maven and SLF4J should provide us with configuration to follow legacy behavior.
Sun Jan 15 21:30:47 2017  tibor_:@hboutemy: Am I right with my statement?
Sun Jan 15 21:33:46 2017  hboutemy:I don't really understand the way it is told
Sun Jan 15 21:34:13 2017  hboutemy:" Worse for Maven and SLF4J should provide us with configuration to follow legacy behavior."
Sun Jan 15 21:35:00 2017  hboutemy:or " In parallel build it will be worse. We need to have the first System.out, whatever the plugins override to. wdyt?"
Sun Jan 15 21:42:56 2017  tibor_:If a pugin redirects "his" logs, then the maven logs should not be influence and printed anyway. This is what i mean.
Sun Jan 15 21:43:11 2017  tibor_:still imaging parallel build
Sun Jan 15 22:09:16 2017  tibor_:@hboutemy: I sent an email to Christian in ML. I hope we will continue because now we have freeze.

Comments