; is
> > > > > > >> the time to do that, with a CLI option (to be removed after
> >
> > 3.7.x)
> >
> > > > to
> > > >
> > > > > > >> pull
> > > > > > >> in the 3.6.x default versions if your pom is missing
a strong reason to update Surefire due to new JRE
> > versions
> > > > > >> > have
> > > > > >> > been
> > > > > >> > updated too many times last two years.
> > > > > >> > They required a fix done within a few
; > >> > updated too many times last two years.
> > > > >> > They required a fix done within a few days and some of them are
> > > > >>
> > > > >> shaking on
> > > > >>
> > > > >> > the chair...
> > > &g
; I want only the same compatibility with default plugins because
> > > >>
> > > >> people do
> > > >>
> > > >> > not see these plugins as a distinct community. They are both Maven
> > > >> > and
>
gins as a distinct community. They are both Maven
> > >> > and
> > >> > plugins from us Apache, so they most probably would expect it
> > >>
> > >> consistent
> > >>
> > >> > altogether.
> > >> > Makes sen
t; >>
> >> modifications to
> >>
> >> > > get to a working build environment. Maven is all about not
> >>
> >> requiring you
> >>
> >> > to
> >> >
> >> > > do that (anymore). So even
>> The warning has been there long enough. Let’s pull the trigger.
> >> >> >>
> >> >> >> On Sat 12 Jan 2019 at 21:34, Tibor Digana
> >> >> >>
> >> >> >> wrote:
> >> >> >> > I have a strong rea
t; >> > plugins from us Apache, so they most probably would expect it
>> >>
>> >> consistent
>> >>
>> >> > altogether.
>> >> > Makes sense?
>> >> >
>> >> > On Sat, Jan 12, 2
t;> > Our Maven Core is stable and Java 9+ ready but the obsolete plugins
> >> >>
> >> >> are
> >> >>
> >> >> > not.
> >> >> > I want only the same compatibility with default plugins because
> >> >>
> >&g
gt;> are
> > > >>
> > > >> > not.
> > > >> > I want only the same compatibility with default plugins because
> > > >>
> > > >> people do
> > > >>
> > > >> > not see these plugins as a distinct community. They are both Maven
>> > wrote:
> >> > > I think that’s a real bad idea if you have to do local
> >> modifications to
> >> > > get to a working build environment. Maven is all about not
> >> requiring you
> >> >
> >> > to
> >> >
> >> > > do that (anymore). So even re
So even requiring a certain Maven Version does
>>
>> not
>>
>> > > fit
>> > > in that pattern (although unavoidable if you do not want to work
>>
>> with
>>
>> > > wrappers).
>> > >
>> > > So this means
t it
> > >>
> > >> consistent
> > >>
> > >> > altogether.
> > >> > Makes sense?
> > >> >
> > >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
> > >>
> > >>
> > >>
> > >>
t; >> modifications to
> >>
> >> > > get to a working build environment. Maven is all about not
> >>
> >> requiring you
> >>
> >> > to
> >> >
> >> > > do that (anymore). So even requi
quiring
> >>>> you
> >>>
> >>> to
> >>>
> >>>> do that (anymore). So even requiring a certain Maven Version does not
> >>>> fit
> >>>> in that pattern (although unavoidable if you do not want to work w
t; > > >> > not.
> > > >> > I want only the same compatibility with default plugins because
> > > >> people do
> > > >> > not see these plugins as a distinct community. They are both Maven
> > and
> > &g
> >> >
> > >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
> > >>
> > >> >
> > >> > wrote:
> > >> > > I think that’s a real bad idea if you have to do local
> > >> modifications to
&
ble if you do not want to work
>> with
>> > > wrappers).
>> > >
>> > > So this means: keep old standard versions and overwrite them
always
>> in
>> > > poms. (And it means the amount of default versions should be
>> reduced or
>> >
t; >> requiring you
> >> >
> >> > to
> >> >
> >> > > do that (anymore). So even requiring a certain Maven Version does
> >> not
> >> > > fit
> >> > > in that pattern (although unavoidable if you do not wa
s
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > ________
> > Von: Robert Scholte
> > Gesendet: Samstag, Januar 12, 2019 5:07 PM
> > An: Maven Developers List
> > Betreff: Re: Update versions of all plugins in defaul
>>
>>>> do that (anymore). So even requiring a certain Maven Version does not
>>>> fit
>>>> in that pattern (although unavoidable if you do not want to work with
>>>> wrappers).
>>>>
>>>> So this means: keep old standard
ns and overwrite them always in
> > > poms. (And it means the amount of default versions should be reduced or
> >
> > at
> >
> > > least not add new ones)
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.ec
ns should be reduced or
> at
> > least not add new ones)
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > ____________
> > Von: Robert Scholte
> > Gesendet: Samstag, Januar 12, 2019 5:07 PM
>
__
> Von: Robert Scholte
> Gesendet: Samstag, Januar 12, 2019 5:07 PM
> An: Maven Developers List
> Betreff: Re: Update versions of all plugins in default-bindings.xml
>
> I had chats with both Adam Bien and Sebastian Daschner asking for a better
> way to work with a si
, Januar 12, 2019 5:07 PM
An: Maven Developers List
Betreff: Re: Update versions of all plugins in default-bindings.xml
I had chats with both Adam Bien and Sebastian Daschner asking for a better
way to work with a simple high-speed throw-away development pom.
They are both working a lot with Java EE
I had chats with both Adam Bien and Sebastian Daschner asking for a better
way to work with a simple high-speed throw-away development pom.
They are both working a lot with Java EE applications and want to rely on
defaults as much as possible.
So in a way they don't care about plugin version
original idea, let's try to evaluate :)
IMHO this could work for packaging plugins in default lifecycle, that are
defined in default-bindings.xml, but would not for other lifecycles that are
configured in components.xml (without copy/pasting content not related to
plugins)
I don't think an ext
Just wondering, can this be solved by an extension?
So instead of changing this in Maven Core itself, people can add an
extension to Maven with the latest+stable releases.
Hervé and I already discovered that current focus is mainly on plugins
right now. We should also work on extensions.
Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a écrit :
> ok, Herve, the fact is that these plugins have been updated from time to
> time.
yes, we did it in the past (years ago, look at the history) and went to the
conclusion we should not do that to improve reproducibility, unless there
yes Michael, exactly, expected this answer.
That's probably the best we can do? Or more?
Perhaps we can cut a beta version of 3.7.0 in prior which is also an option?
What else?
Testing in our private commercial projects.
..
On Fri, Jan 11, 2019 at 1:00 PM Michael Osipov wrote:
> Am 2019-01-11 u
Am 2019-01-11 um 12:55 schrieb Tibor Digana:
ok, Herve, the fact is that these plugins have been updated from time to
time.
How can we be on safe side with these updates? What is mandatory to do for
such upgrade?
Testing...just like I do. See comments MNG-6555. I have found the very
first issu
ok, Herve, the fact is that these plugins have been updated from time to
time.
How can we be on safe side with these updates? What is mandatory to do for
such upgrade?
On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY wrote:
> As I wrote in many Jira issues over years on this topic, I'm not in favor
As I wrote in many Jira issues over years on this topic, I'm not in favor of
that
To me, staying with the same default plugins versions from Maven version to
Maven version is a feature: nobody should expect to change his Maven version
to change the plugins versions
The best practice is to defin
+1 for upgrading all of the plugins
+1 for 3.7.0
Many plugins released recently have improvements in speed and jdk support
Having a new release with all greatest and latest versions will be
very appreciated by users
Enrico
Il giorno gio 10 gen 2019 alle ore 20:50 Stephen Connolly
ha scritto:
>
No reason that we cannot call the next release 3.7.0 and include the bump,
mind you
On Thu 10 Jan 2019 at 16:31, Anders Hammar wrote:
> IMHO it shouldn't be done in a patch release, but rather a minor release
> (3.7.0).
>
> /Anders (mobile)
>
> Den tors 10 jan. 2019 17:09 skrev Tibor Digana :
>
IMHO it shouldn't be done in a patch release, but rather a minor release
(3.7.0).
/Anders (mobile)
Den tors 10 jan. 2019 17:09 skrev Tibor Digana :
> Why we use old versions in default-bindings.xml?
> Can we update all versions in 3.6.1 release?
>
> Here is MNG-6557 which is related to Surefire
Why we use old versions in default-bindings.xml?
Can we update all versions in 3.6.1 release?
Here is MNG-6557 which is related to Surefire but I guess this Jira issue
can be freely related to all plugins.
WDYT?
Any objections to update all plugins and assign this issue in 3.6.1?
Cheers
Tibor
37 matches
Mail list logo
