Another good feedback from beam (they did a PoC using gradle and are signigicantly faster with gradle): being able to parallelize some plugins (like checkstyle/findbugs/pmd) can be beneficial to the overall soft.
Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-06 11:16 GMT+01:00 Romain Manni-Bucau <[email protected]>: > Can't tackle it before next year but if not done in january sure. > > > 2017-11-06 10:00 GMT+01:00 Stephen Connolly <[email protected]>: >> FYI this seems something that doesnt need to wait for 4.0.0 >> >> If there was a PR for this and enough other small changes I'd be happy to >> roll a 3.5.3 >> >> Do you want to take a stab at it? >> >> (only complexity might be parallel execution, but we could just report the >> linear plan number and when in parallel also log how many have completed) >> >> On 6 November 2017 at 00:51, Romain Manni-Bucau <[email protected]> >> wrote: >> >>> indeed: https://issues.apache.org/jira/browse/MNG-6302 >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn >>> >>> >>> 2017-11-06 9:37 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail. >>> com>: >>> > On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau <[email protected]> >>> > wrote: >>> > >>> >> Forgot a user wish feature: some progress logging somehow. On "big" >>> project >>> >> (actually on project logging a lot) you are easily lost on the progress, >>> >> you know current module is X but you don't know anymore if it is 50% of >>> the >>> >> build or 5%. Having at least "module X / Y" would be helpful. IMO it is >>> >> enough to log it with the module name: >>> >> >>> >> [INFO] >>> >> ------------------------------------------------------------ >>> ------------ >>> >> [INFO] Building Foo 1.0.0-SNAPSHOT >>> >> [INFO] >>> >> ------------------------------------------------------------ >>> ------------ >>> >> [INFO] Module 10 / 100 >>> >> >>> > >>> > Can you file a JIRA? >>> > >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> 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> >>> >> >>> >> 2017-11-05 22:27 GMT+01:00 Bernd Eckenfels <[email protected]>: >>> >> >>> >> > Hello, >>> >> > >>> >> > >>> >> > >>> >> > Adding annotations and processor as a compiletime dependency sounds >>> like >>> >> a >>> >> > reasonable thing. It would however be cool if the JAR could describe >>> >> which >>> >> > package needs to go on the classpath and which is processor impl. (and >>> >> > having a different artifact for runtime) >>> >> > >>> >> > >>> >> > >>> >> > Gruss >>> >> > >>> >> > Bernd >>> >> > >>> >> > >>> >> > >>> >> > *Von: *Mark Derricutt <[email protected]> >>> >> > *Gesendet: *Sonntag, 5. November 2017 22:20 >>> >> > *An: *Maven Developers List <[email protected]> >>> >> > *Betreff: *Re: Maven 4.0.0 >>> >> > >>> >> > >>> >> > >>> >> > On 5 Nov 2017, at 10:42, Robert Scholte wrote: >>> >> > >>> >> > I would like to drop strict scopes in general and give plugins the >>> >> > opportunity to depend on >>> >> > specific scoped dependencies. >>> >> > >>> >> > How would this help with annotations tho? The main issue I'm facing is >>> >> > having a standard m-c-p plugin definition in a parent ( or tile ) but >>> >> > needing different annotation processors used per project. With the >>> >> current >>> >> > plugin, this means either listing them as standard dependencies and >>> have >>> >> > them auto-scanned, and pollute the compilation classpath, or list >>> every >>> >> > possible annotation processor dependency we may use in our projects in >>> >> the >>> >> > parent, which is less than ideal. >>> >> > >>> >> > I hope you are aware that modules already end up on the modulepath >>> based >>> >> > on the moduledescriptor(s). So I don't see the need for this scope. >>> >> (unless >>> >> > you have this wish that in the end Maven will create the module >>> >> descriptor >>> >> > based on this, but I still think we shouldn't do that) >>> >> > >>> >> > I remembered reading something about this, and assumed it was the >>> case if >>> >> > there was a module-info.class, but what if its a standard jar with an >>> >> > Automatic-Module-Name header? Does that fall into the module path or >>> >> > classpath? Having control for this case may be useful. >>> >> > >>> >> > I recognize this wish. The best solution is to make the dependency >>> >> > optional. >>> >> > >>> >> > The problem with this is that the dependency is still on the classpath >>> >> for >>> >> > say surefire, which can influence behaviour. >>> >> > >>> >> > Mark >>> >> > >>> >> > "The ease with which a change can be implemented has no relevance at >>> all >>> >> > to whether it is the right change for the (Java) Platform for all >>> time." >>> >> — >>> >> > Mark Reinhold. >>> >> > >>> >> > Mark Derricutt >>> >> > http://www.theoryinpractice.net >>> >> > http://www.chaliceofblood.net >>> >> > http://plus.google.com/+MarkDerricutt >>> >> > http://twitter.com/talios >>> >> > http://facebook.com/mderricutt >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > --------------------------------------------------------------------- >>> >> > To unsubscribe, e-mail: [email protected] >>> >> > For additional commands, e-mail: [email protected] >>> >> > >>> >> >>> > -- >>> > Sent from my phone >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
