Maven
  1. Maven
  2. MNG-1545

some execution output not routed through default routes.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.5
    • Component/s: Embedding
    • Labels:
      None

      Description

      when running embedded maven I create an instance of EventMonitor, TransferListener and MavenEmbedderLogger.
      however there's still some output that is not received through these means, but rather printoed to standard output (I suppose)
      that's wrong because it prohibits custom handling of output.

      one example that I found is the surefire plugin's output.. everything prepended with [surefire] is printed out wrongly..

        Activity

        Hide
        John Casey added a comment -

        should we re-route system streams to logger, just to guard against plugins doing Bad Things again?

        scanning all the current plugins, etc. may fix this issue for now, but any new plugin (or subsequent update to existing plugins) can re-break it.

        Show
        John Casey added a comment - should we re-route system streams to logger, just to guard against plugins doing Bad Things again? scanning all the current plugins, etc. may fix this issue for now, but any new plugin (or subsequent update to existing plugins) can re-break it.
        Hide
        Arik Kfir added a comment -

        I'm not sure that would be wise - when runningin another application (e.g. an IDE) I wouldn't want Maven to fiddle with external resources such as streams. What if the IDE wants to reroute the system streams to another source?

        I think this should be solved by imposing some other form of validation on the source (perhaps a checkstyle check that fails the build if it finds a System.out?)

        Show
        Arik Kfir added a comment - I'm not sure that would be wise - when runningin another application (e.g. an IDE) I wouldn't want Maven to fiddle with external resources such as streams. What if the IDE wants to reroute the system streams to another source? I think this should be solved by imposing some other form of validation on the source (perhaps a checkstyle check that fails the build if it finds a System.out?)
        Hide
        Brett Porter added a comment -

        I think surefire should be fixed in the later plugins - can you confirm?

        Show
        Brett Porter added a comment - I think surefire should be fixed in the later plugins - can you confirm?
        Hide
        Milos Kleint added a comment -

        brett, which version of surefire do you mean?

        Show
        Milos Kleint added a comment - brett, which version of surefire do you mean?
        Hide
        Brett Porter added a comment -

        surefire plugin 2.2 (surefire 2.0)

        Show
        Brett Porter added a comment - surefire plugin 2.2 (surefire 2.0)
        Hide
        Milos Kleint added a comment -

        still doesn't seem to work for me. when running the build in the IDE, I get the surefire output in the console where I started the IDE from, instead the output window. please note that if you do a System.out in a maven build somewhere, the IDE is capable of catching that one even though it's not routed through the loggers. but with surefire's forking, it's all lost.

        Show
        Milos Kleint added a comment - still doesn't seem to work for me. when running the build in the IDE, I get the surefire output in the console where I started the IDE from, instead the output window. please note that if you do a System.out in a maven build somewhere, the IDE is capable of catching that one even though it's not routed through the loggers. but with surefire's forking, it's all lost.
        Hide
        Milos Kleint added a comment -

        brett: I've done some additional debugging of the surefire plugin problem and I tracked it down the StreamPumper classes that print messages from the forked process to the System.out of the IDE's process. However the delegating System.out impl in the IDE doesn't recognize these threads (StreamPumper is a running thread) as belonging to build being executed and prints them to console. I believe it's because the threads don't belong to the same ThreadGroup. I tried to confirm the theory but surefire cannot be used with the trunk version of plexus-utils.

        please note that even when this is fixed, it still doens't fully satisfy the issues mentioned in this report. In the ideal case one should get the output in the logger/llisteners, which is not the case now and it will only be cought by the IDE's safety net. But it cannot be filtered out, have actions attached to it etc..

        Show
        Milos Kleint added a comment - brett: I've done some additional debugging of the surefire plugin problem and I tracked it down the StreamPumper classes that print messages from the forked process to the System.out of the IDE's process. However the delegating System.out impl in the IDE doesn't recognize these threads (StreamPumper is a running thread) as belonging to build being executed and prints them to console. I believe it's because the threads don't belong to the same ThreadGroup. I tried to confirm the theory but surefire cannot be used with the trunk version of plexus-utils. please note that even when this is fixed, it still doens't fully satisfy the issues mentioned in this report. In the ideal case one should get the output in the logger/llisteners, which is not the case now and it will only be cought by the IDE's safety net. But it cannot be filtered out, have actions attached to it etc..
        Hide
        Milos Kleint added a comment -

        After some more work I think I got it working for netbeans correctly. The StreamPumper not printing was a Netbeans/Mevenide classpath issue.
        Now I have a multiplexing stdout/stderr implementation that is capable of sending the System.out and System.err to the correct output window pane.

        not sure if we can consider the issue fix as the texts are not routed thought the loggers but System.out.

        Show
        Milos Kleint added a comment - After some more work I think I got it working for netbeans correctly. The StreamPumper not printing was a Netbeans/Mevenide classpath issue. Now I have a multiplexing stdout/stderr implementation that is capable of sending the System.out and System.err to the correct output window pane. not sure if we can consider the issue fix as the texts are not routed thought the loggers but System.out.
        Hide
        Jason van Zyl added a comment -

        Milos has figured this out in netbeans using a multiplexing solution in netbeans. This is really a bigger in issue where a set of threadsafe components are not logging to the originating thread but for the time being this issue has been resolved for netbeans.

        Show
        Jason van Zyl added a comment - Milos has figured this out in netbeans using a multiplexing solution in netbeans. This is really a bigger in issue where a set of threadsafe components are not logging to the originating thread but for the time being this issue has been resolved for netbeans.
        Hide
        Brett Porter added a comment -

        but if this works for netbeans doesn't it still need to be fixed for anything else using the embedder? I'm not sure it should be closed.

        Show
        Brett Porter added a comment - but if this works for netbeans doesn't it still need to be fixed for anything else using the embedder? I'm not sure it should be closed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Milos Kleint
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development