| I think if we have a default of ‘max parallel builds: 1’ (or alternatively, ‘parallel builds: false’ and no-one knows about the feature, it’s as good as non existent to those who use Eclipse.
Can we update the default to ‘true’ or ‘max processors’ or ‘half processors’ or similar, so we can enable it out of the box for every project build type? If not, what’s stoppping us from doing so?
Alex Sent from my iPhone 📱 On 22 Jan 2021, at 11:15, Mickael Istria <mistria@xxxxxxxxxx> wrote:
That said, practice in my world is that I do not see anybody using it. From my perspective it still looks highly experimental in the Java world, which for me is the 'this' and it looks like that 'this' could have some nudges to move it 'forward', like documentation, usable preferences, test suites, promotion?
Note that there is a usable preference ("max simultaneous project builds"), there is some documentation with javadoc and actually there is nothing "new" to do for integrators/adopters, they just need to use the narrowest scheduling rule possible for their builders and that's all; there are test suites and there was promotion with the EclipseCon talk, release notes, release video...
But there is never too much of that, so contributions to improve all that would indeed be really welcome!
One question. I do not understand the language server idea in relation to 'this'. In Bndtools we integrate the results of many different projects, using different languages and generators to create different distributions. How can the language server model help to parallelize this?
With language servers and debug adapters and devops as well, having the IDE to continuously orchestrate and run builds is often useless, builds get encapsulated in the Language Server and/or Debug Adapter to run when they're needed without IDE to be involved. And then, when a test pass, people usually run their full build with CLI or pushing it on some review service with CI hooks to get the full result of their work in the more official build. So this makes parallel build less interesting for most non-Java related cases.
|
