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:51:49 GMT
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
View raw message