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" <khmarba...@gmx.de
<mailto:khmarba...@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 <c...@schulte.it
<mailto:c...@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-unsubscr...@maven.apache.org
<mailto:users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
<mailto:users-h...@maven.apache.org>
Thanks,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
