this is the gradle way but it only works because you also have the
dependency chain between plugins in gradle. This is missing in maven (like
group:artifact@execution before group':artifact'@execution' / or after) and
therefore can't be worked out at all with just inputs outputs for backward
compatibility - and if you assume all plugins will migrate, this feature
would be available for end users in a very long time which would be sad.
That is why I thought letting the user helping providing some insights.
Anyway, being able to parallelise the code analyzis, front and back builds
for modules having frontend-maven-plugin + standard java in the same module
etc... would be very beneficial if we can have something working with maven.
> Hi Romain,
> I don't think this is something for the pom.
> It is the plugin which should know if it has effect on the build.
> Or maybe more global: if we could define for the plugin what is input and
> what is output, then it should be possible to decide which parts could run
> in parallel.
> On Fri, 19 Jan 2018 14:20:50 +0100, Romain Manni-Bucau <
> [hidden email]> wrote:
> Hi guys,
>> there is no way to parallelize not conflicting tasks for a same phase at
>> the moment right? Any way it gets under the radar?
>> A common example is to run all code analyzis concurrently (findbugs, pmd,
>> checkstyle, ...) at the same time without waiting for one then the other
>> etc since all can be very long.
>> It could be nice an fancy to define part of the reactor parallelisablity
>> the pom, like:
>> anything to enhance it?
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
> To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] >