Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: <CA+nPnMzFVDTYyrFBbU4bz1g3aK6GAnUor5LdaBgtyFGTU3opmg@mail.gmail.com>
References: <CA+nPnMwEH9Z2myp71uaSrdcyLJRFrE-Vrt20191rd01h+Ufhjw@mail.gmail.com>
 <CALYGm1xb1MOHpsX+7EG8x4bd-zHZ+O95e2Y5Y2DudZiEE6eNCA@mail.gmail.com>
 <op.y867wxh4kdkhrr@desktop-2khsk44.dynamic.ziggo.nl> <E99A04F6-B78E-4B4F-82E9-C89A8FB744DE@talios.com>
 <59ff8258.ecb2df0a.5d316.bc89@mx.google.com> <CACLE=7MKL_6CNvRBnVO6krFxHM86eh88oZQOrH-vtqtsq-QQEA@mail.gmail.com>
 <CA+nPnMxsM1OxiZQun9vjKHbwBgMiwrYEjaB5X4XnFmGLeTZYEA@mail.gmail.com>
 <CACLE=7MVhWsfEjykVQsACu3tuX-_QNWvBRHkRML+AkKmnW3Xcg@mail.gmail.com> <CA+nPnMzFVDTYyrFBbU4bz1g3aK6GAnUor5LdaBgtyFGTU3opmg@mail.gmail.com>
From: Romain Manni-Bucau <rmannibucau@gmail.com>
Date: Mon, 6 Nov 2017 11:16:20 +0100
Message-ID: <CACLE=7MWskmXX8X+zzOC96jqiX55D1nRwjxas-pXY1n6k5vyhg@mail.gmail.com>
Subject: Re: Maven 4.0.0
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 06 Nov 2017 10:30:45 -0000

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.co=
m>:
> 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 th=
e
> 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 progre=
ss,
>> >> 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 describ=
e
>> >> 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 ) b=
ut
>> >> > 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 o=
r
>> >> > 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 classp=
ath
>> >> for
>> >> > say surefire, which can influence behaviour.
>> >> >
>> >> > Mark
>> >> >
>> >> > "The ease with which a change can be implemented has no relevance a=
t
>> all
>> >> > to whether it is the right change for the (Java) Platform for all
>> time."
>> >> =E2=80=94
>> >> > 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