You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Karl Heinz Marbaise <kh...@gmx.de> on 2016/06/11 20:21:08 UTC
Preleminary Maven 3.4.0-SNAPSHOT Testing
Hi to all Maven users,
is someone of you willing to do some testing on the current state of
development for the upcoming Maven 3.4.0 release?
Please be aware of this *** This is not an official release ***
I have created downloadable packages which are available from here:
Windows: https://s.apache.org/fawM,
Linux: https://s.apache.org/RQ3C
Every kind of feedback is helpful.
This is only a current state of development (Git hash:
644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
community...
The current list of changes can be seen in the issue tracker:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
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 Torsten Stolpmann <st...@verit.de>.
Hi Karl-Heinz,
upgrading from maven 3.3.9 I ran our product build using this snapshot
without any visible regressions.
Hope this helps,
Torsten
On 11.06.2016 22:21, Karl Heinz Marbaise wrote:
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
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 Paul Benedict <pb...@apache.org>.
That is an interesting idea so no one gets blindsided by an important new
feature. Baby steps, right?
I recommend that you opine in the ticket:
https://issues.apache.org/jira/browse/MNG-5935
...and also write dev@ to pass on your idea. I think your idea has merit.
Cheers,
Paul
On Mon, Jun 20, 2016 at 3:00 PM, Oliver B. Fischer <o.b.fischer@swe-blog.net
> wrote:
> 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.
>
> The best solution IMHO would be to print out a warning with a detailed
> hint that no one could ignore.
>
> Am 20.06.16 um 21:56 schrieb Paul Benedict:
>
>> Do you mean make it a warning in 3.4 and fix behavior in 3.5?
>>
>> Cheers,
>> Paul
>>
>> On Mon, Jun 20, 2016 at 2:42 PM, Oliver B. Fischer <
>> o.b.fischer@swe-blog.net
>>
>>> wrote:
>>> Ok, I will fix it. But wouldn't it be an usefull option to print some
>>> warning about this problem before changing the current behaviour?
>>>
>>>
>>> WDYT?
>>>
>>>
>>> Am 12.06.16 um 23:08 schrieb Christian Schulte:
>>>
>>> --
>>> 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
>>>
>>>
>>>
> --
> 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
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
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 <sc...@apache.org>.
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,
--
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 "Oliver B. Fischer" <o....@swe-blog.net>.
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.
The best solution IMHO would be to print out a warning with a detailed
hint that no one could ignore.
Am 20.06.16 um 21:56 schrieb Paul Benedict:
> Do you mean make it a warning in 3.4 and fix behavior in 3.5?
>
> Cheers,
> Paul
>
> On Mon, Jun 20, 2016 at 2:42 PM, Oliver B. Fischer <o.b.fischer@swe-blog.net
>> wrote:
>> Ok, I will fix it. But wouldn't it be an usefull option to print some
>> warning about this problem before changing the current behaviour?
>>
>>
>> WDYT?
>>
>>
>> Am 12.06.16 um 23:08 schrieb Christian Schulte:
>>
>> --
>> 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
>>
>>
--
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 Paul Benedict <pb...@apache.org>.
Do you mean make it a warning in 3.4 and fix behavior in 3.5?
Cheers,
Paul
On Mon, Jun 20, 2016 at 2:42 PM, Oliver B. Fischer <o.b.fischer@swe-blog.net
> wrote:
> Ok, I will fix it. But wouldn't it be an usefull option to print some
> warning about this problem before changing the current behaviour?
>
>
> WDYT?
>
>
> Am 12.06.16 um 23:08 schrieb Christian Schulte:
>
>> Am 06/12/16 um 22:01 schrieb Oliver B. Fischer:
>>
>>> With this snapshot I am unable to build jQAssistant. You can fetch it
>>> from git@github.com:buschmais/jqassistant.git
>>>
>>> You need to fix the project. 3.4 adds support for managing the
>> 'optional' flag in dependency management and contains bugfixes to
>> resolution issues. Either you have used the 'optional' flag in
>> dependency management somewhere and have not noticed this is not
>> supported or you are managing some dependency to 'test' scope and Maven
>> correctly does no longer select such a dependency when transitive. All
>> of those bugfixes have already been reverted lately and the current
>> 3.4-SNAPSHOT now again behaves incorrectly without you noticing it.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> --
> 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 "Oliver B. Fischer" <o....@swe-blog.net>.
Ok, I will fix it. But wouldn't it be an usefull option to print some
warning about this problem before changing the current behaviour?
WDYT?
Am 12.06.16 um 23:08 schrieb Christian Schulte:
> Am 06/12/16 um 22:01 schrieb Oliver B. Fischer:
>> With this snapshot I am unable to build jQAssistant. You can fetch it
>> from git@github.com:buschmais/jqassistant.git
>>
> You need to fix the project. 3.4 adds support for managing the
> 'optional' flag in dependency management and contains bugfixes to
> resolution issues. Either you have used the 'optional' flag in
> dependency management somewhere and have not noticed this is not
> supported or you are managing some dependency to 'test' scope and Maven
> correctly does no longer select such a dependency when transitive. All
> of those bugfixes have already been reverted lately and the current
> 3.4-SNAPSHOT now again behaves incorrectly without you noticing it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
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 06/12/16 um 22:01 schrieb Oliver B. Fischer:
> With this snapshot I am unable to build jQAssistant. You can fetch it
> from git@github.com:buschmais/jqassistant.git
>
You need to fix the project. 3.4 adds support for managing the
'optional' flag in dependency management and contains bugfixes to
resolution issues. Either you have used the 'optional' flag in
dependency management somewhere and have not noticed this is not
supported or you are managing some dependency to 'test' scope and Maven
correctly does no longer select such a dependency when transitive. All
of those bugfixes have already been reverted lately and the current
3.4-SNAPSHOT now again behaves incorrectly without you noticing it.
---------------------------------------------------------------------
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 "Oliver B. Fischer" <o....@swe-blog.net>.
With this snapshot I am unable to build jQAssistant. You can fetch it
from git@github.com:buschmais/jqassistant.git
Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from
> the community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
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 Uwe Barthel <ba...@x-reizend.de>.
Hi Karl Heinz,
> Are you asking some PR in particular ?
https://issues.apache.org/jira/browse/MNG-3092 - https://github.com/apache/maven/pull/70
-- barthel
> On 12 Jun 2016, at 21:52, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi Uwe,
>
> On 6/12/16 9:40 PM, Uwe Barthel wrote:
>> Hi Karl Heinz,
>>
>> did you merge any of the open github.com PRs into it?
>
> I didn't but there have been PR's which have been merged...
>
> So please consult the issue tracker which shows which PR's have made it into...
>
> Are you asking some PR in particular ?
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>> -- barthel
>>
>>
>>> On 11 Jun 2016, at 22:21, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>>>
>>> Hi to all Maven users,
>>>
>>> is someone of you willing to do some testing on the current state of development for the upcoming Maven 3.4.0 release?
>>>
>>> Please be aware of this *** This is not an official release ***
>>>
>>> I have created downloadable packages which are available from here:
>>>
>>> Windows: https://s.apache.org/fawM,
>>> Linux: https://s.apache.org/RQ3C
>>>
>>>
>>> Every kind of feedback is helpful.
>>>
>>> This is only a current state of development (Git hash: 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the community...
>>>
>>> The current list of changes can be seen in the issue tracker:
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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 Uwe,
On 6/12/16 9:40 PM, Uwe Barthel wrote:
> Hi Karl Heinz,
>
> did you merge any of the open github.com PRs into it?
I didn't but there have been PR's which have been merged...
So please consult the issue tracker which shows which PR's have made it
into...
Are you asking some PR in particular ?
Kind regards
Karl Heinz Marbaise
>
> -- barthel
>
>
>> On 11 Jun 2016, at 22:21, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>>
>> Hi to all Maven users,
>>
>> is someone of you willing to do some testing on the current state of development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash: 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the community...
>>
>> The current list of changes can be seen in the issue tracker:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> 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 Uwe Barthel <ba...@x-reizend.de>.
Hi Karl Heinz,
did you merge any of the open github.com PRs into it?
-- barthel
> On 11 Jun 2016, at 22:21, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash: 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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 Anton,
On 6/12/16 12:43 AM, Anton Tanasenko wrote:
> Hi,
> There is a commit for MNG-2478 which I think could cause problems for
> projects that are authored using 3.4.0 and the new resources-filtered
> source folder is used (provided it was not configured in the project as
> such before). Those projects will not be buildable with prior maven
> versions.
> This is not something major, but it does break backwards compatibility
> somewhat. Is that ok?
Hm..good hint...
The change is this:
diff --git
a/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
b/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
index ae49e84..5abbb2c 100644
---
a/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
+++
b/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
@@ -62,11 +62,19 @@ under the License.
<resource>
<directory>${project.basedir}/src/main/resources</directory>
</resource>
+ <resource>
+
<directory>${project.basedir}/src/main/filtered-resources</directory>
+ <filtering>true</filtering>
+ </resource>
</resources>
<testResources>
<testResource>
<directory>${project.basedir}/src/test/resources</directory>
</testResource>
+ <testResource>
+
<directory>${project.basedir}/src/test/filtered-resources</directory>
+ <filtering>true</filtering>
+ </testResource>
</testResources>
<pluginManagement>
which means only adding a new folder which is filtered by default. Yes
if a project contains such folder and it is not configured it could
cause a problem..
This is one of the points which is important for the release notes...
Thanks.
Karl Heinz
>
> https://issues.apache.org/jira/browse/MNG-2478
>
>
> 2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise <kh...@gmx.de>:
>
>> Hi to all Maven users,
>>
>> is someone of you willing to do some testing on the current state of
>> development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash:
>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>> community...
>>
>> The current list of changes can be seen in the issue tracker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
Mit freundlichem Gru�
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
Hauptstrasse 177
52146 W�rselen http://www.soebes.de
---------------------------------------------------------------------
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 jieryn,
On 6/12/16 3:58 AM, jieryn wrote:
> Tested on RHEL 7, Java 8, -T8, all maven plugins up to date with
> current releases (thanks versions-m-p), on many internal projects for
> basic build/test/it and it is working great! It really looks great and
> modern! :-)
>
> Now I just made it my default version of Apache Maven
Important note. This is not a official release. This is only preliminary
test state...
Anyway. First thanks for testing and giving feedback..
> and will give it
> more rigorous testing throughout the week, more plugins, more goals,
> more profiles, more oddball cases.
That would be great...
Thanks in advance...
Kind regards
Karl Heinz
>
> (not scientific testing, but I am seeing minor performance
> improvements on the order of 2-3% despite colour outputs)
sounds good...
>
> Thank you Apache Maven Team! Thank you Karl :)
>
>
> On Sat, Jun 11, 2016 at 6:43 PM, Anton Tanasenko
> <at...@gmail.com> wrote:
>> Hi,
>> There is a commit for MNG-2478 which I think could cause problems for
>> projects that are authored using 3.4.0 and the new resources-filtered
>> source folder is used (provided it was not configured in the project as
>> such before). Those projects will not be buildable with prior maven
>> versions.
>> This is not something major, but it does break backwards compatibility
>> somewhat. Is that ok?
>>
>> https://issues.apache.org/jira/browse/MNG-2478
>>
>>
>> 2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise <kh...@gmx.de>:
>>
>>> Hi to all Maven users,
>>>
>>> is someone of you willing to do some testing on the current state of
>>> development for the upcoming Maven 3.4.0 release?
>>>
>>> Please be aware of this *** This is not an official release ***
>>>
>>> I have created downloadable packages which are available from here:
>>>
>>> Windows: https://s.apache.org/fawM,
>>> Linux: https://s.apache.org/RQ3C
>>>
>>>
>>> Every kind of feedback is helpful.
>>>
>>> This is only a current state of development (Git hash:
>>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>>> community...
>>>
>>> The current list of changes can be seen in the issue tracker:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> Regards,
>> Anton.
---------------------------------------------------------------------
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 jieryn <ji...@gmail.com>.
Tested on RHEL 7, Java 8, -T8, all maven plugins up to date with
current releases (thanks versions-m-p), on many internal projects for
basic build/test/it and it is working great! It really looks great and
modern! :-)
Now I just made it my default version of Apache Maven and will give it
more rigorous testing throughout the week, more plugins, more goals,
more profiles, more oddball cases.
(not scientific testing, but I am seeing minor performance
improvements on the order of 2-3% despite colour outputs)
Thank you Apache Maven Team! Thank you Karl :)
On Sat, Jun 11, 2016 at 6:43 PM, Anton Tanasenko
<at...@gmail.com> wrote:
> Hi,
> There is a commit for MNG-2478 which I think could cause problems for
> projects that are authored using 3.4.0 and the new resources-filtered
> source folder is used (provided it was not configured in the project as
> such before). Those projects will not be buildable with prior maven
> versions.
> This is not something major, but it does break backwards compatibility
> somewhat. Is that ok?
>
> https://issues.apache.org/jira/browse/MNG-2478
>
>
> 2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise <kh...@gmx.de>:
>
>> Hi to all Maven users,
>>
>> is someone of you willing to do some testing on the current state of
>> development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash:
>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>> community...
>>
>> The current list of changes can be seen in the issue tracker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Regards,
> Anton.
---------------------------------------------------------------------
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 Anton Tanasenko <at...@gmail.com>.
Hi,
There is a commit for MNG-2478 which I think could cause problems for
projects that are authored using 3.4.0 and the new resources-filtered
source folder is used (provided it was not configured in the project as
such before). Those projects will not be buildable with prior maven
versions.
This is not something major, but it does break backwards compatibility
somewhat. Is that ok?
https://issues.apache.org/jira/browse/MNG-2478
2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise <kh...@gmx.de>:
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Regards,
Anton.
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Christian Schulte <cs...@schulte.it>.
Am 06/12/16 um 21:47 schrieb Mirko Friedenhagen:
> Hello Christian,
>
> that I could fix. Although hamcrest is transitive in junit.
It is a 'compile' scope dependency of 'junit' and that is transitive and
will become 'test' in case of using 'junit' in 'test' scope. If you
manage that dependency to 'test' scope it will no longer be a 'compile'
scope dependency of 'junit' but a 'test' scope one. And that is not
transitive and will not be available in the classpath.
Concerning
> https://github.com/1and1/testlink-junit/:
> I now invoked the project as 'mvn340 -P '!foss-parent-verification'
> clean verify' and get other stack traces. This might be because the
> parent pom of the project manages logback as having scope test, that
> means probably that the project class path is leaking into the plugin
> class path.
> When I try to manage the dependencies as scope runtime, the version
> number is not picked up from the parent.
I think you are running into
<https://github.com/gleclaire/findbugs-maven-plugin/pull/35>.
---------------------------------------------------------------------
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 Mirko Friedenhagen <mf...@gmail.com>.
Hello Christian,
that I could fix. Although hamcrest is transitive in junit. Concerning
https://github.com/1and1/testlink-junit/:
I now invoked the project as 'mvn340 -P '!foss-parent-verification'
clean verify' and get other stack traces. This might be because the
parent pom of the project manages logback as having scope test, that
means probably that the project class path is leaking into the plugin
class path.
When I try to manage the dependencies as scope runtime, the version
number is not picked up from the parent.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sun, Jun 12, 2016 at 10:27 AM, Christian Schulte <cs...@schulte.it> wrote:
> Am 06/12/16 um 00:03 schrieb Mirko Friedenhagen:
>> Hello Karl-Heinz,
>>
>> I tried this with 2 projects, firstly an inhouse project and it choked with:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
>> (default-test) on project ui-mamido-qamove: Execution default-test of
>> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
>> There was an error in the forked process
>>
>> [ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
>> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> You are managing a transitive dependency to 'test' scope which isn't
> transitive. You need to move that transitive dependency up one level to
> make it a direct dependency.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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 06/12/16 um 00:03 schrieb Mirko Friedenhagen:
> Hello Karl-Heinz,
>
> I tried this with 2 projects, firstly an inhouse project and it choked with:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
> (default-test) on project ui-mamido-qamove: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
> There was an error in the forked process
>
> [ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
You are managing a transitive dependency to 'test' scope which isn't
transitive. You need to move that transitive dependency up one level to
make it a direct dependency.
---------------------------------------------------------------------
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 Mirko Friedenhagen <mf...@gmail.com>.
Forgot to mention: Both projects run fine with 3.3.9.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sun, Jun 12, 2016 at 12:03 AM, Mirko Friedenhagen
<mf...@gmail.com> wrote:
> Hello Karl-Heinz,
>
> I tried this with 2 projects, firstly an inhouse project and it choked with:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
> (default-test) on project ui-mamido-qamove: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
> There was an error in the forked process
>
> [ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:76)
>
> [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
>
> [ERROR] at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
>
> [ERROR] at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
>
> [ERROR] at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
>
> [ERROR] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
>
> [ERROR] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>
> [ERROR] Caused by: java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> [ERROR] at java.lang.ClassLoader.defineClass1(Native Method)
>
> [ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>
> [ERROR] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>
> [ERROR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>
> [ERROR] at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>
> [ERROR] at java.security.AccessController.doPrivileged(Native Method)
>
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> [ERROR] at org.junit.runner.Computer.getSuite(Computer.java:28)
>
> [ERROR] at org.junit.runner.Request.classes(Request.java:75)
>
> [ERROR] at org.junit.runner.Request.classes(Request.java:91)
>
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
>
> [ERROR] at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
>
> [ERROR] ... 6 more
>
> [ERROR] Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> [ERROR] ... 26 more
>
> [ERROR] -> [Help 1]
>
> [ERROR]
>
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> [ERROR]
>
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
>
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>
>
> then I tried this with https://github.com/1and1/testlink-junit and it
> choked like this:
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs (findbugs) on
> project tljunit-parent: Unable to parse configuration of mojo
> org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
> with value '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList -> [Help 1]
>
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs
> (findbugs) on project tljunit-parent: Unable to parse configuration of
> mojo org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for
> parameter pluginArtifacts: Cannot assign configuration entry
> 'pluginArtifacts' with value '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:214)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:354)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:199)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:116)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:80)
>
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
>
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
>
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
>
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
>
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
>
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke (Method.java:498)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
>
> Caused by: org.apache.maven.plugin.PluginConfigurationException:
> Unable to parse configuration of mojo
> org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
> with value '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList
>
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
> (DefaultMavenPluginManager.java:660)
>
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:592)
>
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:121)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:209)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:354)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:199)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:116)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:80)
>
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
>
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
>
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
>
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
>
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
>
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke (Method.java:498)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
>
> Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Cannot assign configuration entry 'pluginArtifacts' with value
> '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList
>
> at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.failIfNotTypeCompatible
> (AbstractConfigurationConverter.java:100)
>
> at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration
> (CollectionConverter.java:82)
>
> at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration
> (CollectionConverter.java:47)
>
> at org.eclipse.sisu.plexus.CompositeBeanHelper.convertProperty
> (CompositeBeanHelper.java:273)
>
> at org.eclipse.sisu.plexus.CompositeBeanHelper.setProperty
> (CompositeBeanHelper.java:174)
>
> at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration
> (ObjectWithFieldsConverter.java:101)
>
> at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent
> (BasicComponentConfigurator.java:34)
>
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
> (DefaultMavenPluginManager.java:630)
>
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:592)
>
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:121)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:209)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:354)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:199)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:155)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:147)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:116)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:80)
>
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
>
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
>
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
>
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
>
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
>
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
>
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke (Method.java:498)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
>
> [ERROR]
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> [ERROR]
>
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
>
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginConfigurationException
>
>
> Regards
> Mirko
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Sat, Jun 11, 2016 at 11:29 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>> Hi Oliver,
>>
>> On 6/11/16 11:25 PM, Oliver B. Fischer wrote:
>>>
>>> Hi,
>>>
>>> Can I use the Linux package to test it on OS X?
>>
>>
>> Yes I do that the whole time ;-)
>>
>> we have no dedicated OS X package ;-)..
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>>
>>>
>>> Best
>>>
>>> Oliver
>>>
>>> Von meinem iPhone gesendet
>>>
>>>> Am 11.06.2016 um 22:21 schrieb Karl Heinz Marbaise <kh...@gmx.de>:
>>>>
>>>> Hi to all Maven users,
>>>>
>>>> is someone of you willing to do some testing on the current state of
>>>> development for the upcoming Maven 3.4.0 release?
>>>>
>>>> Please be aware of this *** This is not an official release ***
>>>>
>>>> I have created downloadable packages which are available from here:
>>>>
>>>> Windows: https://s.apache.org/fawM,
>>>> Linux: https://s.apache.org/RQ3C
>>>>
>>>>
>>>> Every kind of feedback is helpful.
>>>>
>>>> This is only a current state of development (Git hash:
>>>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>>>> community...
>>>>
>>>> The current list of changes can be seen in the issue tracker:
>>>>
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
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 Mirko Friedenhagen <mf...@gmail.com>.
Hello Karl-Heinz,
I tried this with 2 projects, firstly an inhouse project and it choked with:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19:test
(default-test) on project ui-mamido-qamove: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
There was an error in the forked process
[ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
[ERROR] at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:76)
[ERROR] at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
[ERROR] at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
[ERROR] at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
[ERROR] at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
[ERROR] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
[ERROR] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
[ERROR] Caused by: java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
[ERROR] at java.lang.ClassLoader.defineClass1(Native Method)
[ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
[ERROR] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[ERROR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
[ERROR] at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
[ERROR] at java.security.AccessController.doPrivileged(Native Method)
[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
[ERROR] at org.junit.runner.Computer.getSuite(Computer.java:28)
[ERROR] at org.junit.runner.Request.classes(Request.java:75)
[ERROR] at org.junit.runner.Request.classes(Request.java:91)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
[ERROR] ... 6 more
[ERROR] Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
[ERROR] ... 26 more
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
then I tried this with https://github.com/1and1/testlink-junit and it
choked like this:
[ERROR] Failed to execute goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs (findbugs) on
project tljunit-parent: Unable to parse configuration of mojo
org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
with value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs
(findbugs) on project tljunit-parent: Unable to parse configuration of
mojo org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for
parameter pluginArtifacts: Cannot assign configuration entry
'pluginArtifacts' with value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:214)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
(MojoExecutor.java:354)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:199)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginConfigurationException:
Unable to parse configuration of mojo
org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
with value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
(DefaultMavenPluginManager.java:660)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
(DefaultMavenPluginManager.java:592)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:121)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
(MojoExecutor.java:354)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:199)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot assign configuration entry 'pluginArtifacts' with value
'${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList
at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.failIfNotTypeCompatible
(AbstractConfigurationConverter.java:100)
at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration
(CollectionConverter.java:82)
at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration
(CollectionConverter.java:47)
at org.eclipse.sisu.plexus.CompositeBeanHelper.convertProperty
(CompositeBeanHelper.java:273)
at org.eclipse.sisu.plexus.CompositeBeanHelper.setProperty
(CompositeBeanHelper.java:174)
at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration
(ObjectWithFieldsConverter.java:101)
at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent
(BasicComponentConfigurator.java:34)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
(DefaultMavenPluginManager.java:630)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
(DefaultMavenPluginManager.java:592)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:121)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
(MojoExecutor.java:354)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:199)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:984)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:311)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginConfigurationException
Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sat, Jun 11, 2016 at 11:29 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> Hi Oliver,
>
> On 6/11/16 11:25 PM, Oliver B. Fischer wrote:
>>
>> Hi,
>>
>> Can I use the Linux package to test it on OS X?
>
>
> Yes I do that the whole time ;-)
>
> we have no dedicated OS X package ;-)..
>
>
> Kind regards
> Karl Heinz Marbaise
>>
>>
>> Best
>>
>> Oliver
>>
>> Von meinem iPhone gesendet
>>
>>> Am 11.06.2016 um 22:21 schrieb Karl Heinz Marbaise <kh...@gmx.de>:
>>>
>>> Hi to all Maven users,
>>>
>>> is someone of you willing to do some testing on the current state of
>>> development for the upcoming Maven 3.4.0 release?
>>>
>>> Please be aware of this *** This is not an official release ***
>>>
>>> I have created downloadable packages which are available from here:
>>>
>>> Windows: https://s.apache.org/fawM,
>>> Linux: https://s.apache.org/RQ3C
>>>
>>>
>>> Every kind of feedback is helpful.
>>>
>>> This is only a current state of development (Git hash:
>>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>>> community...
>>>
>>> The current list of changes can be seen in the issue tracker:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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 Oliver,
On 6/11/16 11:25 PM, Oliver B. Fischer wrote:
> Hi,
>
> Can I use the Linux package to test it on OS X?
Yes I do that the whole time ;-)
we have no dedicated OS X package ;-)..
Kind regards
Karl Heinz Marbaise
>
> Best
>
> Oliver
>
> Von meinem iPhone gesendet
>
>> Am 11.06.2016 um 22:21 schrieb Karl Heinz Marbaise <kh...@gmx.de>:
>>
>> Hi to all Maven users,
>>
>> is someone of you willing to do some testing on the current state of development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash: 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the community...
>>
>> The current list of changes can be seen in the issue tracker:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
---------------------------------------------------------------------
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 "Oliver B. Fischer" <o....@swe-blog.net>.
Hi,
Can I use the Linux package to test it on OS X?
Best
Oliver
Von meinem iPhone gesendet
> Am 11.06.2016 um 22:21 schrieb Karl Heinz Marbaise <kh...@gmx.de>:
>
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash: 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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 06/12/16 um 23:03 schrieb Mirko Friedenhagen:
> So maybe I got all scopes wrong,
Yes. And that's the reason those bugfixes in Maven have been reverted
latetly.
---------------------------------------------------------------------
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 Mirko Friedenhagen <mf...@gmail.com>.
So maybe I got all scopes wrong, however the new version seems
basically quite incompatible with 3.3.9.
On a side note I like to use org.slf4j.simpleLogger.showDateTime=true
during CI runs. With the new logger the build time does not show
anymore, the only thing that happens is that there is no coloring
anymore.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sun, Jun 12, 2016 at 10:55 PM, Anton Tanasenko
<at...@gmail.com> wrote:
> It would be great if there was a way to enable/disable color using a
> separate option or system property.
> Adding -B could disable color by default, but explicitly enabling it might
> prove useful in, say, Jenkins with AnsiColor plugin.
>
> 2016-06-12 23:39 GMT+03:00 Baptiste Mathus <ml...@batmat.net>:
>
>> Well, as I hadn't tested this version and was just guessing /by intuition/
>> on what I generally use --batch-mode for, I'd disagree on your last
>> statement :).
>> But agreed it might be interesting to have some words about it in the help.
>> Patches/PR are always welcome.
>>
>> 2016-06-12 22:15 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>> > Yes, running with -B disables the colorized output.
>> >
>> > But at least the description of this option should mention this too
>> > because IMHO it is not intuitive that -B disables the colors.
>> >
>> >
>> > WDYT?
>> >
>> > Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
>> >
>> >> Didn't test it, but using batch mode would seem natural for that IMO.
>> >>
>> >> My 2 cents
>> >>
>> >> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
>> >:
>> >>
>> >> The colorized output is very nice, but I would like to have also a
>> >>> commandline option to disable it. I often redirect the output of Maven
>> >>> to a
>> >>> file to check the build. All the escape sequences are disturbing in
>> this
>> >>> case.
>> >>>
>> >>> Running mvn --help I didn't see an option to disable it. Could such an
>> >>> option be added?
>> >>>
>> >>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>> >>>
>> >>> --
>> >>> 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
>> >>>
>> >>>
>> >>>
>> > --
>> > 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
>> >
>> >
>>
>
>
>
> --
> Regards,
> Anton.
---------------------------------------------------------------------
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 Anton Tanasenko <at...@gmail.com>.
It would be great if there was a way to enable/disable color using a
separate option or system property.
Adding -B could disable color by default, but explicitly enabling it might
prove useful in, say, Jenkins with AnsiColor plugin.
2016-06-12 23:39 GMT+03:00 Baptiste Mathus <ml...@batmat.net>:
> Well, as I hadn't tested this version and was just guessing /by intuition/
> on what I generally use --batch-mode for, I'd disagree on your last
> statement :).
> But agreed it might be interesting to have some words about it in the help.
> Patches/PR are always welcome.
>
> 2016-06-12 22:15 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>
> > Yes, running with -B disables the colorized output.
> >
> > But at least the description of this option should mention this too
> > because IMHO it is not intuitive that -B disables the colors.
> >
> >
> > WDYT?
> >
> > Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
> >
> >> Didn't test it, but using batch mode would seem natural for that IMO.
> >>
> >> My 2 cents
> >>
> >> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> >>
> >> The colorized output is very nice, but I would like to have also a
> >>> commandline option to disable it. I often redirect the output of Maven
> >>> to a
> >>> file to check the build. All the escape sequences are disturbing in
> this
> >>> case.
> >>>
> >>> Running mvn --help I didn't see an option to disable it. Could such an
> >>> option be added?
> >>>
> >>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
> >>>
> >>> --
> >>> 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
> >>>
> >>>
> >>>
> > --
> > 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
> >
> >
>
--
Regards,
Anton.
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Posted by Baptiste Mathus <ml...@batmat.net>.
Well, as I hadn't tested this version and was just guessing /by intuition/
on what I generally use --batch-mode for, I'd disagree on your last
statement :).
But agreed it might be interesting to have some words about it in the help.
Patches/PR are always welcome.
2016-06-12 22:15 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
> Yes, running with -B disables the colorized output.
>
> But at least the description of this option should mention this too
> because IMHO it is not intuitive that -B disables the colors.
>
>
> WDYT?
>
> Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
>
>> Didn't test it, but using batch mode would seem natural for that IMO.
>>
>> My 2 cents
>>
>> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>> The colorized output is very nice, but I would like to have also a
>>> commandline option to disable it. I often redirect the output of Maven
>>> to a
>>> file to check the build. All the escape sequences are disturbing in this
>>> case.
>>>
>>> Running mvn --help I didn't see an option to disable it. Could such an
>>> option be added?
>>>
>>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>>>
>>> --
>>> 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
>>>
>>>
>>>
> --
> 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 "Oliver B. Fischer" <o....@swe-blog.net>.
Yes, running with -B disables the colorized output.
But at least the description of this option should mention this too
because IMHO it is not intuitive that -B disables the colors.
WDYT?
Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
> Didn't test it, but using batch mode would seem natural for that IMO.
>
> My 2 cents
>
> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> The colorized output is very nice, but I would like to have also a
>> commandline option to disable it. I often redirect the output of Maven to a
>> file to check the build. All the escape sequences are disturbing in this
>> case.
>>
>> Running mvn --help I didn't see an option to disable it. Could such an
>> option be added?
>>
>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>>
>> --
>> 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
>>
>>
--
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 "Oliver B. Fischer" <o....@swe-blog.net>.
Funny, I wasn't ware of this option. -l does not disables the colorized
output. Therefore the generated log file also contains escape sequences.
Am 12.06.16 um 22:13 schrieb Robert Scholte:
> Or when -l/--log-file is used?
>
> Robert
>
> On Sun, 12 Jun 2016 22:09:43 +0200, Baptiste Mathus <ml...@batmat.net>
> wrote:
>
>> Didn't test it, but using batch mode would seem natural for that IMO.
>>
>> My 2 cents
>>
>> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
N Oliver B. Fischer
A Schnhauser 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 Robert Scholte <rf...@apache.org>.
Or when -l/--log-file is used?
Robert
On Sun, 12 Jun 2016 22:09:43 +0200, Baptiste Mathus <ml...@batmat.net> wrote:
> Didn't test it, but using batch mode would seem natural for that IMO.
>
> My 2 cents
>
> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> The colorized output is very nice, but I would like to have also a
>> commandline option to disable it. I often redirect the output of Maven
>> to a
>> file to check the build. All the escape sequences are disturbing in this
>> case.
>>
>> Running mvn --help I didn't see an option to disable it. Could such an
>> option be added?
>>
>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>>
>>> Hi to all Maven users,
>>>
>>>
>>> is someone of you willing to do some testing on the current state of
>>> development for the upcoming Maven 3.4.0 release?
>>>
>>> Please be aware of this *** This is not an official release ***
>>>
>>> I have created downloadable packages which are available from here:
>>>
>>> Windows: https://s.apache.org/fawM,
>>> Linux: https://s.apache.org/RQ3C
>>>
>>>
>>> Every kind of feedback is helpful.
>>>
>>> This is only a current state of development (Git hash:
>>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>>> community...
>>>
>>> The current list of changes can be seen in the issue tracker:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> --
>> 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
>>
---------------------------------------------------------------------
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 Baptiste Mathus <ml...@batmat.net>.
Didn't test it, but using batch mode would seem natural for that IMO.
My 2 cents
2016-06-12 22:04 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
> The colorized output is very nice, but I would like to have also a
> commandline option to disable it. I often redirect the output of Maven to a
> file to check the build. All the escape sequences are disturbing in this
> case.
>
> Running mvn --help I didn't see an option to disable it. Could such an
> option be added?
>
> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>
>> Hi to all Maven users,
>>
>>
>> is someone of you willing to do some testing on the current state of
>> development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash:
>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>> community...
>>
>> The current list of changes can be seen in the issue tracker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> --
> 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 "Oliver B. Fischer" <o....@swe-blog.net>.
The colorized output is very nice, but I would like to have also a
commandline option to disable it. I often redirect the output of Maven
to a file to check the build. All the escape sequences are disturbing in
this case.
Running mvn --help I didn't see an option to disable it. Could such an
option be added?
Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from
> the community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
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