Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

This is the page where we describe the parallel execution for JUnit4
Maven Surefire Plugin – Fork Options and Parallel Test Execution
(apache.org)



and the source of this page can be found in
maven-surefire/fork-options-and-parallel-execution.apt.vm at master ·
apache/maven-surefire (github.com)



T


On Tue, Apr 13, 2021 at 9:27 PM V. Mark Lehky  wrote:

> I will not be able to look at this today, but I will hopefully get
> back to this within the next week.
>
> If I get this working, I definitely will be able to contribute back.
> Can you suggest where would be the best place to add docs about this?
>
> On Tue, 13 Apr 2021 at 00:40, Tibor Digana  wrote:
> >
> > Hi,
> >
> > threadCountSuites is related to JUnit4 Suite, see this:
> > https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
> >
> > threadCountClasses is related to the typical classes, see this example:
> > https://github.com/junit-team/junit4/wiki/Assertions
> >
> > Parallel packages do not exist, but you can make the same if you write a
> > Suite of Suites, example:
> > SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> > SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> > OtherStoryTest
> > and use this configuration parallel=suites, threadCountSuites=2,
> > test=SuiteMainTest.
> > This would work as you want to.
> >
> > It would nice to write an example in our documentation. If you want to
> > participate in the open source, you can open a pullrequest in GitHub.
> >
> >
> > Cheers
> > Tibor
> >
> > On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
> wrote:
> >
> > > I am trying to run my tests in parallel, and I have a use-case
> > > different from all others that I have been able to find.
> > >
> > > My tests are laid out pretty straight-forward, something like the
> > > following:
> > >
> > > src/test/java/
> > > +-features.areaA
> > > | +-SomeStory.java
> > > | +-AnotherStory.java
> > > | ...
> > > +-features.areaB
> > > | +-DifferentStory.java
> > > | +-OtherStory.java
> > > | ...
> > > ...
> > >
> > > The tests are written using serenity-bdd, which is a wrapper for
> > > selenium, and the test manager is junit4.
> > >
> > > Each "area" represents some discreet area of the application under
> > > test. Tests within one area cannot run in parallel as they would
> > > clobber the data they are using. However, tests between different
> > > areas can certainly run in parallel as there are no collisions.
> > >
> > > I tried to configure my maven-failsafe-plugin according to the
> > > documentation (
> > >
> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> > > ).
> > > Using parallel=suites and any one of threadCount=4,
> > > threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> > > test being run at a time.
> > >
> > > Is my understanding of "suites" wrong in the context of Failsafe
> > > plugin? Is it possible to parallelize tests so that entire packages
> > > are fed into VM threads one at a time, but classes within one package
> > > run sequentially?
> > >
> > > ty
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven internal company component sharing best practices

[Mantas Gridinas]

I've toyed with idea of partially releasing libraries (and
applications, for that matter), but scrapped it because managing the
versions was painful. Reasoning being that most of my changes were in
dependency management block in the bom parent, so all of dependents
would need to bump their parent version, and in turn their own version
anyway. At the time I was using versions plugin for preparing the new
releases. It worked great, since I had a bom parent, and versions:set
-DnextSnapshot would bump the dependencies in that block as well. The
only catch is that you can't use properties for artifact versions (not
that you should, in my opinion).

Regarding having a single repository for "libraries": we have that
right now. It suffers from that monorepository issue that I had
outlined in my previous response, but we just release all the
artifacts regardless if they changed or not. You can think of it as
insurance that each of those libraries won't collide in dependencies.
Atleast it does not move as fast as the regular applications
repository. Not that I believe in single repository for libraries, due
to several reasons:
* Library repositories should be scoped per domain (ex. related to
single external service, and/or framework)
* It becomes easier to store unrelated code in a module

Regardless of rants above, if you won't go out of your way to tear
maven a new one, you will do fine whether it's monorepo or multi repo
approach.


On Tue, Apr 13, 2021 at 6:54 PM Andy Feldman  wrote:
>
> Yes, the release plugin works fine on just one module. That's exactly what
> we do, using the --projects (-pl) flag to only build the module(s) we want
> to release, in combination with release:prepare release:perform. You could
> probably achieve the same thing by running Maven from the submodule
> directory but with our build pipelines we find it easier to configure the
> flag than the working directory.
>
> Note that you wouldn't want to have any snapshot dependencies, even on the
> parent. The parent should be versioned and published as its own artifact.
> In our case we don't use an in-repo  for any submodules we intend
> to publish on their own; we have a company-wide parent in its own repo and
> they inherit directly from that.
>
> I guess I don't see a reason why the parent couldn't be in the same repo,
> as long as it's versioned and published on its own in the same way that
> everything else is. You'd probably want one root-level pom that declares
> all the modules, but you *wouldn't* want to use that pom as the 
> for each of the library poms. You'd instead want the parent pom to be just
> one of the modules. Otherwise you'd have no way to publish it on its own
> because building it would involve building all the declared modules too. I
> hope that makes sense (and I hope it's right since we don't actually do it
> that way!)
>
>
> On Tue, Apr 13, 2021 at 11:50 AM David Hoffer  wrote:
>
> > Following up on this.
> >
> > First, thanks for the quick and detailed responses.
> >
> > I have another colleague that suggested we create a single new GIT repo for
> > the 'library' code that would be a multi-module Maven build, each module
> > being a component.  My first thought is that it does solve the
> > 'releasability' of components and applications issue but does it allow
> > granular versioning/releasing of the modules?
> >
> > In all my experience with multi-module builds they all shared the same
> > version from the parent and all were released at the same time with the
> > same version.  However is that a Maven requirement?
> >
> > I see in the link below in the multi-module projects section that there is
> > an autoVersionSubmodules flag.  So if that is false how does this work on
> > the sub-modules?  E.g. it says it will prompt for the new version for each
> > module but does it allow you to skip modules that didn't have any changes
> > so no need to release?  E.g. is the release granularity at the module
> > layer?
> >
> > E.g. if I have 10 components in the multi-module Maven build, can I release
> > just one and with a version completely independent of the others?
> >
> > Also just so I know...can the release plugin be run on just one module and
> > not on the parent?
> >
> >
> > https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
> >
> > Again just looking for best practices here regarding sharing components and
> > how they can be versioned independently.
> >
> > Thanks,
> > -Dave
> >
> > On Mon, Apr 12, 2021 at 12:36 PM Mantas Gridinas 
> > wrote:
> >
> > > Being in similar situation myself I strongly suggest against storing
> > > the "library" component in the same place as your application is
> > > stored, because you will be producing n+1 artifacts every time, where
> > > n is the modules actually required to build for your application. Your
> > > application will be moving faster than that library component and you
> > > will be producing duplicate builds of it, 

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[V. Mark Lehky]

I will not be able to look at this today, but I will hopefully get
back to this within the next week.

If I get this working, I definitely will be able to contribute back.
Can you suggest where would be the best place to add docs about this?

On Tue, 13 Apr 2021 at 00:40, Tibor Digana  wrote:
>
> Hi,
>
> threadCountSuites is related to JUnit4 Suite, see this:
> https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
>
> threadCountClasses is related to the typical classes, see this example:
> https://github.com/junit-team/junit4/wiki/Assertions
>
> Parallel packages do not exist, but you can make the same if you write a
> Suite of Suites, example:
> SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> OtherStoryTest
> and use this configuration parallel=suites, threadCountSuites=2,
> test=SuiteMainTest.
> This would work as you want to.
>
> It would nice to write an example in our documentation. If you want to
> participate in the open source, you can open a pullrequest in GitHub.
>
>
> Cheers
> Tibor
>
> On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky  wrote:
>
> > I am trying to run my tests in parallel, and I have a use-case
> > different from all others that I have been able to find.
> >
> > My tests are laid out pretty straight-forward, something like the
> > following:
> >
> > src/test/java/
> > +-features.areaA
> > | +-SomeStory.java
> > | +-AnotherStory.java
> > | ...
> > +-features.areaB
> > | +-DifferentStory.java
> > | +-OtherStory.java
> > | ...
> > ...
> >
> > The tests are written using serenity-bdd, which is a wrapper for
> > selenium, and the test manager is junit4.
> >
> > Each "area" represents some discreet area of the application under
> > test. Tests within one area cannot run in parallel as they would
> > clobber the data they are using. However, tests between different
> > areas can certainly run in parallel as there are no collisions.
> >
> > I tried to configure my maven-failsafe-plugin according to the
> > documentation (
> > https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> > ).
> > Using parallel=suites and any one of threadCount=4,
> > threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> > test being run at a time.
> >
> > Is my understanding of "suites" wrong in the context of Failsafe
> > plugin? Is it possible to parallelize tests so that entire packages
> > are fed into VM threads one at a time, but classes within one package
> > run sequentially?
> >
> > ty
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

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

Re: Maven internal company component sharing best practices

[Andy Feldman]

Yes, the release plugin works fine on just one module. That's exactly what
we do, using the --projects (-pl) flag to only build the module(s) we want
to release, in combination with release:prepare release:perform. You could
probably achieve the same thing by running Maven from the submodule
directory but with our build pipelines we find it easier to configure the
flag than the working directory.

Note that you wouldn't want to have any snapshot dependencies, even on the
parent. The parent should be versioned and published as its own artifact.
In our case we don't use an in-repo  for any submodules we intend
to publish on their own; we have a company-wide parent in its own repo and
they inherit directly from that.

I guess I don't see a reason why the parent couldn't be in the same repo,
as long as it's versioned and published on its own in the same way that
everything else is. You'd probably want one root-level pom that declares
all the modules, but you *wouldn't* want to use that pom as the 
for each of the library poms. You'd instead want the parent pom to be just
one of the modules. Otherwise you'd have no way to publish it on its own
because building it would involve building all the declared modules too. I
hope that makes sense (and I hope it's right since we don't actually do it
that way!)


On Tue, Apr 13, 2021 at 11:50 AM David Hoffer  wrote:

> Following up on this.
>
> First, thanks for the quick and detailed responses.
>
> I have another colleague that suggested we create a single new GIT repo for
> the 'library' code that would be a multi-module Maven build, each module
> being a component.  My first thought is that it does solve the
> 'releasability' of components and applications issue but does it allow
> granular versioning/releasing of the modules?
>
> In all my experience with multi-module builds they all shared the same
> version from the parent and all were released at the same time with the
> same version.  However is that a Maven requirement?
>
> I see in the link below in the multi-module projects section that there is
> an autoVersionSubmodules flag.  So if that is false how does this work on
> the sub-modules?  E.g. it says it will prompt for the new version for each
> module but does it allow you to skip modules that didn't have any changes
> so no need to release?  E.g. is the release granularity at the module
> layer?
>
> E.g. if I have 10 components in the multi-module Maven build, can I release
> just one and with a version completely independent of the others?
>
> Also just so I know...can the release plugin be run on just one module and
> not on the parent?
>
>
> https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
>
> Again just looking for best practices here regarding sharing components and
> how they can be versioned independently.
>
> Thanks,
> -Dave
>
> On Mon, Apr 12, 2021 at 12:36 PM Mantas Gridinas 
> wrote:
>
> > Being in similar situation myself I strongly suggest against storing
> > the "library" component in the same place as your application is
> > stored, because you will be producing n+1 artifacts every time, where
> > n is the modules actually required to build for your application. Your
> > application will be moving faster than that library component and you
> > will be producing duplicate builds of it, which ultimately just
> > consumes space in your artifact repository. The upside of this
> > approach is you don't have to worry about transitive dependency
> > conflicts.
> >
> > In our case we host sonatype, put everything there and reference them
> > as needed. There are two downsides to this approach, though:
> > dependency conflicts and bumping the dependency in dependent
> > applications.
> >
> > Dependency conflicts happen because of several reasons:
> > * developer decided to change its artifact/group id starting with some
> > version
> > * you're importing some dependency pom (like spring, camel, or what
> > ever overarching framework provides it)
> > * you require several frameworks at the same time
> >
> > Maven is perfectly capable of resolving those conflicts if artifacts
> > actually collide (spring-boot-camel-starter:3.0.0 provides spring boot
> > 2.2.1 while you're actually using 2.4.4, and since you have shorter
> > path to spring 2.4.4 maven will use that). Problems arise when
> > collisions happen between artifacts that contribute to same package
> > (ex. ehcache changing its group id between ehcache 2 and ehcache 3) or
> > depend on each other indirectly (ex. cxf switching between blocking
> > and async calls depending if you have cxf-rt-transports-http-hc on
> > your classpath). This is solved by using enforcer plugin with
> > dependency convergence rule.
> >
> > Dependency bumping is a pretty tiring process. Whenever you would
> > release a new library version, you would have to go and bump its
> > version across all applications and/or libraries that depend on it.
> > Since we're in the process of 

Re: unsubscribe- STOP

[Padma Asrani]

unsubscribe- STOP

On Tue, Apr 13, 2021 at 6:01 AM Moon,Todd (DFPS Contractor) <
todd.m...@dfps.texas.gov> wrote:

> unsubscribe- STOP
>
> -Original Message-
> From: Delany 
> Sent: Tuesday, April 13, 2021 6:25 AM
> To: Maven Users List 
> Subject: directed acyclic graph of the build
>
> WARNING: This email is from outside the DFPS system. Do not click on links
> or attachments unless you expect them from the sender and know the content
> is safe.
>
> Hi
>
> How can I get a DAG of the build?
> I want to see how projects are being scheduled in a multithreaded build.
>
> Thanks,
> Delany
> NOTICE: There has been a change to my email address. Effective
> immediately, my new email address is: todd.m...@dfps.texas.gov.
>

Re: directed acyclic graph of the build

[Tamás Cservenák]

Howdy,

you can see the "build plan" which is not DAG, but the ordered list out of
DAG (sorted nodes in order DAG requires), just use `-X` on the command line.
But again, this list does not reflect in reality "how the build is gonna
execute"...

As regarding the actual "build order", it depends on Builder implementation:
See here:
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/Builder.java
and package (with ST and MT Builders in subpackages)
https://github.com/apache/maven/tree/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder

Also, there are "alternative" Builders like this one
https://github.com/takari/takari-smart-builder/blob/master/src/main/java/io/takari/maven/builder/smart/SmartBuilder.java

You can get more explained here, but most you can get is by reading sources
above
http://takari.io/book/30-team-maven.html#takari-smart-builder

HTH
T




On Tue, Apr 13, 2021 at 6:58 PM Delany  wrote:

> Im interested in modules though, not dependencies, at least not initially.
> If I say Maven give me a dag of project A, I'd expect it to go through the
> list of modules and create a tree. That's what it's going to build. The
> question then is what order to build them.
> Obviously project A would be first. Then if a child project had a
> dependency on another, that would put it ahead in the build order, etc,
> etc. A picture would emerge, potentially showing me what projects are
> bottlenecking the build.
>
> I see ferstl was working on this:
> https://github.com/ferstl/depgraph-maven-plugin/issues/103
>
> Delany
>
> On Tue, 13 Apr 2021 at 17:36, Tibor Digana  wrote:
>
> > DAG of the POM.
> > I am using IntelliJ IDEA for such things but you can also use
> > maven-dependency-plugin which prints the dependencies in the console.
> >
> > On Tue, Apr 13, 2021 at 1:26 PM Delany 
> wrote:
> >
> > > Hi
> > >
> > > How can I get a DAG of the build?
> > > I want to see how projects are being scheduled in a multithreaded
> build.
> > >
> > > Thanks,
> > > Delany
> > >
> >
>

Re: directed acyclic graph of the build

[Delany]

Im interested in modules though, not dependencies, at least not initially.
If I say Maven give me a dag of project A, I'd expect it to go through the
list of modules and create a tree. That's what it's going to build. The
question then is what order to build them.
Obviously project A would be first. Then if a child project had a
dependency on another, that would put it ahead in the build order, etc,
etc. A picture would emerge, potentially showing me what projects are
bottlenecking the build.

I see ferstl was working on this:
https://github.com/ferstl/depgraph-maven-plugin/issues/103

Delany

On Tue, 13 Apr 2021 at 17:36, Tibor Digana  wrote:

> DAG of the POM.
> I am using IntelliJ IDEA for such things but you can also use
> maven-dependency-plugin which prints the dependencies in the console.
>
> On Tue, Apr 13, 2021 at 1:26 PM Delany  wrote:
>
> > Hi
> >
> > How can I get a DAG of the build?
> > I want to see how projects are being scheduled in a multithreaded build.
> >
> > Thanks,
> > Delany
> >
>

Re: Maven internal company component sharing best practices

[David Hoffer]

Following up on this.

First, thanks for the quick and detailed responses.

I have another colleague that suggested we create a single new GIT repo for
the 'library' code that would be a multi-module Maven build, each module
being a component.  My first thought is that it does solve the
'releasability' of components and applications issue but does it allow
granular versioning/releasing of the modules?

In all my experience with multi-module builds they all shared the same
version from the parent and all were released at the same time with the
same version.  However is that a Maven requirement?

I see in the link below in the multi-module projects section that there is
an autoVersionSubmodules flag.  So if that is false how does this work on
the sub-modules?  E.g. it says it will prompt for the new version for each
module but does it allow you to skip modules that didn't have any changes
so no need to release?  E.g. is the release granularity at the module layer?

E.g. if I have 10 components in the multi-module Maven build, can I release
just one and with a version completely independent of the others?

Also just so I know...can the release plugin be run on just one module and
not on the parent?

https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html

Again just looking for best practices here regarding sharing components and
how they can be versioned independently.

Thanks,
-Dave

On Mon, Apr 12, 2021 at 12:36 PM Mantas Gridinas 
wrote:

> Being in similar situation myself I strongly suggest against storing
> the "library" component in the same place as your application is
> stored, because you will be producing n+1 artifacts every time, where
> n is the modules actually required to build for your application. Your
> application will be moving faster than that library component and you
> will be producing duplicate builds of it, which ultimately just
> consumes space in your artifact repository. The upside of this
> approach is you don't have to worry about transitive dependency
> conflicts.
>
> In our case we host sonatype, put everything there and reference them
> as needed. There are two downsides to this approach, though:
> dependency conflicts and bumping the dependency in dependent
> applications.
>
> Dependency conflicts happen because of several reasons:
> * developer decided to change its artifact/group id starting with some
> version
> * you're importing some dependency pom (like spring, camel, or what
> ever overarching framework provides it)
> * you require several frameworks at the same time
>
> Maven is perfectly capable of resolving those conflicts if artifacts
> actually collide (spring-boot-camel-starter:3.0.0 provides spring boot
> 2.2.1 while you're actually using 2.4.4, and since you have shorter
> path to spring 2.4.4 maven will use that). Problems arise when
> collisions happen between artifacts that contribute to same package
> (ex. ehcache changing its group id between ehcache 2 and ehcache 3) or
> depend on each other indirectly (ex. cxf switching between blocking
> and async calls depending if you have cxf-rt-transports-http-hc on
> your classpath). This is solved by using enforcer plugin with
> dependency convergence rule.
>
> Dependency bumping is a pretty tiring process. Whenever you would
> release a new library version, you would have to go and bump its
> version across all applications and/or libraries that depend on it.
> Since we're in the process of splitting our monorepository, we were
> looking into solutions to automate that. If you're on github, and use
> github as nexus, you can look into dependabot. It's free to use and
> has a lot of configuration options. Since we're not so lucky, we might
> end up using renovate or something similar. The idea is to create a
> pullrequest to dependents whenever a new version of that library is
> released with the bumped version. Upside is you won't have to do
> manual labor of bumping the version, while downside is having a ton of
> noise if you have complicated dependency trees.
>
> These are issues i've encountered so far. You can start by hosting
> your own nexus, uploading artifacts to it and referencing the
> artifacts in the pom. Sonatype offers free solution
> https://www.sonatype.com/products/repository-oss-download. Take care
> of your dependency tree.
>
> On Mon, Apr 12, 2021 at 6:03 PM David Hoffer  wrote:
> >
> > Hey just looking for Maven best practices here, want to be sure I'm not
> > missing something.
> >
> > Here is our use case.
> >
> > We have 10 applications that have duplicate code in each, we want to
> create
> > component(s) for the duplicate code and not duplicate in the 10 apps/GIT
> > any longer.
> >
> > Each app is in a separate GIT repository & each has a Maven build.
> Simple
> > single module build in each.
> >
> > To solve this I am assuming we need a new GIT repo for the duplicate code
> > and a Maven build for it.  That repo and it's component would be released

Re: directed acyclic graph of the build

[Tibor Digana]

DAG of the POM.
I am using IntelliJ IDEA for such things but you can also use
maven-dependency-plugin which prints the dependencies in the console.

On Tue, Apr 13, 2021 at 1:26 PM Delany  wrote:

> Hi
>
> How can I get a DAG of the build?
> I want to see how projects are being scheduled in a multithreaded build.
>
> Thanks,
> Delany
>

Re: UNSUBSCRIBE-STOP

[Torsten Stolpmann]

Try reading this instead: https://maven.apache.org/mailing-lists.html

On 13.04.2021 15:01, Moon,Todd (DFPS Contractor) wrote:

UNSUBSCRIBE-STOP

-Original Message-
From: Tibor Digana 
Sent: Tuesday, April 13, 2021 2:42 AM
To: Maven Users List 
Subject: Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

WARNING: This email is from outside the DFPS system. Do not click on links or 
attachments unless you expect them from the sender and know the content is safe.

There are 3 suites in my example, so set threadCountSuites=3.

On Tue, Apr 13, 2021 at 9:39 AM Tibor Digana  wrote:


Hi,

threadCountSuites is related to JUnit4 Suite, see this:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fjunit-team%2Fjunit4%2Fwiki%2FAggregating-tests-in-suites
data=04%7C01%7CTodd.Moon%40dfps.texas.gov%7Cee8315ecabbd4800ec2808d8fe
4f9de6%7C0915ef3812cd4561ab809c7f41bfb31e%7C0%7C0%7C637538965197441000
%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
k1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FhISbCz3rBaVORh7DxFcNFd4EAqQCL7
hxEvDTtqflWw%3Dreserved=0

threadCountClasses is related to the typical classes, see this example:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fjunit-team%2Fjunit4%2Fwiki%2FAssertionsdata=04%7C01%7CTo
dd.Moon%40dfps.texas.gov%7Cee8315ecabbd4800ec2808d8fe4f9de6%7C0915ef38
12cd4561ab809c7f41bfb31e%7C0%7C0%7C637538965197441000%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C1000sdata=g0oO0eqzTe2V3rA8mPU9GMVNTP%2FELTOfDJGqTBXNr9w%3D
reserved=0

Parallel packages do not exist, but you can make the same if you write
a Suite of Suites, example:
SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
OtherStoryTest and use this configuration parallel=suites,
threadCountSuites=2, test=SuiteMainTest.
This would work as you want to.

It would nice to write an example in our documentation. If you want to
participate in the open source, you can open a pullrequest in GitHub.


Cheers
Tibor

On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
wrote:


I am trying to run my tests in parallel, and I have a use-case
different from all others that I have been able to find.

My tests are laid out pretty straight-forward, something like the
following:

src/test/java/
+-features.areaA
| +-SomeStory.java
| +-AnotherStory.java
| ...
+-features.areaB
| +-DifferentStory.java
| +-OtherStory.java
| ...
...

The tests are written using serenity-bdd, which is a wrapper for
selenium, and the test manager is junit4.

Each "area" represents some discreet area of the application under
test. Tests within one area cannot run in parallel as they would
clobber the data they are using. However, tests between different
areas can certainly run in parallel as there are no collisions.

I tried to configure my maven-failsafe-plugin according to the
documentation (
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmav
en.apache.org%2Fsurefire%2Fmaven-failsafe-plugin%2Fexamples%2Ffork-op
tions-and-parallel-execution.htmldata=04%7C01%7CTodd.Moon%40dfps
.texas.gov%7Cee8315ecabbd4800ec2808d8fe4f9de6%7C0915ef3812cd4561ab809
c7f41bfb31e%7C0%7C0%7C637538965197441000%7CUnknown%7CTWFpbGZsb3d8eyJW
IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
sdata=qnsAGPurAthmrft1nive8SG1aWCmsV5xcDxeVS%2FZcgw%3Dreser
ved=0
).
Using parallel=suites and any one of threadCount=4,
threadCountSuites=4, or useUnlimitedThreads=true, results in only one
test being run at a time.

Is my understanding of "suites" wrong in the context of Failsafe
plugin? Is it possible to parallelize tests so that entire packages
are fed into VM threads one at a time, but classes within one package
run sequentially?

ty

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



NOTICE: There has been a change to my email address. Effective immediately, my 
new email address is: todd.m...@dfps.texas.gov.

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




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

UNSUBSCRIBE-STOP

[Moon,Todd (DFPS Contractor)]

UNSUBSCRIBE-STOP

-Original Message-
From: Tibor Digana 
Sent: Tuesday, April 13, 2021 2:42 AM
To: Maven Users List 
Subject: Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

WARNING: This email is from outside the DFPS system. Do not click on links or 
attachments unless you expect them from the sender and know the content is safe.

There are 3 suites in my example, so set threadCountSuites=3.

On Tue, Apr 13, 2021 at 9:39 AM Tibor Digana  wrote:

> Hi,
>
> threadCountSuites is related to JUnit4 Suite, see this:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fjunit-team%2Fjunit4%2Fwiki%2FAggregating-tests-in-suites
> data=04%7C01%7CTodd.Moon%40dfps.texas.gov%7Cee8315ecabbd4800ec2808d8fe
> 4f9de6%7C0915ef3812cd4561ab809c7f41bfb31e%7C0%7C0%7C637538965197441000
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FhISbCz3rBaVORh7DxFcNFd4EAqQCL7
> hxEvDTtqflWw%3Dreserved=0
>
> threadCountClasses is related to the typical classes, see this example:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fjunit-team%2Fjunit4%2Fwiki%2FAssertionsdata=04%7C01%7CTo
> dd.Moon%40dfps.texas.gov%7Cee8315ecabbd4800ec2808d8fe4f9de6%7C0915ef38
> 12cd4561ab809c7f41bfb31e%7C0%7C0%7C637538965197441000%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C1000sdata=g0oO0eqzTe2V3rA8mPU9GMVNTP%2FELTOfDJGqTBXNr9w%3D
> reserved=0
>
> Parallel packages do not exist, but you can make the same if you write
> a Suite of Suites, example:
> SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> OtherStoryTest and use this configuration parallel=suites,
> threadCountSuites=2, test=SuiteMainTest.
> This would work as you want to.
>
> It would nice to write an example in our documentation. If you want to
> participate in the open source, you can open a pullrequest in GitHub.
>
>
> Cheers
> Tibor
>
> On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
> wrote:
>
>> I am trying to run my tests in parallel, and I have a use-case
>> different from all others that I have been able to find.
>>
>> My tests are laid out pretty straight-forward, something like the
>> following:
>>
>> src/test/java/
>> +-features.areaA
>> | +-SomeStory.java
>> | +-AnotherStory.java
>> | ...
>> +-features.areaB
>> | +-DifferentStory.java
>> | +-OtherStory.java
>> | ...
>> ...
>>
>> The tests are written using serenity-bdd, which is a wrapper for
>> selenium, and the test manager is junit4.
>>
>> Each "area" represents some discreet area of the application under
>> test. Tests within one area cannot run in parallel as they would
>> clobber the data they are using. However, tests between different
>> areas can certainly run in parallel as there are no collisions.
>>
>> I tried to configure my maven-failsafe-plugin according to the
>> documentation (
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmav
>> en.apache.org%2Fsurefire%2Fmaven-failsafe-plugin%2Fexamples%2Ffork-op
>> tions-and-parallel-execution.htmldata=04%7C01%7CTodd.Moon%40dfps
>> .texas.gov%7Cee8315ecabbd4800ec2808d8fe4f9de6%7C0915ef3812cd4561ab809
>> c7f41bfb31e%7C0%7C0%7C637538965197441000%7CUnknown%7CTWFpbGZsb3d8eyJW
>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
>> sdata=qnsAGPurAthmrft1nive8SG1aWCmsV5xcDxeVS%2FZcgw%3Dreser
>> ved=0
>> ).
>> Using parallel=suites and any one of threadCount=4,
>> threadCountSuites=4, or useUnlimitedThreads=true, results in only one
>> test being run at a time.
>>
>> Is my understanding of "suites" wrong in the context of Failsafe
>> plugin? Is it possible to parallelize tests so that entire packages
>> are fed into VM threads one at a time, but classes within one package
>> run sequentially?
>>
>> ty
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
NOTICE: There has been a change to my email address. Effective immediately, my 
new email address is: todd.m...@dfps.texas.gov.

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

unsubscribe- STOP

[Moon,Todd (DFPS Contractor)]

unsubscribe- STOP

-Original Message-
From: Delany 
Sent: Tuesday, April 13, 2021 6:25 AM
To: Maven Users List 
Subject: directed acyclic graph of the build

WARNING: This email is from outside the DFPS system. Do not click on links or 
attachments unless you expect them from the sender and know the content is safe.

Hi

How can I get a DAG of the build?
I want to see how projects are being scheduled in a multithreaded build.

Thanks,
Delany
NOTICE: There has been a change to my email address. Effective immediately, my 
new email address is: todd.m...@dfps.texas.gov.

directed acyclic graph of the build

[Delany]

Hi

How can I get a DAG of the build?
I want to see how projects are being scheduled in a multithreaded build.

Thanks,
Delany

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

There are 3 suites in my example, so set threadCountSuites=3.

On Tue, Apr 13, 2021 at 9:39 AM Tibor Digana  wrote:

> Hi,
>
> threadCountSuites is related to JUnit4 Suite, see this:
> https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites
>
> threadCountClasses is related to the typical classes, see this example:
> https://github.com/junit-team/junit4/wiki/Assertions
>
> Parallel packages do not exist, but you can make the same if you write a
> Suite of Suites, example:
> SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
> SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
> OtherStoryTest
> and use this configuration parallel=suites, threadCountSuites=2,
> test=SuiteMainTest.
> This would work as you want to.
>
> It would nice to write an example in our documentation. If you want to
> participate in the open source, you can open a pullrequest in GitHub.
>
>
> Cheers
> Tibor
>
> On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky 
> wrote:
>
>> I am trying to run my tests in parallel, and I have a use-case
>> different from all others that I have been able to find.
>>
>> My tests are laid out pretty straight-forward, something like the
>> following:
>>
>> src/test/java/
>> +-features.areaA
>> | +-SomeStory.java
>> | +-AnotherStory.java
>> | ...
>> +-features.areaB
>> | +-DifferentStory.java
>> | +-OtherStory.java
>> | ...
>> ...
>>
>> The tests are written using serenity-bdd, which is a wrapper for
>> selenium, and the test manager is junit4.
>>
>> Each "area" represents some discreet area of the application under
>> test. Tests within one area cannot run in parallel as they would
>> clobber the data they are using. However, tests between different
>> areas can certainly run in parallel as there are no collisions.
>>
>> I tried to configure my maven-failsafe-plugin according to the
>> documentation (
>> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
>> ).
>> Using parallel=suites and any one of threadCount=4,
>> threadCountSuites=4, or useUnlimitedThreads=true, results in only one
>> test being run at a time.
>>
>> Is my understanding of "suites" wrong in the context of Failsafe
>> plugin? Is it possible to parallelize tests so that entire packages
>> are fed into VM threads one at a time, but classes within one package
>> run sequentially?
>>
>> ty
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: [maven-failsafe-plugin] run suites in parallel using maven failsafe

[Tibor Digana]

Hi,

threadCountSuites is related to JUnit4 Suite, see this:
https://github.com/junit-team/junit4/wiki/Aggregating-tests-in-suites

threadCountClasses is related to the typical classes, see this example:
https://github.com/junit-team/junit4/wiki/Assertions

Parallel packages do not exist, but you can make the same if you write a
Suite of Suites, example:
SuiteMainTest has (SuiteATest, SuiteBTest) where SuiteATest has
SomeStoryTest, AnotherStoryTest and SuiteBTest has DifferentStoryTest,
OtherStoryTest
and use this configuration parallel=suites, threadCountSuites=2,
test=SuiteMainTest.
This would work as you want to.

It would nice to write an example in our documentation. If you want to
participate in the open source, you can open a pullrequest in GitHub.


Cheers
Tibor

On Mon, Apr 12, 2021 at 8:48 PM V. Mark Lehky  wrote:

> I am trying to run my tests in parallel, and I have a use-case
> different from all others that I have been able to find.
>
> My tests are laid out pretty straight-forward, something like the
> following:
>
> src/test/java/
> +-features.areaA
> | +-SomeStory.java
> | +-AnotherStory.java
> | ...
> +-features.areaB
> | +-DifferentStory.java
> | +-OtherStory.java
> | ...
> ...
>
> The tests are written using serenity-bdd, which is a wrapper for
> selenium, and the test manager is junit4.
>
> Each "area" represents some discreet area of the application under
> test. Tests within one area cannot run in parallel as they would
> clobber the data they are using. However, tests between different
> areas can certainly run in parallel as there are no collisions.
>
> I tried to configure my maven-failsafe-plugin according to the
> documentation (
> https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html
> ).
> Using parallel=suites and any one of threadCount=4,
> threadCountSuites=4, or useUnlimitedThreads=true, results in only one
> test being run at a time.
>
> Is my understanding of "suites" wrong in the context of Failsafe
> plugin? Is it possible to parallelize tests so that entire packages
> are fed into VM threads one at a time, but classes within one package
> run sequentially?
>
> ty
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>