date:20200818

Re: Why is old IO API used in maven resolver?

2020-08-18 Thread STEFAN REICH

@Oliver: thanks, I’ll go ahead and test the proposed changes on our build this 
week. The performance benefit is expected to differ on various OS, but I don’t 
have benchmark results for them.

@Xeno: The two results I quoted are what you are asking for. resolverCopy is 
testing the current implementation and transferTo the new one. The existing 
code can copy the file 5.443 times a second, the proposed fix can perform 8.838 
copies per second.

@Michael: ACK

Thanks for your support!
Stefan

On 2020/08/16 04:40:11, STEFAN REICH  wrote: 
> Hi there!> 
> 
> I am working on a very large code base, and build performance issues made me 
> look at the maven-resolver source code. In terms of File usages, there are a 
> lot of InputStreams being copied around using ByteBuffer, instead of using 
> FileChannel.transferTo. Affected classes are DefaultFileProcessor, 
> ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially 
> more. Was it a conscious decision to use this pattern over the more efficient 
> transferTo? Would you accept a PR with more modern NIO API that still works 
> with JDK 7?> 
> 
> Here are the throughput results from a JMH benchmark, copying a 22MB file 
> around using the pattern currently used in maven, and transferTo, as measured 
> on macOS with JDK 11 on an SSD.> 
> 
> Result "MyBenchmark.resolverCopy":> 
>   291.362 ±(99.9%) 5.443 ops/s [Average]> 
>   (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266> 
>   CI (99.9%): [285.919, 296.804] (assumes normal distribution)> 
> 
> Result "MyBenchmark.transferTo":> 
>   325.188 ±(99.9%) 8.838 ops/s [Average]> 
>   (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799> 
>   CI (99.9%): [316.350, 334.026] (assumes normal distribution)> 
> 
> 
> Thanks!> 
> Stefan> 
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Shade plugin using the wrong project while building the dependency reduced pom in parallel builds

2020-08-18 Thread Emma Holmberg Ohlsson

Hi,

After encountering the issue in
https://issues.apache.org/jira/browse/MSHADE-148 (version 3.3.0 of the
shade plugin and 3.6.0 of Maven)  I ended up in a long debugging session
trying to reproduce the scenario.

What I found is that in ShadeMojo.java
(rewriteDependencyReducedPomIfWeHaveReduction)


ProjectBuildingRequest projectBuildingRequest =

new DefaultProjectBuildingRequest( session.getProjectBuildingRequest() );


will return a different project than the one that is currently processed by
the shading plugin when executing maven with --threads.

updateExcludesInDeps will build a dependency graph on one project but the
exclusions will be added to a different project.

We end up in an infinite loop in
rewriteDependencyReducedPomIfWeHaveReduction since the same exclusions will
be added over and over again.


How is session.getProjectBuildingRequest() supposed to work in parallel
builds?

Is this by design, is the shade plugin using it wrong or is it a bug in
maven-core?


Thanks in advance!

Emma Holmberg Ohlsson

Re: Assumption fail treated as unexcepted exception?!

2020-08-18 Thread Martin Gainty

MG>below

From: Markus KARG 
Sent: Tuesday, August 18, 2020 8:28 AM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

Martin,

sorry was busy otherwise, had no time to check with JUnit 4. Will try ASAP and 
report here.

In fact I do not understand what you want me to ask the JUnit authors. I do not 
want to use JUnit 3 at all (I did not actively decide for any version), so if 
there is something to ask them, please tell me *what*?
MG>we need to understand if the statement if Junit AssumptionViolatedException 
is thrown
MG>the intended behaviour is to NOT fail the testcase that wraps 
AssumptionViolatedException 
MG>AssumptionViolatedException source is displayed below

package org.junit;

import org.hamcrest.Matcher;

/**
 * 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);
}
}

MG>if the above junit statement is true then when you throw 
AssumptionViolatedException
MG>the testcase that wraps AssumptionViolatedException  should 
NOT FAIL the testcase
MG>If true I will admit this junit behaviour seems counter-intuitive
MG>thanks
MG>martin

thanks
-Markus

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

have you tried with junit4?

if you need to stick with older junit then you can implement your 
AssumptionViolatedException to extend BuildFailureException

any feedback from junit author on this behaviour?

gruss
~martin~

From: Markus KARG 
Sent: Monday, August 17, 2020 1:53 PM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

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

Re: Your project website

2020-08-18 Thread Andrew Wetmore

Hi:

I wrote to you two weeks ago about your project website, but have not seen
a response. Whom should I contact directly? I am trying to see whether your
project still uses the Apache CMS and, if so, what your plans are to
migrate off it.

Thanks in advance for your help.

Andrew

On Wed, Aug 5, 2020 at 9:35 AM Andrew Wetmore  wrote:

> Hi:
>
> I am part of the Infrastructure team, and am writing to ask whether your
> project is still using the Apache CMS for your project website. As you
> know, the CMS is reaching end-of-life, and we need projects to move their
> websites onto a different option within the next few weeks.
>
> There are several alternatives available, including those listed on this
> page [1] on managing project websites. Infra is assembling a Wiki page [2]
> on migrating a website from the CMS, and is looking forward to helping
> projects with this transition.
>
> Please let me know whether your site is still on the Apache CMS and, if
> so, who will be the project point-of-contact with Infra for the migration.
>
> Thank you!
>
>
>
>
> [1] https://infra.apache.org/project-site.html
>
> [2]
> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
>
>
> --
> Andrew Wetmore
> Technical Writer-Editor
> Infra
> *Apache Software Foundation*
> andr...@apache.org
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_1277653308293069744_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>


-- 
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org

AW: Assumption fail treated as unexcepted exception?!

2020-08-18 Thread Markus KARG

Martin,

sorry was busy otherwise, had no time to check with JUnit 4. Will try ASAP and 
report here.

In fact I do not understand what you want me to ask the JUnit authors. I do not 
want to use JUnit 3 at all (I did not actively decide for any version), so if 
there is something to ask them, please tell me *what*?

thanks
-Markus


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

have you tried with junit4?

if you need to stick with older junit then you can implement your 
AssumptionViolatedException to extend BuildFailureException

any feedback from junit author on this behaviour?

gruss
~martin~



From: Markus KARG 
Sent: Monday, August 17, 2020 1:53 PM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

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 g

Re: Assumption fail treated as unexcepted exception?!

2020-08-18 Thread Romain Manni-Bucau

Think the answer had been written already but in case it is not clear - it
looks at least to me: it works as expected.
JUnit 3 does not support assumptions - even when executed with JUnit 4
launcher - exactly as JUnt Jupiter mimics JUnit 4 behavior when
executed with vintage engine.
Assumptions are JUnit >= 4.4 so if you want to use an assumption write a
JUnit 4 test and not a JUnit 3 one.

Hope it helps.
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 18 août 2020 à 13:59, Martin Gainty  a écrit :

> have you tried with junit4?
>
> if you need to stick with older junit then you can implement your
> AssumptionViolatedException to extend BuildFailureException
>
> any feedback from junit author on this behaviour?
>
> gruss
> ~martin~
>
>
> 
> From: Markus KARG 
> Sent: Monday, August 17, 2020 1:53 PM
> To: 'Maven Developers List' 
> Subject: AW: Assumption fail treated as unexcepted exception?!
>
> 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

Re: Assumption fail treated as unexcepted exception?!

2020-08-18 Thread Martin Gainty

have you tried with junit4?

if you need to stick with older junit then you can implement your 
AssumptionViolatedException to extend BuildFailureException

any feedback from junit author on this behaviour?

gruss
~martin~



From: Markus KARG 
Sent: Monday, August 17, 2020 1:53 PM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

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);
>>

Re: maven-script-interpreter next version - please help

2020-08-18 Thread Slawomir Jaranowski

Hi,
I would kindly remind
There are anybody who can and want help me in
release maven-script-interpreter

sob., 25 lip 2020 o 10:35 Slawomir Jaranowski 
napisał(a):

> Hi,
>
> I made changes to maven-script-interpreter which will resolve some issues
> in invoker plugin.
>
> Last my changes brake compatibility, so next version should be: *2.0*
> according to semVer
>
> Here is a list of change:
> https://issues.apache.org/jira/projects/MSHARED/versions/12341132
>
> And the last PR for this release:
> https://issues.apache.org/jira/browse/MSHARED-939
>
> There is anybody, who can help in release - maven-script-interpreter?
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: Why is old IO API used in maven resolver?

Shade plugin using the wrong project while building the dependency reduced pom in parallel builds

Re: Assumption fail treated as unexcepted exception?!

Re: Your project website

AW: Assumption fail treated as unexcepted exception?!

Re: Assumption fail treated as unexcepted exception?!

Re: Assumption fail treated as unexcepted exception?!

Re: maven-script-interpreter next version - please help

8 matches

Site Navigation

Mail list logo

Footer information