e-mail address has changed. Please remove verha...@sander.com
> now
> > and start using san...@sanderverhagen.net from now on. Please update
> your
> > address book. Thank you!
>
> >
> >
> > > -----Original Message-
> > > From: Hervé BOUTEMY [mailto:her
hanged. Please remove verha...@sander.com now
> and start using san...@sanderverhagen.net from now on. Please update your
> address book. Thank you!
>
>
> > -Original Message-
> > From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> > Sent: Tuesday, July 14, 2015 1
We were discussing which version to use for core dependencies. Assembly
plugin will not be 3.0 unless you do it yourself.
Kristian
2015-07-16 22:18 GMT+02:00 Robert Scholte :
> The reason why you're not sure of the exact version explains why we ended
> up with simply 3.0 :)
> Now it is clear
[joke]
If you're really stuck I can invoke a claim that we agreed X and we can
rely on everyone else being too lazy to find the counter-evidence on the
mailing list archives!
[/joke]
More seriously, I remember a discussion but my memory fails me on the exact
version we settled on... Anything less
The reason why you're not sure of the exact version explains why we ended
up with simply 3.0 :)
Now it is clear for everybody.
Robert
Op Wed, 15 Jul 2015 08:43:59 +0200 schreef Kristian Rosenvold
:
14. jul. 2015 21.04 skrev "Robert Scholte"
mvn clean verify -Prun-its -Dinvoker.mavenHome=
Well I suppose you're right.
The wiki document does not represent formal project policy anyway.
Kristian
2015-07-14 21:58 GMT+02:00 Robert Scholte :
> I'd say as much as possible. I'm completely aware that not all can be
> removed, but a move from 2.x ot 3.x is THE moment to do these kind of
14. jul. 2015 21.04 skrev "Robert Scholte" mvn clean verify -Prun-its -Dinvoker.mavenHome=d:\apache-maven-3.0 fails
on my machine
>
We are 3.0.3/4/5 minimum, which I believe is in accordance with our
discussions. Cant remember exactly which versjon though :)
I want to point out that the original set of changes here was a
complete violation of the principles Jason raised in the first place.
It was a completely breaking change, introduced incompatibly. Anyone
who had been pushing foo.filtered files around before it was out of
luck afterwards.
On Tue, Ju
I'd say as much as possible. I'm completely aware that not all can be
removed, but a move from 2.x ot 3.x is THE moment to do these kind of
changes. If you take a look at the Mojo's, most of them are already that
much refactored that they are kind of empty classes, extending the same
Abstra
If point 5.3 is to be interpreted to mean "any" deprecations it officially
has my minus one, since it's simply not going to happen and it is a silly
requirement. We're using 3.0.0 to move maven version,not to settle a new
continent with lots of natives we can oppress.
5.3 is not a code change, so
Op Tue, 14 Jul 2015 20:46:50 +0200 schreef Kristian Rosenvold
:
2015-07-14 20:06 GMT+02:00 Robert Scholte :
Hi Benson,
this is not the 3.0 version of a plugin I had in mind. For instance, it
isn't compatible with all Maven3 versions and there's still a lot of
cleanup to do[1]
It's compat
A little list,
1: we have an agreement, as a project, to bump major versions when
someone is willing to do the Maven 3.x/Java 1.6 transition. There does
not have to be any particularly interesting set of changes to the
plugin, just that. I didn't make the POM changes, for that, I just
found them,
Hi Kristian,
On 7/14/15 8:51 PM, Kristian Rosenvold wrote:
I have already updated this requirements to maven 3.x and moved the
version to 3.0.0.
If this is already done which i not deeply dived/checked etc.
so no problem go for it...
If you for some reason think Benson requires to jump
thr
I have already updated this requirements to maven 3.x and moved the version
to 3.0.0. If you for some reason think Benson requires to jump through some
special hoops for legacy support on this I'd find that largely amusing,
given the versioning strategy we have been discussing wrt 3.x move.
Kristi
2015-07-14 20:06 GMT+02:00 Robert Scholte :
> Hi Benson,
>
> this is not the 3.0 version of a plugin I had in mind. For instance, it
> isn't compatible with all Maven3 versions and there's still a lot of
> cleanup to do[1]
>
It's compatible with all 3.x versions, but I did this before your shared
y, July 14, 2015 10:53
> To: Maven Developers List
> Subject: Re: Intend to release maven-assembly-plugin 3.0.0
>
> blame done and found the inital commit for the 2 excludes:
> see https://issues.apache.org/jira/browse/MASSEMBLY-777
>
> Regards,
>
> Hervé
>
>
Hi Benson,
this is not the 3.0 version of a plugin I had in mind. For instance, it
isn't compatible with all Maven3 versions and there's still a lot of
cleanup to do[1]
Other messages are clear was well, especially from Hervé about trying to
figure out why these extensions are special.
; From: Benson Margulies [mailto:bimargul...@gmail.com]
> > Sent: Tuesday, July 14, 2015 10:05
> > To: Maven Developers List
> > Subject: Re: Intend to release maven-assembly-plugin 3.0.0
> >
> >
> > > If it’s easy to make compatible why would you not do
> -Original Message-
> From: Benson Margulies [mailto:bimargul...@gmail.com]
> Sent: Tuesday, July 14, 2015 10:05
> To: Maven Developers List
> Subject: Re: Intend to release maven-assembly-plugin 3.0.0
>
> > If it’s easy to make compatible why would you not do it?
&
Hi Benson,
I have taken a look and i see only a small change which is very good
idea to do so, but which means the upgrade to 3.0.0 does not make sense.
An update to 3.0.0 indicates very important things to the user which is
not the case and that means 3.0.0 is more compatible to 2.5.X which
> If it’s easy to make compatible why would you not do it?
Really, this is the only interesting point of disagreement here. It's
easy for _me_ to make it compatible. It's hard for readers of the
assembly descriptor documentation to digest and understand yet another
option that tweaks yet another m
> On Jul 14, 2015, at 11:59 AM, Benson Margulies wrote:
>
> On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl wrote:
>> Ultimately your call. If users can upgrade and existing configuration will
>> work there’s no issue. If it breaks the user simply upgrading for something
>> you need need for
> I considered, even, sending email proposing to remove the
> long-deprecated goals from this plugin.
Not a Maven committer, but I'm with Benson on this one. If there is an
opportunity to clean it up, please do it. When I upgrade POMs to new
major versions I'd expect them to fail if I keep using s
On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl wrote:
> Ultimately your call. If users can upgrade and existing configuration will
> work there’s no issue. If it breaks the user simply upgrading for something
> you need need for expediency not so much. If it’s the first case there’s no
> issue
Ultimately your call. If users can upgrade and existing configuration will work
there’s no issue. If it breaks the user simply upgrading for something you need
need for expediency not so much. If it’s the first case there’s no issue, if
it’s the second then I would take the 15 minutes to make it
Jason, I don't think that this constitutes a punch in the face of
anyone for any purpose.
Did you actually read the JIRA? I've removed a file exclusion from
file sets. So, if someone was depending on the undocumented fact that
the assembly plugin would refuse to copy a file named (e.g.)
lexicon.fi
This is why I keep stuff that I want to move on a self-interested/aggressive
path not at Apache. What’s here needs to consider the best interest of all
users.
If you’re basically going to make the next version incompatible for anyone who
upgrades because you need something I don’t think that’s
27 matches
Mail list logo