he 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 plugin
> > > >
> > > &g
to new JRE
> > versions
> > > > > >> > have
> > > > > >> > been
> > > > > >> > updated too many times last two years.
> > > > > >> > They required a fix done within a few days and some of them
> are
> >
ny times last two years.
> > > > >> > They required a fix done within a few days and some of them are
> > > > >>
> > > > >> shaking on
> > > > >>
> > > > >> > the chair...
> > > > >> > Our Maven Core
bility with default plugins because
> > > >>
> > > >> people do
> > > >>
> > > >> > not see these plugins as a distinct community. They are both Maven
> > > >> > and
> > > >> > plugi
ommunity. They are both Maven
> > >> > and
> > >> > plugins from us Apache, so they most probably would expect it
> > >>
> > >> consistent
> > >>
> > >> > altogether.
> > >> > Makes sense?
> > >&g
t;> modifications to
> >>
> >> > > get to a working build environment. Maven is all about not
> >>
> >> requiring you
> >>
> >> > to
> >> >
> >> > > do that (anymore). So even requiring a certain
Let’s pull the trigger.
> >> >> >>
> >> >> >> On Sat 12 Jan 2019 at 21:34, Tibor Digana
> >> >> >>
> >> >> >> wrote:
> >> >> >> > I have a strong reason to update Surefire due to new JRE
> >>
hey most probably would expect it
>> >>
>> >> consistent
>> >>
>> >> > altogether.
>> >> > Makes sense?
>> >> >
>> >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
>> >&
Java 9+ ready but the obsolete plugins
> >> >>
> >> >> are
> >> >>
> >> >> > not.
> >> >> > I want only the same compatibility with default plugins because
> >> >>
> >> >> people do
> >> >
> > > >> > 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
> >
> >> > > 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 requiring a certain Ma
aven Version does
>>
>> not
>>
>> > > fit
>> > > in that pattern (although unavoidable if you do not want to work
>>
>> with
>>
>> > > wrappers).
>> > >
>> > > So this means: keep old standard versions a
gt;
> > >> consistent
> > >>
> > >> > altogether.
> > >> > Makes sense?
> > >> >
> > >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
> > >>
> > >>
> > >>
> > >> > wrote:
>
tions to
> >>
> >> > > get to a working build environment. Maven is all about not
> >>
> >> requiring you
> >>
> >> > to
> >> >
> >> > > do that (anymore). So even requiring a certain Maven
ng
> >>>> 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 with
&
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
> > >
gt; >
> > >> > 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
> > &
ot 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
>> >
>> >
> 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 want to
; 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 default-bindings
>>
>>>> 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://bern
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
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
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
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
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
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
+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
36 matches
Mail list logo
