Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Markus, I was not talking about excuse. I only said that the JUnit library
has a bug regarding the old junit3 style. As far as I know the situation
with this library, it is very unlikely that it would be fixed.
The Surefire cannot do anything about it once the events are not fired from
JUnit3 TestCase.
As Piotr said you have to use the annotations and not to extend the class
TestCase. This would work for sure.
T

On Mon, Aug 17, 2020 at 7:58 PM Markus KARG  wrote:

> That doesn't make it any better, and it is no excuse that we do not simply
> catch that particular exception inside the Surefire plugin.
> So did we simply forget to implement this is the Surefire plugin (so I can
> add it), did we not implement it deliberately (so I shall not add it), or
> is it broken (so I shall fix it)?
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Tibor Digana [mailto:tibordig...@apache.org]
> Gesendet: Montag, 17. August 2020 18:37
> An: Maven Developers List
> Betreff: Re: Assumption fail treated as unexcepted exception?!
>
> This is the outcome in IDEA:
>
> "Tests failed: 1, passed: 0"
>
> So the behavior is the same with Maven.
>
> On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana 
> wrote:
>
> > Hi Markus,
> >
> > It is a specific problem related to the JUnit library because the test
> > fails in IntelliJ IDEA and in Maven as well.
> >
> > The JUnit4 assumptions fail with yellow markers in IDEA but here the
> > JUnit3' TestCase fails in red as a typical error or failure.
> > And Maven fails this test as follows but i think this behavior starts in
> > the junit library itself.
> >
> > [INFO] Running test.TestAssumptions
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 0.028 s <<< FAILURE! - in test.TestAssumptions
> > [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> > org.junit.AssumptionViolatedException: got: , expected: is 
> > at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
> >
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [ERROR] Errors:
> > [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> > expected: is  > [INFO]
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> > [INFO]
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> >
> > On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> > wrote:
> >
> >> Martin,
> >>
> >> I don't understand your question.
> >>
> >> You posted the Javadocs, and they tell it clearly: "A test for which an
> >> assumption fails should NOT generate a test case failure.".
> >>
> >> Also Assume's Javadocs
> >> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are
> pretty
> >> clear about it: "... A failed assumption does NOT mean the code is
> broken,
> >> but that the test provides no useful information. Assume basically means
> >> "don't RUN this test if these conditions don't apply". The default JUnit
> >> runner SKIPS tests with failing assumptions..."
> >>
> >> So do you really want me to ask the JUnit people whether they really
> MEAN
> >> what they clearly wrote...?
> >>
> >> -Markus
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Martin Gainty [mailto:mgai...@hotmail.com]
> >> Gesendet: Montag, 17. August 2020 12:27
> >> An: Maven Developers List
> >> Betreff: Re: Assumption fail treated as unexcepted exception?!
> >>
> >>
> >>/**
> >>  * Call to assume that actual satisfies the condition
> >> specified by matcher.
> >>  * If not, the test halts and is ignored.
> >>  * Example:
> >>  * :
> >>  *   assumeThat(1, is(1)); // passes
> >>  *   foo(); // will execute
> >>  *   assumeThat(0, is(1)); // assumption failure! test halts
> >>  *   int x = 1 / 0; // will never execute
> >>  * 
> >>  *
> >>  * @param  the static type accepted by the matcher (this can flag
> >> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
> >>  * @param actual the computed value being compared
> >>  * @param matcher an expression, built of {@link Matcher}s,
> specifying
> >> allowed values
> >>  * @see org.hamcrest.CoreMatchers
> >>  * @see org.junit.matchers.JUnitMatchers
> >>  */
> >> public static  void assumeThat(T actual, Matcher matcher) {
> >> if (!matcher.matches(actual)) {
> >> throw new AssumptionViolatedException(actual, matcher);
> >> }
> >> }
> >>
> >> //does AssumptionViolatedException ever produce test case failure?
> >>
> >> /**
> >>  * An exception class used to implement assumptions (state in
> >> which a
> >> given test
> >>  * is meaningful and should or should not be executed). A test for which
> >> an
> >> assumption
> >>  * fails should not generate a test case failure.
> >>  *
> >>  * @see org.junit.Assume
> >>  * @since 4.12
> >>  */
> >> @SuppressWarnings("deprecation")
> >> public class AssumptionViolatedException extends
> >> org.junit.internal.AssumptionViolatedException {
> >> 

MEAR-280 and skinnyWar option

[abrarov]

Hi Maven Developers Community,

 

Could somebody take a look at this comment (the bottom most one) -
https://issues.apache.org/jira/browse/MEAR-280?focusedCommentId=17179014

=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
nt-17179014 - in MEAR-280 "Reproducible Builds: make entries in output ear
files reproducible (order + timestamp)"?

 

It looks like a bug in implementation of new feature (of MEAR-280) and it
would be great (helpful for my use case) to fix it before 3.1.0 release of
Maven EAR Plugin.

 

Thank you.

 

Marat Abrarov.

Re: Assumption fail treated as unexcepted exception?!

[Piotr Żygieło]

What could be fixed is PlexusTestCase
(https://github.com/eclipse/sisu.plexus/tree/master/org.eclipse.sisu.plexus)
that TestCopyMojo inherits from. Migrate it to JUnit 4, and one day it
will reach maven-dependency-plugin via maven-plugin-testing-harness.
It's that simple.

OR

Upgrade TestCopyMojo to JUnit 4:
1. Add explicit runner to TestCopyMojo
2. Add (missing now) @Test-s and @Before etc
3. upgrade surefire plugin (currently used 2.22.0 does not mark
not-assumed as skipped)
and you'll get:

[WARNING] Tests run: 2, Failures: 0, Errors: 0, Skipped: 1, Time
elapsed: 2.432 s - in
org.apache.maven.plugins.dependency.fromConfiguration.TestCopyMojo

with
62  
63
in xml surefire report.

(https://github.com/pzygielo/maven-dependency-plugin/commit/353ca210c720278b42e4dca1e7f3f3c34c439c9a,
ran with `mvn test -Dtest=TestCopyMojo`).
Given all existing test methods meet their goals.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

That doesn't make it any better, and it is no excuse that we do not simply 
catch that particular exception inside the Surefire plugin.
So did we simply forget to implement this is the Surefire plugin (so I can add 
it), did we not implement it deliberately (so I shall not add it), or is it 
broken (so I shall fix it)?
-Markus

-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 18:37
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

This is the outcome in IDEA:

"Tests failed: 1, passed: 0"

So the behavior is the same with Maven.

On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana  wrote:

> Hi Markus,
>
> It is a specific problem related to the JUnit library because the test
> fails in IntelliJ IDEA and in Maven as well.
>
> The JUnit4 assumptions fail with yellow markers in IDEA but here the
> JUnit3' TestCase fails in red as a typical error or failure.
> And Maven fails this test as follows but i think this behavior starts in
> the junit library itself.
>
> [INFO] Running test.TestAssumptions
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.028 s <<< FAILURE! - in test.TestAssumptions
> [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> org.junit.AssumptionViolatedException: got: , expected: is 
> at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> expected: is  [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
>
> On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> wrote:
>
>> Martin,
>>
>> I don't understand your question.
>>
>> You posted the Javadocs, and they tell it clearly: "A test for which an
>> assumption fails should NOT generate a test case failure.".
>>
>> Also Assume's Javadocs
>> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
>> clear about it: "... A failed assumption does NOT mean the code is broken,
>> but that the test provides no useful information. Assume basically means
>> "don't RUN this test if these conditions don't apply". The default JUnit
>> runner SKIPS tests with failing assumptions..."
>>
>> So do you really want me to ask the JUnit people whether they really MEAN
>> what they clearly wrote...?
>>
>> -Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Martin Gainty [mailto:mgai...@hotmail.com]
>> Gesendet: Montag, 17. August 2020 12:27
>> An: Maven Developers List
>> Betreff: Re: Assumption fail treated as unexcepted exception?!
>>
>>
>>/**
>>  * Call to assume that actual satisfies the condition
>> specified by matcher.
>>  * If not, the test halts and is ignored.
>>  * Example:
>>  * :
>>  *   assumeThat(1, is(1)); // passes
>>  *   foo(); // will execute
>>  *   assumeThat(0, is(1)); // assumption failure! test halts
>>  *   int x = 1 / 0; // will never execute
>>  * 
>>  *
>>  * @param  the static type accepted by the matcher (this can flag
>> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>>  * @param actual the computed value being compared
>>  * @param matcher an expression, built of {@link Matcher}s, specifying
>> allowed values
>>  * @see org.hamcrest.CoreMatchers
>>  * @see org.junit.matchers.JUnitMatchers
>>  */
>> public static  void assumeThat(T actual, Matcher matcher) {
>> if (!matcher.matches(actual)) {
>> throw new AssumptionViolatedException(actual, matcher);
>> }
>> }
>>
>> //does AssumptionViolatedException ever produce test case failure?
>>
>> /**
>>  * An exception class used to implement assumptions (state in
>> which a
>> given test
>>  * is meaningful and should or should not be executed). A test for which
>> an
>> assumption
>>  * fails should not generate a test case failure.
>>  *
>>  * @see org.junit.Assume
>>  * @since 4.12
>>  */
>> @SuppressWarnings("deprecation")
>> public class AssumptionViolatedException extends
>> org.junit.internal.AssumptionViolatedException {
>> private static final long serialVersionUID = 1L;
>>
>> /**
>>  * An assumption exception with the given actual value and a
>> matcher describing
>>  * the expectation that failed.
>>  */
>> public  AssumptionViolatedException(T actual, Matcher matcher) {
>> super(actual, matcher);
>> }
>>
>> /**
>>  * An assumption exception with a message with the given actual
>> value and a
>>  * matcher describing the expectation that failed.
>>  */
>> public  AssumptionViolatedException(String message, T expected,
>> Matcher matcher) {
>> super(message, expected, matcher);
>> }
>>
>> /**
>>  * An assumption exception with the given message only.
>>  

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

This is the outcome in IDEA:

"Tests failed: 1, passed: 0"

So the behavior is the same with Maven.

On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana  wrote:

> Hi Markus,
>
> It is a specific problem related to the JUnit library because the test
> fails in IntelliJ IDEA and in Maven as well.
>
> The JUnit4 assumptions fail with yellow markers in IDEA but here the
> JUnit3' TestCase fails in red as a typical error or failure.
> And Maven fails this test as follows but i think this behavior starts in
> the junit library itself.
>
> [INFO] Running test.TestAssumptions
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.028 s <<< FAILURE! - in test.TestAssumptions
> [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> org.junit.AssumptionViolatedException: got: , expected: is 
> at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> expected: is  [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
>
> On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> wrote:
>
>> Martin,
>>
>> I don't understand your question.
>>
>> You posted the Javadocs, and they tell it clearly: "A test for which an
>> assumption fails should NOT generate a test case failure.".
>>
>> Also Assume's Javadocs
>> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
>> clear about it: "... A failed assumption does NOT mean the code is broken,
>> but that the test provides no useful information. Assume basically means
>> "don't RUN this test if these conditions don't apply". The default JUnit
>> runner SKIPS tests with failing assumptions..."
>>
>> So do you really want me to ask the JUnit people whether they really MEAN
>> what they clearly wrote...?
>>
>> -Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Martin Gainty [mailto:mgai...@hotmail.com]
>> Gesendet: Montag, 17. August 2020 12:27
>> An: Maven Developers List
>> Betreff: Re: Assumption fail treated as unexcepted exception?!
>>
>>
>>/**
>>  * Call to assume that actual satisfies the condition
>> specified by matcher.
>>  * If not, the test halts and is ignored.
>>  * Example:
>>  * :
>>  *   assumeThat(1, is(1)); // passes
>>  *   foo(); // will execute
>>  *   assumeThat(0, is(1)); // assumption failure! test halts
>>  *   int x = 1 / 0; // will never execute
>>  * 
>>  *
>>  * @param  the static type accepted by the matcher (this can flag
>> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>>  * @param actual the computed value being compared
>>  * @param matcher an expression, built of {@link Matcher}s, specifying
>> allowed values
>>  * @see org.hamcrest.CoreMatchers
>>  * @see org.junit.matchers.JUnitMatchers
>>  */
>> public static  void assumeThat(T actual, Matcher matcher) {
>> if (!matcher.matches(actual)) {
>> throw new AssumptionViolatedException(actual, matcher);
>> }
>> }
>>
>> //does AssumptionViolatedException ever produce test case failure?
>>
>> /**
>>  * An exception class used to implement assumptions (state in
>> which a
>> given test
>>  * is meaningful and should or should not be executed). A test for which
>> an
>> assumption
>>  * fails should not generate a test case failure.
>>  *
>>  * @see org.junit.Assume
>>  * @since 4.12
>>  */
>> @SuppressWarnings("deprecation")
>> public class AssumptionViolatedException extends
>> org.junit.internal.AssumptionViolatedException {
>> private static final long serialVersionUID = 1L;
>>
>> /**
>>  * An assumption exception with the given actual value and a
>> matcher describing
>>  * the expectation that failed.
>>  */
>> public  AssumptionViolatedException(T actual, Matcher matcher) {
>> super(actual, matcher);
>> }
>>
>> /**
>>  * An assumption exception with a message with the given actual
>> value and a
>>  * matcher describing the expectation that failed.
>>  */
>> public  AssumptionViolatedException(String message, T expected,
>> Matcher matcher) {
>> super(message, expected, matcher);
>> }
>>
>> /**
>>  * An assumption exception with the given message only.
>>  */
>> public AssumptionViolatedException(String message) {
>> super(message);
>> }
>>
>> /**
>>  * An assumption exception with the given message and a cause.
>>  */
>> public AssumptionViolatedException(String assumption, Throwable t) {
>> super(assumption, t);
>> }
>> }
>>
>> //will base class throw FAILURE for TestCase?
>> /**
>>  * An exception class used to implement assumptions (state in
>> which a
>> given test
>>  * is meaningful and should or should not be executed). A test for which
>> 

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Hi Markus,

It is a specific problem related to the JUnit library because the test
fails in IntelliJ IDEA and in Maven as well.

The JUnit4 assumptions fail with yellow markers in IDEA but here the
JUnit3' TestCase fails in red as a typical error or failure.
And Maven fails this test as follows but i think this behavior starts in
the junit library itself.

[INFO] Running test.TestAssumptions
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.028 s <<< FAILURE! - in test.TestAssumptions
[ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
org.junit.AssumptionViolatedException: got: , expected: is 
at test/test.TestAssumptions.testABC(TestAssumptions.java:9)

[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
expected: is  wrote:

> Martin,
>
> I don't understand your question.
>
> You posted the Javadocs, and they tell it clearly: "A test for which an
> assumption fails should NOT generate a test case failure.".
>
> Also Assume's Javadocs
> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
> clear about it: "... A failed assumption does NOT mean the code is broken,
> but that the test provides no useful information. Assume basically means
> "don't RUN this test if these conditions don't apply". The default JUnit
> runner SKIPS tests with failing assumptions..."
>
> So do you really want me to ask the JUnit people whether they really MEAN
> what they clearly wrote...?
>
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Martin Gainty [mailto:mgai...@hotmail.com]
> Gesendet: Montag, 17. August 2020 12:27
> An: Maven Developers List
> Betreff: Re: Assumption fail treated as unexcepted exception?!
>
>
>/**
>  * Call to assume that actual satisfies the condition
> specified by matcher.
>  * If not, the test halts and is ignored.
>  * Example:
>  * :
>  *   assumeThat(1, is(1)); // passes
>  *   foo(); // will execute
>  *   assumeThat(0, is(1)); // assumption failure! test halts
>  *   int x = 1 / 0; // will never execute
>  * 
>  *
>  * @param  the static type accepted by the matcher (this can flag
> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>  * @param actual the computed value being compared
>  * @param matcher an expression, built of {@link Matcher}s, specifying
> allowed values
>  * @see org.hamcrest.CoreMatchers
>  * @see org.junit.matchers.JUnitMatchers
>  */
> public static  void assumeThat(T actual, Matcher matcher) {
> if (!matcher.matches(actual)) {
> throw new AssumptionViolatedException(actual, matcher);
> }
> }
>
> //does AssumptionViolatedException ever produce test case failure?
>
> /**
>  * An exception class used to implement assumptions (state in which
> a
> given test
>  * is meaningful and should or should not be executed). A test for which an
> assumption
>  * fails should not generate a test case failure.
>  *
>  * @see org.junit.Assume
>  * @since 4.12
>  */
> @SuppressWarnings("deprecation")
> public class AssumptionViolatedException extends
> org.junit.internal.AssumptionViolatedException {
> private static final long serialVersionUID = 1L;
>
> /**
>  * An assumption exception with the given actual value and a
> matcher describing
>  * the expectation that failed.
>  */
> public  AssumptionViolatedException(T actual, Matcher matcher) {
> super(actual, matcher);
> }
>
> /**
>  * An assumption exception with a message with the given actual
> value and a
>  * matcher describing the expectation that failed.
>  */
> public  AssumptionViolatedException(String message, T expected,
> Matcher matcher) {
> super(message, expected, matcher);
> }
>
> /**
>  * An assumption exception with the given message only.
>  */
> public AssumptionViolatedException(String message) {
> super(message);
> }
>
> /**
>  * An assumption exception with the given message and a cause.
>  */
> public AssumptionViolatedException(String assumption, Throwable t) {
> super(assumption, t);
> }
> }
>
> //will base class throw FAILURE for TestCase?
> /**
>  * An exception class used to implement assumptions (state in which
> a
> given test
>  * is meaningful and should or should not be executed). A test for which an
> assumption
>  * fails should not generate a test case failure.
>  *
>  * @see org.junit.Assume
>  */
> public class AssumptionViolatedException extends RuntimeException
> implements
> SelfDescribing {
> private static final long serialVersionUID = 2L;
>
> /*
>  * We have to use the f prefix until the next major release to ensure
>  * serialization compatibility.
>  * See https://github.com/junit-team/junit/issues/976
>  */
> private final String fAssumption;
> private final boolean fValueMatcher;
> 

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

[Sylwester Lachiewicz]

+1(non binding)

pon., 17 sie 2020, 17:12 użytkownik Olivier Lamy  napisał:

> +1
>
> On Mon, 17 Aug 2020 at 10:45 pm, Elliotte Rusty Harold  >
> wrote:
>
> > Ping. Can I get two more +1's on this? Once this is out, we'll be
> >
> > ready to release a new maven-dependency-plugin that reintroduces the
> >
> > verbose option for dependency:tree for the first time since Maven 2.
> >
> >
> >
> > On Mon, Aug 10, 2020 at 10:19 AM Elliotte Rusty Harold
> >
> >  wrote:
> >
> > >
> >
> > > Let's try this one more time. I updated Jira and regenerated the
> >
> > > release notes. Nothing else has changed:
> >
> > >
> >
> > > Hi,
> >
> > >
> >
> > > We solved 3 issues:
> >
> > >
> >
> > > [MSHARED-949] - dependency:analyze should recommend narrower scope
> >
> > > where possible
> >
> > > [MSHARED-948] - Update link to Jira
> >
> > > [MSHARED-932] - Remove JMock dependency
> >
> > >
> >
> > > There are still five issues left in JIRA:
> >
> > >
> >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> > >
> >
> > >
> >
> > > Staging repo:
> >
> > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> >
> > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
> >
> > >
> >
> > > Source release checksum(s):
> >
> > > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> >
> > >
> >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
> >
> > >
> >
> > > Staging site:
> >
> > >
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > >
> >
> > > Guide to testing staged releases:
> >
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > >
> >
> > > Vote open for at least 72 hours.
> >
> > >
> >
> > > [ ] +1
> >
> > > [ ] +0
> >
> > > [ ] -1
> >
> > >
> >
> > >
> >
> > > On Wed, Aug 5, 2020 at 4:31 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > wrote:
> >
> > > >
> >
> > > > Hi,
> >
> > > >
> >
> > > > We solved 2 issues:
> >
> > > > * [MSHARED-932] Remove JMock dependency
> >
> > > > * [MDEP-708] dependency:analyze should recommend narrower scope
> >
> > > > where possible
> >
> > > >
> >
> > > > There are still five issues left in JIRA:
> >
> > > >
> >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> > > >
> >
> > > >
> >
> > > > Staging repo:
> >
> > > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> >
> > > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
> >
> > > >
> >
> > > > Source release checksum(s):
> >
> > > > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> >
> > > >
> >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
> >
> > > >
> >
> > > > Staging site:
> >
> > > >
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > > >
> >
> > > > Guide to testing staged releases:
> >
> > > >
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > > >
> >
> > > > Vote open for at least 72 hours.
> >
> > > >
> >
> > > > [ ] +1
> >
> > > > [ ] +0
> >
> > > > [ ] -1
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > > Elliotte Rusty Harold
> >
> > > > elh...@ibiblio.org
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Elliotte Rusty Harold
> >
> > > elh...@ibiblio.org
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Elliotte Rusty Harold
> >
> > elh...@ibiblio.org
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> > --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

[Olivier Lamy]

+1

On Mon, 17 Aug 2020 at 10:45 pm, Elliotte Rusty Harold 
wrote:

> Ping. Can I get two more +1's on this? Once this is out, we'll be
>
> ready to release a new maven-dependency-plugin that reintroduces the
>
> verbose option for dependency:tree for the first time since Maven 2.
>
>
>
> On Mon, Aug 10, 2020 at 10:19 AM Elliotte Rusty Harold
>
>  wrote:
>
> >
>
> > Let's try this one more time. I updated Jira and regenerated the
>
> > release notes. Nothing else has changed:
>
> >
>
> > Hi,
>
> >
>
> > We solved 3 issues:
>
> >
>
> > [MSHARED-949] - dependency:analyze should recommend narrower scope
>
> > where possible
>
> > [MSHARED-948] - Update link to Jira
>
> > [MSHARED-932] - Remove JMock dependency
>
> >
>
> > There are still five issues left in JIRA:
>
> >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
>
> >
>
> >
>
> > Staging repo:
>
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
>
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
>
> >
>
> > Source release checksum(s):
>
> > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
>
> >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
>
> >
>
> > Staging site:
>
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
>
> >
>
> > Guide to testing staged releases:
>
> > https://maven.apache.org/guides/development/guide-testing-releases.html
>
> >
>
> > Vote open for at least 72 hours.
>
> >
>
> > [ ] +1
>
> > [ ] +0
>
> > [ ] -1
>
> >
>
> >
>
> > On Wed, Aug 5, 2020 at 4:31 PM Elliotte Rusty Harold 
> wrote:
>
> > >
>
> > > Hi,
>
> > >
>
> > > We solved 2 issues:
>
> > > * [MSHARED-932] Remove JMock dependency
>
> > > * [MDEP-708] dependency:analyze should recommend narrower scope
>
> > > where possible
>
> > >
>
> > > There are still five issues left in JIRA:
>
> > >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
>
> > >
>
> > >
>
> > > Staging repo:
>
> > >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
>
> > >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
>
> > >
>
> > > Source release checksum(s):
>
> > > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
>
> > >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
>
> > >
>
> > > Staging site:
>
> > >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
>
> > >
>
> > > Guide to testing staged releases:
>
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> > >
>
> > > Vote open for at least 72 hours.
>
> > >
>
> > > [ ] +1
>
> > > [ ] +0
>
> > > [ ] -1
>
> > >
>
> > >
>
> > > --
>
> > > Elliotte Rusty Harold
>
> > > elh...@ibiblio.org
>
> >
>
> >
>
> >
>
> > --
>
> > Elliotte Rusty Harold
>
> > elh...@ibiblio.org
>
>
>
>
>
>
>
> --
>
> Elliotte Rusty Harold
>
> elh...@ibiblio.org
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

[Karl Heinz Marbaise]

Hi,

+1 from me (binding)

Kind regards
Karl Heinz Marbaise
On 17.08.20 16:44, Elliotte Rusty Harold wrote:

Ping. Can I get two more +1's on this? Once this is out, we'll be
ready to release a new maven-dependency-plugin that reintroduces the
verbose option for dependency:tree for the first time since Maven 2.

On Mon, Aug 10, 2020 at 10:19 AM Elliotte Rusty Harold
 wrote:


Let's try this one more time. I updated Jira and regenerated the
release notes. Nothing else has changed:

Hi,

We solved 3 issues:

[MSHARED-949] - dependency:analyze should recommend narrower scope
where possible
[MSHARED-948] - Update link to Jira
[MSHARED-932] - Remove JMock dependency

There are still five issues left in JIRA:
https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer


Staging repo:
https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip

Source release checksum(s):
maven-dependency-analyzer-1.11.3-source-release.zip sha512:
84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8

Staging site:
https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


On Wed, Aug 5, 2020 at 4:31 PM Elliotte Rusty Harold  wrote:


Hi,

We solved 2 issues:
 * [MSHARED-932] Remove JMock dependency
 * [MDEP-708] dependency:analyze should recommend narrower scope
where possible

There are still five issues left in JIRA:
https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer


Staging repo:
https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip

Source release checksum(s):
maven-dependency-analyzer-1.11.3-source-release.zip sha512:
84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8

Staging site:
https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


--
Elliotte Rusty Harold
elh...@ibiblio.org




--
Elliotte Rusty Harold
elh...@ibiblio.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

[Elliotte Rusty Harold]

Ping. Can I get two more +1's on this? Once this is out, we'll be
ready to release a new maven-dependency-plugin that reintroduces the
verbose option for dependency:tree for the first time since Maven 2.

On Mon, Aug 10, 2020 at 10:19 AM Elliotte Rusty Harold
 wrote:
>
> Let's try this one more time. I updated Jira and regenerated the
> release notes. Nothing else has changed:
>
> Hi,
>
> We solved 3 issues:
>
> [MSHARED-949] - dependency:analyze should recommend narrower scope
> where possible
> [MSHARED-948] - Update link to Jira
> [MSHARED-932] - Remove JMock dependency
>
> There are still five issues left in JIRA:
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> On Wed, Aug 5, 2020 at 4:31 PM Elliotte Rusty Harold  
> wrote:
> >
> > Hi,
> >
> > We solved 2 issues:
> > * [MSHARED-932] Remove JMock dependency
> > * [MDEP-708] dependency:analyze should recommend narrower scope
> > where possible
> >
> > There are still five issues left in JIRA:
> > https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> > https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
> >
> > Source release checksum(s):
> > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> > 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
> >
> > Staging site:
> > https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Martin,

I don't understand your question.

You posted the Javadocs, and they tell it clearly: "A test for which an
assumption fails should NOT generate a test case failure.".

Also Assume's Javadocs
(https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
clear about it: "... A failed assumption does NOT mean the code is broken,
but that the test provides no useful information. Assume basically means
"don't RUN this test if these conditions don't apply". The default JUnit
runner SKIPS tests with failing assumptions..."

So do you really want me to ask the JUnit people whether they really MEAN
what they clearly wrote...?

-Markus

-Ursprüngliche Nachricht-
Von: Martin Gainty [mailto:mgai...@hotmail.com] 
Gesendet: Montag, 17. August 2020 12:27
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!


   /**
 * Call to assume that actual satisfies the condition
specified by matcher.
 * If not, the test halts and is ignored.
 * Example:
 * :
 *   assumeThat(1, is(1)); // passes
 *   foo(); // will execute
 *   assumeThat(0, is(1)); // assumption failure! test halts
 *   int x = 1 / 0; // will never execute
 * 
 *
 * @param  the static type accepted by the matcher (this can flag
obvious compile-time problems such as {@code assumeThat(1, is("a"))}
 * @param actual the computed value being compared
 * @param matcher an expression, built of {@link Matcher}s, specifying
allowed values
 * @see org.hamcrest.CoreMatchers
 * @see org.junit.matchers.JUnitMatchers
 */
public static  void assumeThat(T actual, Matcher matcher) {
if (!matcher.matches(actual)) {
throw new AssumptionViolatedException(actual, matcher);
}
}

//does AssumptionViolatedException ever produce test case failure?

/**
 * An exception class used to implement assumptions (state in which a
given test
 * is meaningful and should or should not be executed). A test for which an
assumption
 * fails should not generate a test case failure.
 *
 * @see org.junit.Assume
 * @since 4.12
 */
@SuppressWarnings("deprecation")
public class AssumptionViolatedException extends
org.junit.internal.AssumptionViolatedException {
private static final long serialVersionUID = 1L;

/**
 * An assumption exception with the given actual value and a
matcher describing
 * the expectation that failed.
 */
public  AssumptionViolatedException(T actual, Matcher matcher) {
super(actual, matcher);
}

/**
 * An assumption exception with a message with the given actual
value and a
 * matcher describing the expectation that failed.
 */
public  AssumptionViolatedException(String message, T expected,
Matcher matcher) {
super(message, expected, matcher);
}

/**
 * An assumption exception with the given message only.
 */
public AssumptionViolatedException(String message) {
super(message);
}

/**
 * An assumption exception with the given message and a cause.
 */
public AssumptionViolatedException(String assumption, Throwable t) {
super(assumption, t);
}
}

//will base class throw FAILURE for TestCase?
/**
 * An exception class used to implement assumptions (state in which a
given test
 * is meaningful and should or should not be executed). A test for which an
assumption
 * fails should not generate a test case failure.
 *
 * @see org.junit.Assume
 */
public class AssumptionViolatedException extends RuntimeException implements
SelfDescribing {
private static final long serialVersionUID = 2L;

/*
 * We have to use the f prefix until the next major release to ensure
 * serialization compatibility.
 * See https://github.com/junit-team/junit/issues/976
 */
private final String fAssumption;
private final boolean fValueMatcher;
private final Object fValue;
private final Matcher fMatcher;

/**
 * @deprecated Please use {@link org.junit.AssumptionViolatedException}
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, boolean hasValue,
Object value, Matcher matcher) {
this.fAssumption = assumption;
this.fValue = value;
this.fMatcher = matcher;
this.fValueMatcher = hasValue;

if (value instanceof Throwable) {
  initCause((Throwable) value);
}
}

/**
 * An assumption exception with the given value (String or
 * Throwable) and an additional failing {@link Matcher}.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException}
instead.
 */
@Deprecated
public AssumptionViolatedException(Object value, Matcher matcher) {
this(null, true, value, matcher);
}

/**
 * An assumption exception with the given value (String or
 * Throwable) and an additional failing {@link Matcher}.
 *
 * @deprecated Please use {@link 

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

So the bug is that Maven Dependency Plugin's test suite uses the JUnit 4 
library for test-compile, but actually executes the tests using JUnit 3, right?

-Markus


-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 14:09
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

Yes Piotr, this is another example why Markus has these unpleasant
experiences with JUnit3.
The code with JUnit4 annotation should be fine.

On Mon, Aug 17, 2020 at 1:34 PM Piotr Żygieło 
wrote:

> Please note, that TestCopyMojo is considered as JUnit3 TestCase
> (
> https://github.com/junit-team/junit4/blob/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8/src/main/java/org/junit/internal/builders/JUnit3Builder.java#L17
> ).
> So perhaps JUnit4+ features are not to be expected in such a case?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Just to make clear: *I* did not add *anything* to make it go wrong -- I just 
execute the existing Maven Dependency Plugin's test suite into which I added an 
assumption. Neither did I write that plugin nor its tests nor its POM. Just to 
clarify that.

-Markus


-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 13:27
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

yes it should be marked Skipped.
Many factors may turn this. As for instance I have these experiences with
Powermock which always fails the test in IntelliJ IDEA even if the
assumption fails.
Check it out with almost empty POM and a trivial test and compare the
outcome with the one you have attached. And then you will maybe see more.

@Test
public void test() {
 assumeTrue(false);
}

This code should work with JUnit 4.12 and whatever plugin version.
Turn this code to your specifics one by one and you will see what you have
added necessarily has changed the behavior.

T





On Sun, Aug 16, 2020 at 1:40 PM Markus KARG  wrote:

> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> [INFO]
>
> [ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0
>
>
>
> It seems maven treats JUnit assumptions just like JUnit exceptions! :-(
>
>
>
> Can someone tell my why that happens? Do I have to set some option tell
> Maven it shall SKIP instead of ERROR on failing assumptions?!
>
>
>
> Thanks in advance!
>
> -Markus Karg
>
>
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[MCHECKSTYLE] Request for merging PRs #17 and #28 please

[Benjamin Marwell]

Hi,

PRs #17 and #28 seem to be ready to be merged. They are also approved
by reviewers.
If they still look good, could they be merged? They are open for a while now.

* https://github.com/apache/maven-checkstyle-plugin/pull/17
* https://github.com/apache/maven-checkstyle-plugin/pull/28

Thanks!
Ben

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

Yes Piotr, this is another example why Markus has these unpleasant
experiences with JUnit3.
The code with JUnit4 annotation should be fine.

On Mon, Aug 17, 2020 at 1:34 PM Piotr Żygieło 
wrote:

> Please note, that TestCopyMojo is considered as JUnit3 TestCase
> (
> https://github.com/junit-team/junit4/blob/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8/src/main/java/org/junit/internal/builders/JUnit3Builder.java#L17
> ).
> So perhaps JUnit4+ features are not to be expected in such a case?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Assumption fail treated as unexcepted exception?!

[Piotr Żygieło]

Please note, that TestCopyMojo is considered as JUnit3 TestCase
(https://github.com/junit-team/junit4/blob/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8/src/main/java/org/junit/internal/builders/JUnit3Builder.java#L17).
So perhaps JUnit4+ features are not to be expected in such a case?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Assumption fail treated as unexcepted exception?!

[Tibor Digana]

yes it should be marked Skipped.
Many factors may turn this. As for instance I have these experiences with
Powermock which always fails the test in IntelliJ IDEA even if the
assumption fails.
Check it out with almost empty POM and a trivial test and compare the
outcome with the one you have attached. And then you will maybe see more.

@Test
public void test() {
 assumeTrue(false);
}

This code should work with JUnit 4.12 and whatever plugin version.
Turn this code to your specifics one by one and you will see what you have
added necessarily has changed the behavior.

T





On Sun, Aug 16, 2020 at 1:40 PM Markus KARG  wrote:

> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> [INFO]
>
> [ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0
>
>
>
> It seems maven treats JUnit assumptions just like JUnit exceptions! :-(
>
>
>
> Can someone tell my why that happens? Do I have to set some option tell
> Maven it shall SKIP instead of ERROR on failing assumptions?!
>
>
>
> Thanks in advance!
>
> -Markus Karg
>
>
>
>

Re: Assumption fail treated as unexcepted exception?!

[Martin Gainty]

   /**
 * Call to assume that actual satisfies the condition 
specified by matcher.
 * If not, the test halts and is ignored.
 * Example:
 * :
 *   assumeThat(1, is(1)); // passes
 *   foo(); // will execute
 *   assumeThat(0, is(1)); // assumption failure! test halts
 *   int x = 1 / 0; // will never execute
 * 
 *
 * @param  the static type accepted by the matcher (this can flag 
obvious compile-time problems such as {@code assumeThat(1, is("a"))}
 * @param actual the computed value being compared
 * @param matcher an expression, built of {@link Matcher}s, specifying 
allowed values
 * @see org.hamcrest.CoreMatchers
 * @see org.junit.matchers.JUnitMatchers
 */
public static  void assumeThat(T actual, Matcher matcher) {
if (!matcher.matches(actual)) {
throw new AssumptionViolatedException(actual, matcher);
}
}

//does AssumptionViolatedException ever produce test case failure?

/**
 * An exception class used to implement assumptions (state in which a 
given test
 * is meaningful and should or should not be executed). A test for which an 
assumption
 * fails should not generate a test case failure.
 *
 * @see org.junit.Assume
 * @since 4.12
 */
@SuppressWarnings("deprecation")
public class AssumptionViolatedException extends 
org.junit.internal.AssumptionViolatedException {
private static final long serialVersionUID = 1L;

/**
 * An assumption exception with the given actual value and a 
matcher describing
 * the expectation that failed.
 */
public  AssumptionViolatedException(T actual, Matcher matcher) {
super(actual, matcher);
}

/**
 * An assumption exception with a message with the given actual 
value and a
 * matcher describing the expectation that failed.
 */
public  AssumptionViolatedException(String message, T expected, 
Matcher matcher) {
super(message, expected, matcher);
}

/**
 * An assumption exception with the given message only.
 */
public AssumptionViolatedException(String message) {
super(message);
}

/**
 * An assumption exception with the given message and a cause.
 */
public AssumptionViolatedException(String assumption, Throwable t) {
super(assumption, t);
}
}

//will base class throw FAILURE for TestCase?
/**
 * An exception class used to implement assumptions (state in which a 
given test
 * is meaningful and should or should not be executed). A test for which an 
assumption
 * fails should not generate a test case failure.
 *
 * @see org.junit.Assume
 */
public class AssumptionViolatedException extends RuntimeException implements 
SelfDescribing {
private static final long serialVersionUID = 2L;

/*
 * We have to use the f prefix until the next major release to ensure
 * serialization compatibility.
 * See https://github.com/junit-team/junit/issues/976
 */
private final String fAssumption;
private final boolean fValueMatcher;
private final Object fValue;
private final Matcher fMatcher;

/**
 * @deprecated Please use {@link org.junit.AssumptionViolatedException} 
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, boolean hasValue, 
Object value, Matcher matcher) {
this.fAssumption = assumption;
this.fValue = value;
this.fMatcher = matcher;
this.fValueMatcher = hasValue;

if (value instanceof Throwable) {
  initCause((Throwable) value);
}
}

/**
 * An assumption exception with the given value (String or
 * Throwable) and an additional failing {@link Matcher}.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException} 
instead.
 */
@Deprecated
public AssumptionViolatedException(Object value, Matcher matcher) {
this(null, true, value, matcher);
}

/**
 * An assumption exception with the given value (String or
 * Throwable) and an additional failing {@link Matcher}.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException} 
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, Object value, 
Matcher matcher) {
this(assumption, true, value, matcher);
}

/**
 * An assumption exception with the given message only.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException} 
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption) {
this(assumption, false, null, null);
}

/**
 * An assumption exception with the given message and a cause.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException} 
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, Throwable e) {
this(assumption, false, null, null);
initCause(e);
}

  

Re: Fwd: Maven builds out of control

[Arnaud Héritier]

No I agree, it's a long term solution and orthogonal on cleaning our
branches/builds and limiting our usages

If these are static agents the best we could do at the CI level is to
restrict the usage of our builds to a limited number of agents
https://docs.cloudbees.com/docs/cloudbees-ci/latest/traditional-secure-guide/folders-plus#_controlled_agents


On Mon, Aug 17, 2020 at 10:55 AM Olivier Lamy  wrote:

> traditional slaves
> I have a goal to help moving to kubernetes but this will not fix this
> problem :)
>
>
> On Mon, 17 Aug 2020 at 16:46, Arnaud Héritier  wrote:
>
> > Thanks for the feedback Gavin, it makes a lot of sense to me.
> > The new infrastructure is a traditional one (ie not hosted on
> Kubernetes) ?
> >
> > On Mon, Aug 17, 2020 at 10:44 AM Gavin McDonald 
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, Aug 17, 2020 at 10:35 AM Olivier Lamy 
> wrote:
> > >
> > > > +infra
> > > >
> > > > On Mon, 17 Aug 2020 at 4:23 pm, Arnaud Héritier  >
> > > > wrote:
> > > >
> > > >> If we are consuming too much resources couldn't we have a dedicated
> > > >> Jenkins
> > > >>
> > > >> controller and/or limit our agents capacities to be the one ones to
> be
> > > >>
> > > >> impacted by these problems instead of all the users or this Jenkins
> > > >>
> > > >> controller ?
> > > >>
> > > >> Beam, Cassandra, CouchDB and few more have a dedicated controller :
> > > >>
> > > >> https://jenkins-ccos.apache.org/job/masters/
> > > >>
> > > >> What are the rules to have a dedicated one ?
> > > >>
> > > >
> > > All of those projects got their own master as they are contributing
> their
> > > own nodes and not using the ASF provided ones
> > >
> > > HTH
> > >
> > >
> > > >
> > > >>
> > > >>
> > > >> On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov <
> micha...@apache.org>
> > > >> wrote:
> > > >>
> > > >>
> > > >>
> > > >> > Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> > > >>
> > > >> > > Furthermore, we need to clean up unused branches.
> > > >>
> > > >> > > What about removing branches older than 1yo?
> > > >>
> > > >> > > Then older than 6months?
> > > >>
> > > >> >
> > > >>
> > > >> > I consider branches which have been merged obsolete, but there is
> no
> > > >>
> > > >> > hard rule that an unmerged branch is obsolete. It may prepresent
> an
> > > >>
> > > >> > unfished state or something which was not agreed on. Dropping work
> > > does
> > > >>
> > > >> > not feel right. It needs to be decided on a case-by-case approach.
> > > >>
> > > >> > I have done this recently for Wagon and Resolver.
> > > >>
> > > >> >
> > > >>
> > > >> > Michael
> > > >>
> > > >> >
> > > >>
> > > >> >
> > -
> > > >>
> > > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>
> > > >> > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>
> > > >> >
> > > >>
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Arnaud Héritier
> > > >>
> > > >> Twitter/Skype : aheritier
> > > >>
> > > >> --
> > > > Olivier Lamy
> > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >
> > >
> > >
> > > --
> > >
> > > *Gavin McDonald*
> > > Systems Administrator
> > > ASF Infrastructure Team
> > >
> >
> >
> > --
> > Arnaud Héritier
> > Twitter/Skype : aheritier
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: Fwd: Maven builds out of control

[Olivier Lamy]

traditional slaves
I have a goal to help moving to kubernetes but this will not fix this
problem :)


On Mon, 17 Aug 2020 at 16:46, Arnaud Héritier  wrote:

> Thanks for the feedback Gavin, it makes a lot of sense to me.
> The new infrastructure is a traditional one (ie not hosted on Kubernetes) ?
>
> On Mon, Aug 17, 2020 at 10:44 AM Gavin McDonald 
> wrote:
>
> > Hi,
> >
> > On Mon, Aug 17, 2020 at 10:35 AM Olivier Lamy  wrote:
> >
> > > +infra
> > >
> > > On Mon, 17 Aug 2020 at 4:23 pm, Arnaud Héritier 
> > > wrote:
> > >
> > >> If we are consuming too much resources couldn't we have a dedicated
> > >> Jenkins
> > >>
> > >> controller and/or limit our agents capacities to be the one ones to be
> > >>
> > >> impacted by these problems instead of all the users or this Jenkins
> > >>
> > >> controller ?
> > >>
> > >> Beam, Cassandra, CouchDB and few more have a dedicated controller :
> > >>
> > >> https://jenkins-ccos.apache.org/job/masters/
> > >>
> > >> What are the rules to have a dedicated one ?
> > >>
> > >
> > All of those projects got their own master as they are contributing their
> > own nodes and not using the ASF provided ones
> >
> > HTH
> >
> >
> > >
> > >>
> > >>
> > >> On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov 
> > >> wrote:
> > >>
> > >>
> > >>
> > >> > Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> > >>
> > >> > > Furthermore, we need to clean up unused branches.
> > >>
> > >> > > What about removing branches older than 1yo?
> > >>
> > >> > > Then older than 6months?
> > >>
> > >> >
> > >>
> > >> > I consider branches which have been merged obsolete, but there is no
> > >>
> > >> > hard rule that an unmerged branch is obsolete. It may prepresent an
> > >>
> > >> > unfished state or something which was not agreed on. Dropping work
> > does
> > >>
> > >> > not feel right. It needs to be decided on a case-by-case approach.
> > >>
> > >> > I have done this recently for Wagon and Resolver.
> > >>
> > >> >
> > >>
> > >> > Michael
> > >>
> > >> >
> > >>
> > >> >
> -
> > >>
> > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>
> > >> > For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >> >
> > >>
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Arnaud Héritier
> > >>
> > >> Twitter/Skype : aheritier
> > >>
> > >> --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
> >
> > --
> >
> > *Gavin McDonald*
> > Systems Administrator
> > ASF Infrastructure Team
> >
>
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Fwd: Maven builds out of control

[Arnaud Héritier]

Thanks for the feedback Gavin, it makes a lot of sense to me.
The new infrastructure is a traditional one (ie not hosted on Kubernetes) ?

On Mon, Aug 17, 2020 at 10:44 AM Gavin McDonald 
wrote:

> Hi,
>
> On Mon, Aug 17, 2020 at 10:35 AM Olivier Lamy  wrote:
>
> > +infra
> >
> > On Mon, 17 Aug 2020 at 4:23 pm, Arnaud Héritier 
> > wrote:
> >
> >> If we are consuming too much resources couldn't we have a dedicated
> >> Jenkins
> >>
> >> controller and/or limit our agents capacities to be the one ones to be
> >>
> >> impacted by these problems instead of all the users or this Jenkins
> >>
> >> controller ?
> >>
> >> Beam, Cassandra, CouchDB and few more have a dedicated controller :
> >>
> >> https://jenkins-ccos.apache.org/job/masters/
> >>
> >> What are the rules to have a dedicated one ?
> >>
> >
> All of those projects got their own master as they are contributing their
> own nodes and not using the ASF provided ones
>
> HTH
>
>
> >
> >>
> >>
> >> On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov 
> >> wrote:
> >>
> >>
> >>
> >> > Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> >>
> >> > > Furthermore, we need to clean up unused branches.
> >>
> >> > > What about removing branches older than 1yo?
> >>
> >> > > Then older than 6months?
> >>
> >> >
> >>
> >> > I consider branches which have been merged obsolete, but there is no
> >>
> >> > hard rule that an unmerged branch is obsolete. It may prepresent an
> >>
> >> > unfished state or something which was not agreed on. Dropping work
> does
> >>
> >> > not feel right. It needs to be decided on a case-by-case approach.
> >>
> >> > I have done this recently for Wagon and Resolver.
> >>
> >> >
> >>
> >> > Michael
> >>
> >> >
> >>
> >> > -
> >>
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> >
> >>
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Arnaud Héritier
> >>
> >> Twitter/Skype : aheritier
> >>
> >> --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>
>
> --
>
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>


-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: Fwd: Maven builds out of control

[Olivier Lamy]

Yes, we can limit branches using regex.
if use @dependabot merge the branch is deleted


On Mon, 17 Aug 2020 at 16:41, Maarten Mulders  wrote:

> On 17/08/2020 09:55, Olivier Lamy wrote:
> > Hi there
> > we definitely need to reduce the matrix we have and cleanup branches ...
> > so I reduced the matrix (no more 14,15)
> > and only '3.3.x','3.6.x'
> >
> > Furthermore, we need to clean up unused branches.
> > What about removing branches older than 1yo?
> > Then older than 6months?
>
> Nowadays there are a lot of branches created by Dependabot.
> I think it's good to update dependencies more frequently than we
> currently do. But we shouldn't be building all those branches on Jenkins
> immediately, and without (human) review. There's a risk of unreviewed
> code being ran on Jenkins. Also, as we can see from this situation, it
> creates so many branches that are never cleaned up.
>
> If there would be a way to prevent those branches being built, that
> would definitely save space in the build queue. All branches start with
> dependabot/, but I haven't found a way yet to filter those out.
>
> Thanks,
>
> Maarten
>
> > -- Forwarded message -
> > From: Richard Eckart de Castilho 
> > Date: Mon, 17 Aug 2020 at 15:37
> > Subject: Re: Maven builds out of control
> > To: 
> >
> >
> > Dear Maven developers,
> >
> > please fix or disable your CI builds ... other people need to use the
> > servers as well and in particular those who need to test jobs as part of
> > their job migration.
> >
> > @INFRA: Maybe confine all Maven Jobs to a single specific slave for the
> > time being? That way, they only starve themselves.
> >
> > Cheers,
> >
> > -- Richard
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Fwd: Maven builds out of control

[Gavin McDonald]

Hi,

On Mon, Aug 17, 2020 at 10:35 AM Olivier Lamy  wrote:

> +infra
>
> On Mon, 17 Aug 2020 at 4:23 pm, Arnaud Héritier 
> wrote:
>
>> If we are consuming too much resources couldn't we have a dedicated
>> Jenkins
>>
>> controller and/or limit our agents capacities to be the one ones to be
>>
>> impacted by these problems instead of all the users or this Jenkins
>>
>> controller ?
>>
>> Beam, Cassandra, CouchDB and few more have a dedicated controller :
>>
>> https://jenkins-ccos.apache.org/job/masters/
>>
>> What are the rules to have a dedicated one ?
>>
>
All of those projects got their own master as they are contributing their
own nodes and not using the ASF provided ones

HTH


>
>>
>>
>> On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov 
>> wrote:
>>
>>
>>
>> > Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
>>
>> > > Furthermore, we need to clean up unused branches.
>>
>> > > What about removing branches older than 1yo?
>>
>> > > Then older than 6months?
>>
>> >
>>
>> > I consider branches which have been merged obsolete, but there is no
>>
>> > hard rule that an unmerged branch is obsolete. It may prepresent an
>>
>> > unfished state or something which was not agreed on. Dropping work does
>>
>> > not feel right. It needs to be decided on a case-by-case approach.
>>
>> > I have done this recently for Wagon and Resolver.
>>
>> >
>>
>> > Michael
>>
>> >
>>
>> > -
>>
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> >
>>
>> >
>>
>>
>>
>> --
>>
>> Arnaud Héritier
>>
>> Twitter/Skype : aheritier
>>
>> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


-- 

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team

Re: Maven builds out of control

[Christofer Dutz]

Hi all,

Well you could probably self-limit your builds.

I know that when using Jenkinsfiles you can define tags for nodes the build 
runs on.
So you could probably limit these to a hand full of "H??" nodes and it should 
not use up all of the resources.

Chris

Am 17.08.20, 10:23 schrieb "Arnaud Héritier" :

If we are consuming too much resources couldn't we have a dedicated Jenkins
controller and/or limit our agents capacities to be the one ones to be
impacted by these problems instead of all the users or this Jenkins
controller ?
Beam, Cassandra, CouchDB and few more have a dedicated controller :
https://jenkins-ccos.apache.org/job/masters/
What are the rules to have a dedicated one ?

On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov  wrote:

> Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> > Furthermore, we need to clean up unused branches.
> > What about removing branches older than 1yo?
> > Then older than 6months?
>
> I consider branches which have been merged obsolete, but there is no
> hard rule that an unmerged branch is obsolete. It may prepresent an
> unfished state or something which was not agreed on. Dropping work does
> not feel right. It needs to be decided on a case-by-case approach.
> I have done this recently for Wagon and Resolver.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: Fwd: Maven builds out of control

[Maarten Mulders]

On 17/08/2020 09:55, Olivier Lamy wrote:

Hi there
we definitely need to reduce the matrix we have and cleanup branches ...
so I reduced the matrix (no more 14,15)
and only '3.3.x','3.6.x'

Furthermore, we need to clean up unused branches.
What about removing branches older than 1yo?
Then older than 6months?


Nowadays there are a lot of branches created by Dependabot.
I think it's good to update dependencies more frequently than we 
currently do. But we shouldn't be building all those branches on Jenkins 
immediately, and without (human) review. There's a risk of unreviewed 
code being ran on Jenkins. Also, as we can see from this situation, it 
creates so many branches that are never cleaned up.


If there would be a way to prevent those branches being built, that 
would definitely save space in the build queue. All branches start with 
dependabot/, but I haven't found a way yet to filter those out.


Thanks,

Maarten


-- Forwarded message -
From: Richard Eckart de Castilho 
Date: Mon, 17 Aug 2020 at 15:37
Subject: Re: Maven builds out of control
To: 


Dear Maven developers,

please fix or disable your CI builds ... other people need to use the
servers as well and in particular those who need to test jobs as part of
their job migration.

@INFRA: Maybe confine all Maven Jobs to a single specific slave for the
time being? That way, they only starve themselves.

Cheers,

-- Richard




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Fwd: Maven builds out of control

[Olivier Lamy]

+infra

On Mon, 17 Aug 2020 at 4:23 pm, Arnaud Héritier  wrote:

> If we are consuming too much resources couldn't we have a dedicated Jenkins
>
> controller and/or limit our agents capacities to be the one ones to be
>
> impacted by these problems instead of all the users or this Jenkins
>
> controller ?
>
> Beam, Cassandra, CouchDB and few more have a dedicated controller :
>
> https://jenkins-ccos.apache.org/job/masters/
>
> What are the rules to have a dedicated one ?
>
>
>
> On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov 
> wrote:
>
>
>
> > Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
>
> > > Furthermore, we need to clean up unused branches.
>
> > > What about removing branches older than 1yo?
>
> > > Then older than 6months?
>
> >
>
> > I consider branches which have been merged obsolete, but there is no
>
> > hard rule that an unmerged branch is obsolete. It may prepresent an
>
> > unfished state or something which was not agreed on. Dropping work does
>
> > not feel right. It needs to be decided on a case-by-case approach.
>
> > I have done this recently for Wagon and Resolver.
>
> >
>
> > Michael
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
> >
>
>
>
> --
>
> Arnaud Héritier
>
> Twitter/Skype : aheritier
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Fwd: Maven builds out of control

[Arnaud Héritier]

If we are consuming too much resources couldn't we have a dedicated Jenkins
controller and/or limit our agents capacities to be the one ones to be
impacted by these problems instead of all the users or this Jenkins
controller ?
Beam, Cassandra, CouchDB and few more have a dedicated controller :
https://jenkins-ccos.apache.org/job/masters/
What are the rules to have a dedicated one ?

On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov  wrote:

> Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> > Furthermore, we need to clean up unused branches.
> > What about removing branches older than 1yo?
> > Then older than 6months?
>
> I consider branches which have been merged obsolete, but there is no
> hard rule that an unmerged branch is obsolete. It may prepresent an
> unfished state or something which was not agreed on. Dropping work does
> not feel right. It needs to be decided on a case-by-case approach.
> I have done this recently for Wagon and Resolver.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: Fwd: Maven builds out of control

[Michael Osipov]

Am 2020-08-17 um 09:55 schrieb Olivier Lamy:

Furthermore, we need to clean up unused branches.
What about removing branches older than 1yo?
Then older than 6months?


I consider branches which have been merged obsolete, but there is no 
hard rule that an unmerged branch is obsolete. It may prepresent an 
unfished state or something which was not agreed on. Dropping work does 
not feel right. It needs to be decided on a case-by-case approach.

I have done this recently for Wagon and Resolver.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Fwd: Maven builds out of control

[Olivier Lamy]

Hi there
we definitely need to reduce the matrix we have and cleanup branches ...
so I reduced the matrix (no more 14,15)
and only '3.3.x','3.6.x'

Furthermore, we need to clean up unused branches.
What about removing branches older than 1yo?
Then older than 6months?


-- Forwarded message -
From: Richard Eckart de Castilho 
Date: Mon, 17 Aug 2020 at 15:37
Subject: Re: Maven builds out of control
To: 


Dear Maven developers,

please fix or disable your CI builds ... other people need to use the
servers as well and in particular those who need to test jobs as part of
their job migration.

@INFRA: Maybe confine all Maven Jobs to a single specific slave for the
time being? That way, they only starve themselves.

Cheers,

-- Richard


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy