You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Oliver B. Fischer" <o....@swe-blog.net> on 2016/07/02 10:36:01 UTC
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
My suggestions is based on the view of a Maven user who would like to do
it's daily job ;-)
In our team we have > 20 Maven projects and as a Maven 'User' you need
the chance to fix such issues before the break your build. Everyone
would blame Maven for this. We should have the chance to fix these
problems before they become serious.
WDYT?
Oliver
Am 20.06.16 um 23:23 schrieb Christian Schulte:
> Am 06/20/16 um 22:00 schrieb Oliver B. Fischer:
>> Yes, I think this would be very helpfull. Otherwise I see a lot of
>> people complaining about Maven and that is not able to do its work.
> Such warning messages could only be issued by Aether. That cannot be
> done in 3.4. We already reverted the things in question in 3.4 so that
> the issues you are running into no longer exist in 3.4 although it's
> really the other way around. There are issues in the project you could
> not notice because Maven makes those issues appear as correct behaviour.
> They will pop up again in a later Maven version. Maybe 3.5. No one knows
> right now. I ran a build of your project and just saw it will start
> throwing ClassNotFound related exceptions/compilation issues. Not having
> looked into any details. What is written here
> <http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html>
> is what Maven is aiming to adhere to. If we find a bug which makes it
> behave differently, we need to fix that on our side. The sooner the
> better so that people get a chance to notice as early as possible.
> That's what has happened. Current 3.4.0-SNAPSHOT should again support
> your project the way it did before. Does not solve the issues at hand.
> You can always download a recent Maven SNAPSHOT from
> <https://builds.apache.org/view/All/job/maven-3.3-release-status-build/>. It
> would help a lot if people would be using such a SNAPSHOT more
> frequently so that we can sort out things more efficiently. Also helps
> to find out what to focus in the release notes.
>
>
> Regards,
--
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/06/16 um 15:08 schrieb Jason van Zyl:
> Feature toggles, as the practice has been for many years, has the user being conscious of what they are doing. The feature may prove to be a problem and you specifically dont want to expose it to the whole user population. I honestly find your attitude extremely disconcerting. What you think is right, or how you think something should work is fine but shoving things in as you have, affecting core behavior and just expecting users to make any of the adjustments necessary is not very wise. Please take a step back and think about what youre doing.
>
> A conscious change to a POM by a user or a command line switch for a possible feature/fix in 4.x while the user can run 3.x is a great way to figure out whether said feature/fix is viable or not.
>
> No, someone new to Maven downloading 3.x should not get every new feature or behaviorally changing bug fix. Its clear youve not had to support any large population of users. You just cant do that. You change one thing you think is more correct and 500 people spend a few hours wondering why a build is broken. No one is going to read release notes, most are not on the mailing list. Youll just hose them, and an attitude of they were just doing things wrong really isnt acceptable.
>
I already reverted the things in question more than two weeks ago.
That's the result of the preliminary snapshot testing. Nothing wrong
with that. We are asking users to test the snapshot for exactly that
reason. We are now just talking about how to deliver bugfixes to the
users. I am fine with disabling things in 3.4 and making them default in
4.0. What is not to question is that we need to deliver them. I maybe
will just add a note to
<http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html>
where Maven is not behaving the way a reader would expect it. The issues
we are talking about have been reported by users in JIRA. It's not my
personal feature list I would like to implement or anything like that.
It happens one of those issues has been reported by me years ago. There
are others I just fixed when going through JIRA.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Jason van Zyl <ja...@takari.io>.
Feature toggles, as the practice has been for many years, has the user being conscious of what they are doing. The feature may prove to be a problem and you specifically don’t want to expose it to the whole user population. I honestly find your attitude extremely disconcerting. What you think is right, or how you think something should work is fine but shoving things in as you have, affecting core behavior and just expecting users to make any of the adjustments necessary is not very wise. Please take a step back and think about what you’re doing.
A conscious change to a POM by a user or a command line switch for a possible feature/fix in 4.x while the user can run 3.x is a great way to figure out whether said feature/fix is viable or not.
No, someone new to Maven downloading 3.x should not get every new feature or behaviorally changing bug fix. It’s clear you’ve not had to support any large population of users. You just can’t do that. You change one thing you think is more “correct” and 500 people spend a few hours wondering why a build is broken. No one is going to read release notes, most are not on the mailing list. You’ll just hose them, and an attitude of “they were just doing things wrong” really isn’t acceptable.
> On Jul 2, 2016, at 7:31 PM, Christian Schulte <cs...@schulte.it> wrote:
>
> Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
>> Hi,
>>
>> On 7/2/16 2:06 PM, Jason van Zyl wrote:
>> ....
>>> So we need to figure out a way to deliver the new behavior while
>> preserving
>>> the old for a time being. Maybe a branch,
>>
>>
>>> but I think the best way to do it is to have both behaviors exist in the
>>> same codebase and turn on what we considered corrected behavior
>>> with feature toggles.
>
> Someone who never has used Maven before and who downloads the current
> release should just use the 'mvn' command and get the behaviour with all
> "features" activated and should not have to care about any "feature". If
> I upgrade to a recent Maven version I am doing that to get the latest
> "features". That's like upgrading from OS 3.1 to OS 10 and having to
> check 10000 checkboxes in the installer to activate all "features"
> introduced after OS 3.1. If not activating any feature the OS 10
> installer installs OS 3.1. Come one.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Mark Derricutt <ma...@talios.com>.
On 3 Jul 2016, at 9:40, Karl Heinz Marbaise wrote:
> I'm note sure if IDE is handling .mvn/maven.config correct?
Not sure about .mvn/maven.config - but I know IntelliJ sure doesn't seem to use ./mvn/extensions.xml - the MavenServer they run is a single process for the lifetime of the IDE/project and doesn't seem to trigger ( at least, session level extensions ) each time to run things. Plugins with <extensions>true</extensions> seem to run tho.
--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Mark,
POM activation can't be used cause many features/toggles we are talking
about here needed to be activated before a pom has been read at all and
furthermore starting with Maven 3.3.1 you could use .mvn/maven.config[1]
to handle such things.
I'm note sure if IDE is handling .mvn/maven.config correct?
On build servers you will hopefully test first an activation of a
feature and later you will get that into your default configuration
which is hopefully not manually maintained (I hope using something like
Job DSL or jenkins file of Jenkins for example or similar things on
other build servers)...
And furthermore manually enabling them is exactly what we wish here, so
this can only happen by intention of the particular user and not by
accident...because those features should only selected by intention...
[1]: http://maven.apache.org/docs/3.3.1/release-notes.html
Kind regards
Karl Heinz
On 7/2/16 11:28 PM, Mark Derricutt wrote:
> The features look nice, the only thing I don't really like is (maybe
> mistaken) it's command line only? Which would mean you have to manual
> enable it every where, ides, build servers, unless you can enable them
> with some form of in-pom declaration?
>
> From the hip, on Android...
>
> On 3/07/2016 09:19, "Karl Heinz Marbaise" <khmarbaise@gmx.de
> <ma...@gmx.de>> wrote:
>
> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> ....
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist
> in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
> > Users can opt in early if they want to see the potential benefit
> > but it won\u2019t affect users adversely or unintentionally.
> >Eventually over time the new behavior becomes the default and the
> old behavior
> > can be toggled for the stragglers.
>
> I have implemented as an example feature toggles as module via
> MNG-6056[1] (on a branch) which makes all this possible.
>
> So you can use things like:
>
> --activate-features MNG9991,MNG9992
>
> which can easily questioned in the code (already an example in the
> branch):
>
> @Requirement
> private SelectedFeatures featureToggle;
> ...
> if (featureToggle.isFeatureActive(Feature.MNG10000)) {
> // The feature is implemented here or a different selection is done.
> }}
>
>
> If we sometime in the future decied to make the feature MNG10000 the
> default behaviour we can simply remove the if (...) in code and the
> enumeration entry...and it is default behaviour..those who give the
> activation via command line will only get a WARNING on a missing
> feature toggle which gives a hint to remove that from command
> line...like this:
>
> [WARNING] The requested feature 'MNG10001' Does not exist.
>
>
> Also you can request information like this (plus description):
>
> ~/ws-git/javaee (mvn321)$
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean
> --list-features
>
> Currently existing feature toggles which you can enable:
>
> Issue Option Description
> --------- -------- ----------------------------------------------------
> MNG-9991 MNG9991 First Feature to be toggable via command line
> option. First
> Feature to be toggable via command line option.
> MNG-9992 MNG9992 First Feature to be toggable via command line
> option. First
> Feature to be toggable via command line option.
> XX asdfa.
> asdf dsf.
> MNG-9993 MNG9993 First Feature to be toggable via command line
> option. More
> text than you think.
> MNG-10000 MNG10000 First Feature to be toggable via command line
> option. Here
> much more than you thing.
>
> If you like to know more about a particular issue please visit:
> issues.apache.org/jira/browse/[ISSUE]
> <http://issues.apache.org/jira/browse/%5BISSUE%5D>
>
> so this implemented only two new command line options:
>
> --activate-features ARGS
> --list-features
>
> ...
>
> Furthermore if we identify wrong configurations etc. (not so easy or
> may be impossible) we can give a hint on the feature toggle to let
> the user make the decision if he want to have a different (correct)
> solution or an improved solution....or whatever...
>
>
> Kind regards
> Karl Heinz
>
>
> [1]: https://issues.apache.org/jira/browse/MNG-6056
>
>
> Sure we can just throw away the old behavior but I honest think the
> downstream impact will be enormous, and in a negative way.
>
>
> On Jul 2, 2016, at 7:07 AM, Christian Schulte <cs@schulte.it
> <ma...@schulte.it>> wrote:
>
> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>
> My suggestions is based on the view of a Maven user who
> would like to do
> it's daily job ;-)
>
> In our team we have > 20 Maven projects and as a Maven
> 'User' you need
> the chance to fix such issues before the break your
> build. Everyone
> would blame Maven for this. We should have the chance to
> fix these
> problems before they become serious.
>
> WDYT?
>
>
> It's a matter of how you plan Maven upgrades. I understand
> you just want
> to download a newer Maven version without having to do
> anything else. As
> already said, the commits in question have been reverted for
> 3.4. Think
> about upgrading Maven is like upgrading your operating
> system. You are a
> developer yourself. How do you fix bugs without fixing them?
>
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
> Thanks,
>
> Jason
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Mark Derricutt <ma...@talios.com>.
The features look nice, the only thing I don't really like is (maybe
mistaken) it's command line only? Which would mean you have to manual
enable it every where, ides, build servers, unless you can enable them
with some form of in-pom declaration?
From the hip, on Android...
On 3/07/2016 09:19, "Karl Heinz Marbaise" <kh...@gmx.de> wrote:
> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> ....
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
> > Users can opt in early if they want to see the potential benefit
> > but it won’t affect users adversely or unintentionally.
> >Eventually over time the new behavior becomes the default and the old
> behavior
> > can be toggled for the stragglers.
>
> I have implemented as an example feature toggles as module via MNG-6056[1]
> (on a branch) which makes all this possible.
>
> So you can use things like:
>
> --activate-features MNG9991,MNG9992
>
> which can easily questioned in the code (already an example in the branch):
>
> @Requirement
> private SelectedFeatures featureToggle;
> ...
> if (featureToggle.isFeatureActive(Feature.MNG10000)) {
> // The feature is implemented here or a different selection is done.
> }}
>
>
> If we sometime in the future decied to make the feature MNG10000 the
> default behaviour we can simply remove the if (...) in code and the
> enumeration entry...and it is default behaviour..those who give the
> activation via command line will only get a WARNING on a missing feature
> toggle which gives a hint to remove that from command line...like this:
>
> [WARNING] The requested feature 'MNG10001' Does not exist.
>
>
> Also you can request information like this (plus description):
>
> ~/ws-git/javaee (mvn321)$
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean --list-features
>
> Currently existing feature toggles which you can enable:
>
> Issue Option Description
> --------- -------- ----------------------------------------------------
> MNG-9991 MNG9991 First Feature to be toggable via command line option.
> First
> Feature to be toggable via command line option.
> MNG-9992 MNG9992 First Feature to be toggable via command line option.
> First
> Feature to be toggable via command line option. XX
> asdfa.
> asdf dsf.
> MNG-9993 MNG9993 First Feature to be toggable via command line option.
> More
> text than you think.
> MNG-10000 MNG10000 First Feature to be toggable via command line option.
> Here
> much more than you thing.
>
> If you like to know more about a particular issue please visit:
> issues.apache.org/jira/browse/[ISSUE]
> <http://issues.apache.org/jira/browse/%5BISSUE%5D>
>
> so this implemented only two new command line options:
>
> --activate-features ARGS
> --list-features
>
> ...
>
> Furthermore if we identify wrong configurations etc. (not so easy or may
> be impossible) we can give a hint on the feature toggle to let the user
> make the decision if he want to have a different (correct) solution or an
> improved solution....or whatever...
>
>
> Kind regards
> Karl Heinz
>
>
> [1]: https://issues.apache.org/jira/browse/MNG-6056
>
>
> Sure we can just throw away the old behavior but I honest think the
> downstream impact will be enormous, and in a negative way.
>
>>
>> On Jul 2, 2016, at 7:07 AM, Christian Schulte <cs...@schulte.it> wrote:
>>>
>>> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>>>
>>>> My suggestions is based on the view of a Maven user who would like to do
>>>> it's daily job ;-)
>>>>
>>>> In our team we have > 20 Maven projects and as a Maven 'User' you need
>>>> the chance to fix such issues before the break your build. Everyone
>>>> would blame Maven for this. We should have the chance to fix these
>>>> problems before they become serious.
>>>>
>>>> WDYT?
>>>>
>>>
>>> It's a matter of how you plan Maven upgrades. I understand you just want
>>> to download a newer Maven version without having to do anything else. As
>>> already said, the commits in question have been reverted for 3.4. Think
>>> about upgrading Maven is like upgrading your operating system. You are a
>>> developer yourself. How do you fix bugs without fixing them?
>>>
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/03/16 um 01:49 schrieb Christian Schulte:
> Am 07/03/16 um 01:39 schrieb Karl Heinz Marbaise:
>> Hi,
>>
>> On 7/3/16 1:31 AM, Christian Schulte wrote:
>>> Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
>>>> Hi,
>>>>
>>>> On 7/2/16 2:06 PM, Jason van Zyl wrote:
>>>> ....
>>>> >So we need to figure out a way to deliver the new behavior while
>>>> preserving
>>>> >the old for a time being. Maybe a branch,
>>>>
>>>>
>>>> > but I think the best way to do it is to have both behaviors exist in the
>>>> > same codebase and turn on what we considered corrected behavior
>>>> > with feature toggles.
>>>
>>> Someone who never has used Maven before and who downloads the current
>>> release should just use the 'mvn' command and get the behaviour with all
>>> "features" activated and should not have to care about any "feature". If
>>> I upgrade to a recent Maven version I am doing that to get the latest
>>> "features". That's like upgrading from OS 3.1 to OS 10 and having to
>>> check 10000 checkboxes in the installer to activate all "features"
>>> introduced after OS 3.1. If not activating any feature the OS 10
>>> installer installs OS 3.1. Come one.
>>
>> This guy should use the same Maven as anyone else around the world which
>> means all breaking features should be disabled by default (see my
>> previous email)..
>
> And how will this stop this guy from making the same mistakes others
> have done before?
>
By this I mean: 99.9% if not 100% of all POMs have been authored based
on a trial and error basis. Then a more recent Maven version starts to
fail and that means trial and error should be repeated with that new
version but we "downgrade" Maven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/03/16 um 01:39 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 7/3/16 1:31 AM, Christian Schulte wrote:
>> Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
>>> Hi,
>>>
>>> On 7/2/16 2:06 PM, Jason van Zyl wrote:
>>> ....
>>> >So we need to figure out a way to deliver the new behavior while
>>> preserving
>>> >the old for a time being. Maybe a branch,
>>>
>>>
>>> > but I think the best way to do it is to have both behaviors exist in the
>>> > same codebase and turn on what we considered corrected behavior
>>> > with feature toggles.
>>
>> Someone who never has used Maven before and who downloads the current
>> release should just use the 'mvn' command and get the behaviour with all
>> "features" activated and should not have to care about any "feature". If
>> I upgrade to a recent Maven version I am doing that to get the latest
>> "features". That's like upgrading from OS 3.1 to OS 10 and having to
>> check 10000 checkboxes in the installer to activate all "features"
>> introduced after OS 3.1. If not activating any feature the OS 10
>> installer installs OS 3.1. Come one.
>
> This guy should use the same Maven as anyone else around the world which
> means all breaking features should be disabled by default (see my
> previous email)..
And how will this stop this guy from making the same mistakes others
have done before?
> We are not an operation system nor a company like Apple who can force
> users to upgrade...
Nobody is forced to upgrade. It is really the other way around. They
upgrade and then start filing issues in JIRA asking us to fix
regressions which are no regressions. And we are stupid enough to do that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Mark Derricutt <ma...@talios.com>.
On 3 Jul 2016, at 11:39, Karl Heinz Marbaise wrote:
> If you started with Maven 2 and now you upgrade to Maven 3.3.9 you will get a large number of new features and different behaviour compared to Maven 2 etc...but there are some parts in Maven 3.X+ which are working wronge for a long time and which should keept the same ...to get reliable results (from the users perspective)..
It's a pity we've broken that already tho - esp. with dependency resolution. One of the main things we all use maven for, and is one thing that is constantly a mystical land of hope.
It would seem that maven these days when using "3.3.9" as a version, if someone else wants "3.3.0" then the later is whats used, it used to be the highest version requested was used - this changes at some point and leads to all manner of confusion.
However, remaining on topic - I'd say that for 3.x we'd leave these features off by default, but for 4.x we turn them on.
I for one can't wait til we fix all the problems with the "compile" scope - and I don't care if we cause a lot of grief for end users in the process.
--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 7/3/16 1:31 AM, Christian Schulte wrote:
> Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
>> Hi,
>>
>> On 7/2/16 2:06 PM, Jason van Zyl wrote:
>> ....
>> >So we need to figure out a way to deliver the new behavior while
>> preserving
>> >the old for a time being. Maybe a branch,
>>
>>
>> > but I think the best way to do it is to have both behaviors exist in the
>> > same codebase and turn on what we considered corrected behavior
>> > with feature toggles.
>
> Someone who never has used Maven before and who downloads the current
> release should just use the 'mvn' command and get the behaviour with all
> "features" activated and should not have to care about any "feature". If
> I upgrade to a recent Maven version I am doing that to get the latest
> "features". That's like upgrading from OS 3.1 to OS 10 and having to
> check 10000 checkboxes in the installer to activate all "features"
> introduced after OS 3.1. If not activating any feature the OS 10
> installer installs OS 3.1. Come one.
This guy should use the same Maven as anyone else around the world which
means all breaking features should be disabled by default (see my
previous email)..
We are not an operation system nor a company like Apple who can force
users to upgrade...
If you started with Maven 2 and now you upgrade to Maven 3.3.9 you will
get a large number of new features and different behaviour compared to
Maven 2 etc...but there are some parts in Maven 3.X+ which are working
wronge for a long time and which should keept the same ...to get
reliable results (from the users perspective)..
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/03/16 um 01:42 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 7/3/16 1:34 AM, Christian Schulte wrote:
>> Am 07/03/16 um 01:16 schrieb Karl Heinz Marbaise:
>>> If we make the decision to make a particular feature the default we can
>>> simple remove it from the feature toggle list...Or we can make to
>>> produce it warnings etc.
>>
>> And how is that different from just shipping that feature active by
>> default right from the start? The same will happen. Nobody will have
>> ever activated the feature before and then the build breaks as well when
>> that feature becomes the default.
>
> You seemed to ignore the context of the previous sentence ....
No.
> After a time users have tested it we can make it default in other words...
I repeat: Nobody will test those new features if activating them means
having to maintain the POMs.
> And shipping it active by default would mean
to make users aware of POM issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 7/3/16 1:34 AM, Christian Schulte wrote:
> Am 07/03/16 um 01:16 schrieb Karl Heinz Marbaise:
>> If we make the decision to make a particular feature the default we can
>> simple remove it from the feature toggle list...Or we can make to
>> produce it warnings etc.
>
> And how is that different from just shipping that feature active by
> default right from the start? The same will happen. Nobody will have
> ever activated the feature before and then the build breaks as well when
> that feature becomes the default.
You seemed to ignore the context of the previous sentence ....
After a time users have tested it we can make it default in other words...
And shipping it active by default would mean to break builds by default....
Kind regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/03/16 um 01:16 schrieb Karl Heinz Marbaise:
> If we make the decision to make a particular feature the default we can
> simple remove it from the feature toggle list...Or we can make to
> produce it warnings etc.
And how is that different from just shipping that feature active by
default right from the start? The same will happen. Nobody will have
ever activated the feature before and then the build breaks as well when
that feature becomes the default.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 7/3/16 12:46 AM, Christian Schulte wrote:
> Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
>> Hi,
>>
>> On 7/2/16 2:06 PM, Jason van Zyl wrote:
>> ....
>> >So we need to figure out a way to deliver the new behavior while
>> preserving
>> >the old for a time being. Maybe a branch,
>>
>>
>> > but I think the best way to do it is to have both behaviors exist in the
>> > same codebase and turn on what we considered corrected behavior
>> > with feature toggles.
>> > Users can opt in early if they want to see the potential benefit
>> > but it won\u2019t affect users adversely or unintentionally.
>> >Eventually over time the new behavior becomes the default and the old
>> behavior
>> > can be toggled for the stragglers.
>>
>> I have implemented as an example feature toggles as module via
>> MNG-6056[1] (on a branch) which makes all this possible.
>>
>> So you can use things like:
>>
>> --activate-features MNG9991,MNG9992
>>
>
> I am all for active by default and giving a chance to disable things if
> needed. We do want the "features" to be active and we do want users to
> notice there is an issue they need to fix.
It is true that WE (maven devs) want the features to be active but the
users are the leaders (the community) which means we should not break by
default builds...(it does not really matter if the users needed to fix
their builds/pom's etc. cause they are using a feature wrong or relying
on a behaviour which is wrong etc.)..
Only if a users decides to acitvate a feature toggle he decided to
check/test that feature...by intention...
Apart from that already explained in detail by Jason...
> They can disable things if
> needed then but it's them who need to handle that and who need to know
> why they need to disable a feature and what to do about it.
> Not
> activating things by default makes no sense in my opinion.
It makes completely sense, cause it keeps compatibility over the minor
releases which gives us the chance to do changes without breaking a
large number of builds (maybe millions of builds)...by default...
> --activate-features list,of,twenty,issues after a few releases. Nobody
> wants that. We want --deactivate-features list,
> of,only,the,issues,users,have,to,fix,themselves,we,do,not,care,about,when,and,how,they,will,do,if,they,ever,will,do,anything,at,all
If we make the decision to make a particular feature the default we can
simple remove it from the feature toggle list...Or we can make to
produce it warnings etc.
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> ....
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
> > Users can opt in early if they want to see the potential benefit
> > but it won\u2019t affect users adversely or unintentionally.
> >Eventually over time the new behavior becomes the default and the old
> behavior
> > can be toggled for the stragglers.
>
> I have implemented as an example feature toggles as module via
> MNG-6056[1] (on a branch) which makes all this possible.
>
> So you can use things like:
>
> --activate-features MNG9991,MNG9992
>
I am all for active by default and giving a chance to disable things if
needed. We do want the "features" to be active and we do want users to
notice there is an issue they need to fix. They can disable things if
needed then but it's them who need to handle that and who need to know
why they need to disable a feature and what to do about it. Not
activating things by default makes no sense in my opinion.
--activate-features list,of,twenty,issues after a few releases. Nobody
wants that. We want --deactivate-features list,
of,only,the,issues,users,have,to,fix,themselves,we,do,not,care,about,when,and,how,they,will,do,if,they,ever,will,do,anything,at,all
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> ....
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
Someone who never has used Maven before and who downloads the current
release should just use the 'mvn' command and get the behaviour with all
"features" activated and should not have to care about any "feature". If
I upgrade to a recent Maven version I am doing that to get the latest
"features". That's like upgrading from OS 3.1 to OS 10 and having to
check 10000 checkboxes in the installer to activate all "features"
introduced after OS 3.1. If not activating any feature the OS 10
installer installs OS 3.1. Come one.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/02/16 um 23:18 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 7/2/16 2:06 PM, Jason van Zyl wrote:
> ....
> >So we need to figure out a way to deliver the new behavior while
> preserving
> >the old for a time being. Maybe a branch,
>
>
> > but I think the best way to do it is to have both behaviors exist in the
> > same codebase and turn on what we considered corrected behavior
> > with feature toggles.
> > Users can opt in early if they want to see the potential benefit
> > but it won\u2019t affect users adversely or unintentionally.
> >Eventually over time the new behavior becomes the default and the old
> behavior
> > can be toggled for the stragglers.
>
> I have implemented as an example feature toggles as module via
> MNG-6056[1] (on a branch) which makes all this possible.
>
That would be needed at least in Aether as well. Maybe everywhere. Maybe
plugins also. So 'maven-shared-utils' is a better place for this?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 7/2/16 2:06 PM, Jason van Zyl wrote:
....
>So we need to figure out a way to deliver the new behavior while
preserving
>the old for a time being. Maybe a branch,
> but I think the best way to do it is to have both behaviors exist in the
> same codebase and turn on what we considered corrected behavior
> with feature toggles.
> Users can opt in early if they want to see the potential benefit
> but it won\u2019t affect users adversely or unintentionally.
>Eventually over time the new behavior becomes the default and the old
behavior
> can be toggled for the stragglers.
I have implemented as an example feature toggles as module via
MNG-6056[1] (on a branch) which makes all this possible.
So you can use things like:
--activate-features MNG9991,MNG9992
which can easily questioned in the code (already an example in the branch):
@Requirement
private SelectedFeatures featureToggle;
...
if (featureToggle.isFeatureActive(Feature.MNG10000)) {
// The feature is implemented here or a different selection is done.
}}
If we sometime in the future decied to make the feature MNG10000 the
default behaviour we can simply remove the if (...) in code and the
enumeration entry...and it is default behaviour..those who give the
activation via command line will only get a WARNING on a missing feature
toggle which gives a hint to remove that from command line...like this:
[WARNING] The requested feature 'MNG10001' Does not exist.
Also you can request information like this (plus description):
~/ws-git/javaee (mvn321)$
~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean --list-features
Currently existing feature toggles which you can enable:
Issue Option Description
--------- -------- ----------------------------------------------------
MNG-9991 MNG9991 First Feature to be toggable via command line option.
First
Feature to be toggable via command line option.
MNG-9992 MNG9992 First Feature to be toggable via command line option.
First
Feature to be toggable via command line option. XX
asdfa.
asdf dsf.
MNG-9993 MNG9993 First Feature to be toggable via command line option.
More
text than you think.
MNG-10000 MNG10000 First Feature to be toggable via command line option.
Here
much more than you thing.
If you like to know more about a particular issue please visit:
issues.apache.org/jira/browse/[ISSUE]
so this implemented only two new command line options:
--activate-features ARGS
--list-features
...
Furthermore if we identify wrong configurations etc. (not so easy or may
be impossible) we can give a hint on the feature toggle to let the user
make the decision if he want to have a different (correct) solution or
an improved solution....or whatever...
Kind regards
Karl Heinz
[1]: https://issues.apache.org/jira/browse/MNG-6056
Sure we can just throw away the old behavior but I honest think the
downstream impact will be enormous, and in a negative way.
>
>> On Jul 2, 2016, at 7:07 AM, Christian Schulte <cs...@schulte.it> wrote:
>>
>> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>>> My suggestions is based on the view of a Maven user who would like to do
>>> it's daily job ;-)
>>>
>>> In our team we have > 20 Maven projects and as a Maven 'User' you need
>>> the chance to fix such issues before the break your build. Everyone
>>> would blame Maven for this. We should have the chance to fix these
>>> problems before they become serious.
>>>
>>> WDYT?
>>
>> It's a matter of how you plan Maven upgrades. I understand you just want
>> to download a newer Maven version without having to do anything else. As
>> already said, the commits in question have been reverted for 3.4. Think
>> about upgrading Maven is like upgrading your operating system. You are a
>> developer yourself. How do you fix bugs without fixing them?
>>
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/02/16 um 15:53 schrieb Jeff Jensen:
> Feature toggles +1 FTW
>
> Agreed, switching the default behavior over time is a good path of change.
> Perhaps helping with the awareness of the feature, when the feature is off,
> display an info message stating this feature exists and suggest enabling it
> with the toggle, possibly noting future plans of it becoming the default
> behavior.
Not talking about features here. That would be easy. Take a look at this
commit, for example.
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e>
You really want a command line option like:
--without-mng-5935-bugfix
? This will get out of hand in just a few releases.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Jeff Jensen <je...@upstairstechnology.com>.
Feature toggles +1 FTW
Agreed, switching the default behavior over time is a good path of change.
Perhaps helping with the awareness of the feature, when the feature is off,
display an info message stating this feature exists and suggest enabling it
with the toggle, possibly noting future plans of it becoming the default
behavior.
On Sat, Jul 2, 2016 at 7:06 AM, Jason van Zyl <ja...@takari.io> wrote:
> The question is not whether to fix them, but how they are fixed in the
> context of the people using the software.
>
> I think you strive for the pure, elegant and correct way of how you think
> something should work. In most cases I’ve seen your reasoning is sound and
> in most cases is what should be done but how those corrections are
> delivered is as important as the fix itself. For whatever mistakes we have
> made we have hundreds of thousands, if not millions, of users who still
> need to do their daily work. Yes, they come to expect Maven to work as if
> it was a product they purchased and while that may seem unreasonable that
> is the situation we are in.
>
> I think for all the corrections you are making, it’s fine if they land in
> 4.0 where it’s documented that for a given correction where their POM looks
> like X it must look like Y to be correct. It’s a conscious choice on the
> part of the user to get the benefits of newer versions and to receive these
> benefits there are some behavioral changes that accompany those benefits.
> Maybe we can write something that looks for these patterns and helps users
> correct the errors. But this really can’t happen across a minor version as
> it’s just not expected. For one change we make where we don’t make this
> clear we potentially accrue thousands of man hours of pain from users and
> to me the math is clear this is not a good option. We have lots of baggage
> but we have to live with it and I believe we have to live with it because
> that’s what makes it work for all our users.
>
> We have historically gone to great lengths with the ITs to ensure behavior
> has remained stable so that for the vast majority of our users things don’t
> break. Maybe that has kept us from fixing some fundamentally incorrect
> behavior but it has preserved the utility delivered to our users. So we
> need to figure out a way to deliver the new behavior while preserving the
> old for a time being. Maybe a branch, but I think the best way to do it is
> to have both behaviors exist in the same codebase and turn on what we
> considered corrected behavior with feature toggles. Users can opt in early
> if they want to see the potential benefit but it won’t affect users
> adversely or unintentionally. Eventually over time the new behavior becomes
> the default and the old behavior can be toggled for the stragglers. Sure we
> can just throw away the old behavior but I honest think the downstream
> impact will be enormous, and in a negative way.
>
> > On Jul 2, 2016, at 7:07 AM, Christian Schulte <cs...@schulte.it> wrote:
> >
> > Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
> >> My suggestions is based on the view of a Maven user who would like to do
> >> it's daily job ;-)
> >>
> >> In our team we have > 20 Maven projects and as a Maven 'User' you need
> >> the chance to fix such issues before the break your build. Everyone
> >> would blame Maven for this. We should have the chance to fix these
> >> problems before they become serious.
> >>
> >> WDYT?
> >
> > It's a matter of how you plan Maven upgrades. I understand you just want
> > to download a newer Maven version without having to do anything else. As
> > already said, the commits in question have been reverted for 3.4. Think
> > about upgrading Maven is like upgrading your operating system. You are a
> > developer yourself. How do you fix bugs without fixing them?
> >
> >
> > Regards,
> > --
> > Christian
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Jason van Zyl <ja...@takari.io>.
The question is not whether to fix them, but how they are fixed in the context of the people using the software.
I think you strive for the pure, elegant and correct way of how you think something should work. In most cases I’ve seen your reasoning is sound and in most cases is what should be done but how those corrections are delivered is as important as the fix itself. For whatever mistakes we have made we have hundreds of thousands, if not millions, of users who still need to do their daily work. Yes, they come to expect Maven to work as if it was a product they purchased and while that may seem unreasonable that is the situation we are in.
I think for all the corrections you are making, it’s fine if they land in 4.0 where it’s documented that for a given correction where their POM looks like X it must look like Y to be correct. It’s a conscious choice on the part of the user to get the benefits of newer versions and to receive these benefits there are some behavioral changes that accompany those benefits. Maybe we can write something that looks for these patterns and helps users correct the errors. But this really can’t happen across a minor version as it’s just not expected. For one change we make where we don’t make this clear we potentially accrue thousands of man hours of pain from users and to me the math is clear this is not a good option. We have lots of baggage but we have to live with it and I believe we have to live with it because that’s what makes it work for all our users.
We have historically gone to great lengths with the ITs to ensure behavior has remained stable so that for the vast majority of our users things don’t break. Maybe that has kept us from fixing some fundamentally incorrect behavior but it has preserved the utility delivered to our users. So we need to figure out a way to deliver the new behavior while preserving the old for a time being. Maybe a branch, but I think the best way to do it is to have both behaviors exist in the same codebase and turn on what we considered corrected behavior with feature toggles. Users can opt in early if they want to see the potential benefit but it won’t affect users adversely or unintentionally. Eventually over time the new behavior becomes the default and the old behavior can be toggled for the stragglers. Sure we can just throw away the old behavior but I honest think the downstream impact will be enormous, and in a negative way.
> On Jul 2, 2016, at 7:07 AM, Christian Schulte <cs...@schulte.it> wrote:
>
> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>> My suggestions is based on the view of a Maven user who would like to do
>> it's daily job ;-)
>>
>> In our team we have > 20 Maven projects and as a Maven 'User' you need
>> the chance to fix such issues before the break your build. Everyone
>> would blame Maven for this. We should have the chance to fix these
>> problems before they become serious.
>>
>> WDYT?
>
> It's a matter of how you plan Maven upgrades. I understand you just want
> to download a newer Maven version without having to do anything else. As
> already said, the commits in question have been reverted for 3.4. Think
> about upgrading Maven is like upgrading your operating system. You are a
> developer yourself. How do you fix bugs without fixing them?
>
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
> My suggestions is based on the view of a Maven user who would like to do
> it's daily job ;-)
>
> In our team we have > 20 Maven projects and as a Maven 'User' you need
> the chance to fix such issues before the break your build. Everyone
> would blame Maven for this. We should have the chance to fix these
> problems before they become serious.
>
> WDYT?
It's a matter of how you plan Maven upgrades. I understand you just want
to download a newer Maven version without having to do anything else. As
already said, the commits in question have been reverted for 3.4. Think
about upgrading Maven is like upgrading your operating system. You are a
developer yourself. How do you fix bugs without fixing them?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org