maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Maven 4.0.0
Date Mon, 06 Nov 2017 09:00:44 GMT
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 <rmannibucau@gmail.com>
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 <rmannibucau@gmail.com>
> > 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 <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
> >> >
> >>
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> 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