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 Wed, 08 Nov 2017 20:02:39 GMT
Another good feedback from beam (they did a PoC using gradle and are
signigicantly faster with gradle): being able to parallelize some
plugins (like checkstyle/findbugs/pmd) can be beneficial to the
overall soft.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-06 11:16 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
> Can't tackle it before next year but if not done in january sure.
>
>
> 2017-11-06 10:00 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail.com>:
>> 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
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message