Can gradle team add ProgressLogger and ProgressLoggerFactory to public API?


(Gregory Amerson) #1

This is an old topic but I want to resurrect it when talking about Gradle 3.0. Many plugins will download their own files independent of gradle dependency resolution and it would be nice if we can have access to API to show progress to those developers.

Here is an example of what I was trying to do, but it was using internal APIs.

Here is what it looked like on the console

Could something like this be added to API in 3.0?


(René Pirringer) #2

And the StyledTextOutput too, because I also want to have a nice colored output!


(René Pirringer) #3

I as plugin develop want to be in better control of the output the plugin produces. I want to show a nice progress and also add color to the displayed text.

I’m the author of the gradle xcode plugin that supports building Xcode projects using gradle. Under the hood I use the xcodebuild tool that generates lots of output, and I filter this to only the important stuff. e.g. I show the currently compile file with the ProgressLogger.
Compile errors are logged using a red color to the console, and for warning I use yellow.

I’m really wondering what sense I makes to move the ProgressLogger and StyledTextOutput to private classes?


(Doron Gold) #4

I second that point.

Moving org.gradle.logging.StyledTextOutputStyledTextOutput to org.gradle.internal.logging.text.StyledTextOutput broke my taskTree plugin.
To fix my plugin I now use the internal StyledTextOutput.

Fragile an frowned upon as it may be, this marks yet another dependency that I now have on internal gradle packages.

One other internal gradle class which is very neccessary for plugin development (and which I use in my plugin) is the @Option annotation in org.gradle.api.internal.tasks.options. I would really like to see this one move to a public package.

In general, as a plugin developer, I would be glad to see useful gradle classes move out of internal packages into public packages, instead of the other way around.


(René Pirringer) #5

I had the same problem, and also use the internal packages now.


(Eric Wendelin) #6

I agree that it sucks that the ProgressLogger and StyledTextOutput is internal.

Problems like this were a major topic of discussion in our our planning session, and we will be taking steps in the future to avoid problems like this, in general.

I’m sorry that I don’t have any announcements for you right now, but I expect that you will see significant steps toward enabling the community and plugins like yours in the near future.

Please reach out to me if you have questions or concerns.


What is the state of finer console output control?
(Ryan Ernst) #7

What is the status on adding ProgressLogger back in some way? It has been almost 3 months now since any update was made on this thread, and not only is 3.0 out, but 3.1 is out.

This is incredibly important for anyone with a large custom build. We (elasticsearch, http://github.com/elastic/elasticsearch) are completely stuck on 2.13. We have a custom test task, as well as wrapper around vagrant for packaging tests. For both of these it is important to show status of the underlying process (vagrant command, or test subprocesses) without having to spit out tons of information to the terminal in a normal good build. The compactness of build output to me, I thought, was a key tenant of gradle compared to ant or maven, and one of the (many) motivating factors to switch to it. So to see this sit so long as a blocker for us to using the many improvements in 3.x is frankly frustrating.


(Noam Zwebner) #8

And now it’s been more than a year…