Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow parallel building with checkstyle #109

Merged

Conversation

Bananeweizen
Copy link
Collaborator

Since Eclipse Photon or Oxygen users can enable parallel building of the
workspace. However, parallel building requires all existing project
builders to implement a useful scheduling rule. If builders don't
implement that method, they automatically lock the workspace root.

A simple and still safe implementation for checkstyle is to lock only
the currently analyzed project. That allows all other builders to run on
the remaining projects in parallel.

See https://de.slideshare.net/mickaelistria/parallel-builds-in-eclipse-ide-workspace
for more technical background.

Since Eclipse Photon or Oxygen users can enable parallel building of the
workspace. However, parallel building requires all existing project
builders to implement a useful scheduling root. If builders don't
implement that method, they automatically lock the workspace root.

A simple and still safe implementation for checkstyle is to lock only
the currently analyzed project. That allows all other builders to run on
the remaining projects in parallel.

See https://de.slideshare.net/mickaelistria/parallel-builds-in-eclipse-ide-workspace
for more technical background.
@Bananeweizen Bananeweizen merged commit dc1ad38 into checkstyle:master Oct 29, 2018
@Bananeweizen Bananeweizen deleted the enableParallelWorkspaceBuild branch October 29, 2018 09:34
@romani
Copy link
Member

romani commented Oct 29, 2018

@Bananeweizen , it is better to wait for approval from person of Checkstyle organization.
all approvals from outside are not qualified.

@Bananeweizen
Copy link
Collaborator Author

@romani I don't get that sentence. melloware is a committer, what different people would you expect? At least for the eclipse plugin project, I'm not aware of doing a "steward" review model, where only a privileged group of committers can approve changes. If another committer reviews, that is sufficient to me.

@melloware
Copy link

@Bananeweizen I am not a committer on this project. I am a big fan of it and your change to me seems like an excellent one worth committing. But yes I don't see any "steward" review model posted.

@rnveach
Copy link
Member

rnveach commented Oct 30, 2018

As far as I know it is the same for all github projects. Only admins of the project can merge stuff, which is only people in the checkstyle organization here. Even if me or @romani approved this, we would probably still want someone from eclipse-cs ( @lkoe ) to look it over as we aren't plugin maintainers and we don't know how this change would affect the plugin in eclipse.

@Bananeweizen
Copy link
Collaborator Author

Thanks for the comments. In that case I may have been fooling myself. I thought I already had one other eclipse based review now, and that the merge button was enabled because of that. But probably that was just because I'm a committer on the eclipse plugin repository myself.

Nevertheless, the same change has been applied to the Eclipse Spotbugs, JDT, PDE, and m2e plugins already, so it should be working fine. :)

(Note for testers: If you want to check if performance is improved after this change, then all active implementations of IncrementalProjectBuilder must return a non workspace root scheduling rule. If just a single builder returns the workspace root, then all builders will build with the workspace root as scheduling rule. Therefore testing must happen in a heavily patched eclipse installation as of now.)

@romani
Copy link
Member

romani commented Oct 31, 2018

If another committer reviews, that is sufficient to me.

It is better to stay to approve merge by people who have RW access to repository (maintainers). If any disagreement happened between maintainers, there should be a pause and disagrement should be resolved by any means.
Pleople outside maintainers team are always welcome to share ideas and do review, but they do not allow merge. Only maintainers know what needs to be fixed and how to test and .... .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants