maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Maven 4.0.0
Date Mon, 06 Nov 2017 08:13:32 GMT
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





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 <ecki@zusammenkunft.net>:

> 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 <mark@talios.com>
> *Gesendet: *Sonntag, 5. November 2017 22:20
> *An: *Maven Developers List <dev@maven.apache.org>
> *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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message