Re: Assumption fail treated as unexcepted exception?!

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

MEAR-280 and skinnyWar option

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

Re: Assumption fail treated as unexcepted exception?!

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

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

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

Re: Assumption fail treated as unexcepted exception?!

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

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

+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

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

+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,

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

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

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

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

AW: Assumption fail treated as unexcepted exception?!

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

AW: Assumption fail treated as unexcepted exception?!

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:

AW: Assumption fail treated as unexcepted exception?!

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-

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

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!

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 > ( >

Re: Assumption fail treated as unexcepted exception?!

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?

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

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

Re: Fwd: Maven builds out of control

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

Re: Fwd: Maven builds out of control

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

Re: Fwd: Maven builds out of control

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

Re: Fwd: Maven builds out of control

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

Re: Fwd: Maven builds out of control

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

Re: Maven builds out of control

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

Re: Fwd: Maven builds out of control

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

Re: Fwd: Maven builds out of control

+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 > >

Re: Fwd: Maven builds out of control

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 :

Re: Fwd: Maven builds out of control

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

Fwd: Maven builds out of control

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