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 :)
Le mardi 14 juillet 2015 15:39:16 Benson Margulies a écrit :
> On Tue, Jul 14, 2015 at 3:10 PM, Hervé BOUTEMY
wrote:
> > thank you
> >
> > Le mardi 14 juillet 2015 15:06:57 Benson Margulies a écrit :
> >> Reverted.
>
> De rien, and all that, but I want to emphasize that this is just how
> CTR w
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
On Tue, Jul 14, 2015 at 3:10 PM, Hervé BOUTEMY wrote:
> thank you
>
> Le mardi 14 juillet 2015 15:06:57 Benson Margulies a écrit :
>> Reverted.
De rien, and all that, but I want to emphasize that this is just how
CTR works. I committed based on my itch. You saw a problem. I
reverted. No fuss, no
thank you
Le mardi 14 juillet 2015 15:06:57 Benson Margulies a écrit :
> Reverted.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
--
Reverted.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
Interesting, the commit for "**/*.filtered" says: "Based on patch provided...".
But the patch does NOT exclude the .filtered, while the commit does. That makes
it a very unclear whether the .filtered was actually so much related to
MASSEMBLY-154. The unit test (change) does also not address this
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.
blame done and found the inital commit for the 2 excludes:
see https://issues.apache.org/jira/browse/MASSEMBLY-777
Regards,
Hervé
Le mardi 14 juillet 2015 17:19:30 Sander Verhagen a écrit :
> I'm not much of a stakeholder in this but after following the discussion I'm
> getting curious if there'
using svn blame, I started to try to figure out why these strange things are
here.
the *.formatted was easy to find:
http://svn.apache.org/r960848
corresponding to
https://issues.apache.org/jira/browse/MASSEMBLY-462
I read quickly this Jira issue, I didn't really catch what created the
.formatte
Hi,
The vote has passed with the following result:
+1 (binding): Jason van Zyl, Hervé Boutemy, Karl Heinz Marbaise
+1 (non binding): Mirko Firedenhagen
I will promote the artifacts to the central repo.
Kind regards
Karl Heinz Marbaise
-
I'm not much of a stakeholder in this but after following the discussion I'm
getting curious if there's any hints to why this was introduced? Is there a VCS
"blame" to do that links to a JIRA issue of some kind? This could uncover at
least a few (reasonable or not) use cases for this (admitted,
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
I have selfish/professional reasons to desire a release with a fix to
MASSEMBLY-777, and the fix, involving an intentional incompatibility,
needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be
next. So I plan to start the process tomorrow morning EDT unless
someone objects.
--
This code lives in AddFileSetsTask.java. There are no comments. Can
anyone explain it? Can I simply delete it via MASSEMBLY-777?
final List excludes = fileSet.getExcludes();
excludes.add( "**/*.filtered" );
excludes.add( "**/*.formatted" );
task.setExcludes( exc
Hi,
I am new to this community and want to contribute in it to the best I can.
Name - Onkar Nagnath Kamatkar
Project - Apache Maven
Mentor Name - Joachim Van der Auwera
Issue Link - https://issues.apache.org/jira/browse/MNG-5659
This is what I found to be my first issue in the community. I want
31 matches
Mail list logo
