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
