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] > >
