[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] commented on pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49#issuecomment-958970536 Superseded by #50. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] closed pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] closed pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] commented on pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49#issuecomment-958970536 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] closed pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] closed pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire - multiple tests framework on classpath
Usually you will endup with one engine and one or more test APIs. The documentation above solves all combinations with junit4, junit5 and testng. If somebody uses one @Test annotation and wants to say that f/w1 should run test class 1 but f/w2 should run test class 2, then the plugin should be configured with two executions within one phase default-test. I don't think we should rewrap entire plugin config params per provider since it can be solved with Maven's in POM. T On Wed, Nov 3, 2021 at 6:22 PM Slawomir Jaranowski wrote: > Hi, > > I understand the difference between framework and providers. > I also know that we can add specific providers as dependency to the plugin > and in the result we have manually selected providers. > > When we don't configure any dependency the provider is chosen automatically > depending on what we have on classpath, what framework. > > eg. When we have on classpath junit4 and junit5, but without junit5 vintage > - junit4 tests are silently skipped. > > In most cases in the project we use one testing framework so > automatically choosing one provider is ok. > > When we use more that one framework it is probably during migration, so we > should define proper dependency. > It is ok when we have control on what we do in a project, but there are > some situations when we can make mistakes, like > - user add second testing framework and forgot about configuration > - we change project dependency and in transitive dependency we got next > testing framework > > So I want to mitigate the risk of skipped tests by warning / failing that > we have many frameworks and automatically provider selection takes place. > > We can also try to choose many providers (not one) automatically, but I > think it will be more complicated and in standard usage is not needed. > For automatic detection we have many corner cases, like testng + junit4 - > testng by default runs junit4 tests, so without special configuration for > testng we run some of the tests twice. > > > śr., 3 lis 2021 o 15:09 Tibor Digana napisał(a): > > > Hi Slawomir, > > > > The reality is different. > > It's not the frameworks but providers. > > So the plugin iterates over providers. > > You may choose whether you will define the provider artifacts in plugin > > deps or you let the plugin to select the providers upon dependencies > which > > means that there is some logic and JUnit5 deps may activate one provider > > for both the junit4 and 5. > > > > T > > > > On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski < > s.jaranow...@gmail.com > > > > > wrote: > > > > > Hi, > > > > > > When multiple test frameworks are present on project classpath surefire > > > chooses one framework for running the tests. > > > > > > In such situations, some tests are silently skipped. > > > > > > > > > I've created issue [1] for it with a simple proposition. > > > > > > After discussion on slack another proposition was in place to detect > the > > > test framework with other dependencies and choose a proper provider. > > > > > > Or use multiple providers instead of only one. > > > > > > > > > It will be good to choose how to solve this problem. > > > > > > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954 > > > > > > -- > > > Sławomir Jaranowski > > > > > > https://twitter.com/SlawekJaran > > > https://github.com/slawekjaranowski > > > https://linkedin.com/in/slawomirjaranowski > > > > > > > > -- > Sławomir Jaranowski >
Re: Surefire - multiple tests framework on classpath
Hi Slawomir, Pls follow this page https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html There is a chapter "How to run multiple APIs or Engines". There are also some links pointing to our integration test in the Apache project. Pls have a look. Cheers Tibor On Wed, Nov 3, 2021 at 6:22 PM Slawomir Jaranowski wrote: > Hi, > > I understand the difference between framework and providers. > I also know that we can add specific providers as dependency to the plugin > and in the result we have manually selected providers. > > When we don't configure any dependency the provider is chosen automatically > depending on what we have on classpath, what framework. > > eg. When we have on classpath junit4 and junit5, but without junit5 vintage > - junit4 tests are silently skipped. > > In most cases in the project we use one testing framework so > automatically choosing one provider is ok. > > When we use more that one framework it is probably during migration, so we > should define proper dependency. > It is ok when we have control on what we do in a project, but there are > some situations when we can make mistakes, like > - user add second testing framework and forgot about configuration > - we change project dependency and in transitive dependency we got next > testing framework > > So I want to mitigate the risk of skipped tests by warning / failing that > we have many frameworks and automatically provider selection takes place. > > We can also try to choose many providers (not one) automatically, but I > think it will be more complicated and in standard usage is not needed. > For automatic detection we have many corner cases, like testng + junit4 - > testng by default runs junit4 tests, so without special configuration for > testng we run some of the tests twice. > > > śr., 3 lis 2021 o 15:09 Tibor Digana napisał(a): > > > Hi Slawomir, > > > > The reality is different. > > It's not the frameworks but providers. > > So the plugin iterates over providers. > > You may choose whether you will define the provider artifacts in plugin > > deps or you let the plugin to select the providers upon dependencies > which > > means that there is some logic and JUnit5 deps may activate one provider > > for both the junit4 and 5. > > > > T > > > > On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski < > s.jaranow...@gmail.com > > > > > wrote: > > > > > Hi, > > > > > > When multiple test frameworks are present on project classpath surefire > > > chooses one framework for running the tests. > > > > > > In such situations, some tests are silently skipped. > > > > > > > > > I've created issue [1] for it with a simple proposition. > > > > > > After discussion on slack another proposition was in place to detect > the > > > test framework with other dependencies and choose a proper provider. > > > > > > Or use multiple providers instead of only one. > > > > > > > > > It will be good to choose how to solve this problem. > > > > > > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954 > > > > > > -- > > > Sławomir Jaranowski > > > > > > https://twitter.com/SlawekJaran > > > https://github.com/slawekjaranowski > > > https://linkedin.com/in/slawomirjaranowski > > > > > > > > -- > Sławomir Jaranowski >
Re: Surefire - multiple tests framework on classpath
Hi, I understand the difference between framework and providers. I also know that we can add specific providers as dependency to the plugin and in the result we have manually selected providers. When we don't configure any dependency the provider is chosen automatically depending on what we have on classpath, what framework. eg. When we have on classpath junit4 and junit5, but without junit5 vintage - junit4 tests are silently skipped. In most cases in the project we use one testing framework so automatically choosing one provider is ok. When we use more that one framework it is probably during migration, so we should define proper dependency. It is ok when we have control on what we do in a project, but there are some situations when we can make mistakes, like - user add second testing framework and forgot about configuration - we change project dependency and in transitive dependency we got next testing framework So I want to mitigate the risk of skipped tests by warning / failing that we have many frameworks and automatically provider selection takes place. We can also try to choose many providers (not one) automatically, but I think it will be more complicated and in standard usage is not needed. For automatic detection we have many corner cases, like testng + junit4 - testng by default runs junit4 tests, so without special configuration for testng we run some of the tests twice. śr., 3 lis 2021 o 15:09 Tibor Digana napisał(a): > Hi Slawomir, > > The reality is different. > It's not the frameworks but providers. > So the plugin iterates over providers. > You may choose whether you will define the provider artifacts in plugin > deps or you let the plugin to select the providers upon dependencies which > means that there is some logic and JUnit5 deps may activate one provider > for both the junit4 and 5. > > T > > On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski > > wrote: > > > Hi, > > > > When multiple test frameworks are present on project classpath surefire > > chooses one framework for running the tests. > > > > In such situations, some tests are silently skipped. > > > > > > I've created issue [1] for it with a simple proposition. > > > > After discussion on slack another proposition was in place to detect the > > test framework with other dependencies and choose a proper provider. > > > > Or use multiple providers instead of only one. > > > > > > It will be good to choose how to solve this problem. > > > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954 > > > > -- > > Sławomir Jaranowski > > > > https://twitter.com/SlawekJaran > > https://github.com/slawekjaranowski > > https://linkedin.com/in/slawomirjaranowski > > > -- Sławomir Jaranowski
Re: Surefire - multiple tests framework on classpath
Hi Slawomir, The reality is different. It's not the frameworks but providers. So the plugin iterates over providers. You may choose whether you will define the provider artifacts in plugin deps or you let the plugin to select the providers upon dependencies which means that there is some logic and JUnit5 deps may activate one provider for both the junit4 and 5. T On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski wrote: > Hi, > > When multiple test frameworks are present on project classpath surefire > chooses one framework for running the tests. > > In such situations, some tests are silently skipped. > > > I've created issue [1] for it with a simple proposition. > > After discussion on slack another proposition was in place to detect the > test framework with other dependencies and choose a proper provider. > > Or use multiple providers instead of only one. > > > It will be good to choose how to solve this problem. > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954 > > -- > Sławomir Jaranowski > > https://twitter.com/SlawekJaran > https://github.com/slawekjaranowski > https://linkedin.com/in/slawomirjaranowski >
[GitHub] [maven-artifact-transfer] dependabot[bot] closed pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] closed pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request #50: Bump actions/checkout from 2.3.4 to 2.4.0
dependabot[bot] opened a new pull request #50: URL: https://github.com/apache/maven-artifact-transfer/pull/50 Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.4 to 2.4.0. Release notes Sourced from https://github.com/actions/checkout/releases;>actions/checkout's releases. v2.4.0 Convert SSH URLs like org-ORG_ID@github.com: to https://github.com/ - https://github-redirect.dependabot.com/actions/checkout/pull/621;>pr v2.3.5 Update dependencies Commits https://github.com/actions/checkout/commit/ec3a7ce113134d7a93b817d10a8272cb61118579;>ec3a7ce set insteadOf url for org-id (https://github-redirect.dependabot.com/actions/checkout/issues/621;>#621) https://github.com/actions/checkout/commit/fd47087372161c6f2a7b96d2ef87e944d89023ed;>fd47087 codeql should analyze lib not dist (https://github-redirect.dependabot.com/actions/checkout/issues/620;>#620) https://github.com/actions/checkout/commit/3d677ac575eac4b370e52131024fa99ee754def1;>3d677ac script to generate license info (https://github-redirect.dependabot.com/actions/checkout/issues/614;>#614) https://github.com/actions/checkout/commit/826ba42d6c06e4d78b1b33478af7b54277e60b52;>826ba42 npm audit fix (https://github-redirect.dependabot.com/actions/checkout/issues/612;>#612) https://github.com/actions/checkout/commit/eb8a193c1dbf4bbb2053320cef52bacc1a485839;>eb8a193 update dev dependencies and react to new linting rules (https://github-redirect.dependabot.com/actions/checkout/issues/611;>#611) https://github.com/actions/checkout/commit/c49af7ca1f339b07a5baac8c8bfc49a5248f31d3;>c49af7c Create codeql-analysis.yml (https://github-redirect.dependabot.com/actions/checkout/issues/602;>#602) https://github.com/actions/checkout/commit/1e204e9a9253d643386038d443f96446fa156a97;>1e204e9 update licensed check (https://github-redirect.dependabot.com/actions/checkout/issues/606;>#606) https://github.com/actions/checkout/commit/0299a0d2b67d48224ce047d03c69693b37fe77fe;>0299a0d update dist (https://github-redirect.dependabot.com/actions/checkout/issues/605;>#605) https://github.com/actions/checkout/commit/be0f44845645e415725af198163a96fea9e54334;>be0f448 Bump ws from 5.2.2 to 5.2.3 (https://github-redirect.dependabot.com/actions/checkout/issues/604;>#604) https://github.com/actions/checkout/commit/56c00a7b1f53d3094df328ad4c2cd2b2d385c569;>56c00a7 Bump tmpl from 1.0.4 to 1.0.5 (https://github-redirect.dependabot.com/actions/checkout/issues/588;>#588) Additional commits viewable in https://github.com/actions/checkout/compare/v2.3.4...v2.4.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #49: Bump actions/checkout from 2.3.4 to 2.3.5
dependabot[bot] commented on pull request #49: URL: https://github.com/apache/maven-artifact-transfer/pull/49#issuecomment-958970536 Superseded by #50. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
