Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Nils Breunese]

I can’t comment on your question directly, but I just wanted to say that your 
use case sounds like it could benefit from the Maven Build Cache Extension 
(https://maven.apache.org/extensions/maven-build-cache-extension/).

Just my 2 cents.

Nils.

> Op 6 feb 2024 om 11:40 heeft Joseph Leonard  
> het volgende geschreven:
> 
> Hi all,
> 
> It would be great to get any thoughts on whether the following is a defect:
> 
> 
> Issue details:
> tl;dr
> 
> Maven can resolve dependencies either from:
> 
>  *   an external repo
>  *   a class directory of a module being built within the reactor
>  *   a packaged jar of a module being built within the reactor
> 
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.
> 
> Full details
> Scenario
> 
> Consider you have a repo with the following structure:
> 
>   App
> 
> / \
> 
>/   \
> 
>   (compile scope)  (test scope)
> 
>  /   \
> 
>\/_   _\/
> 
> ModuleA  TestSupportModule1
> 
>/
> 
>   /
> 
>(compile scope)
> 
> /
> 
>   \/_
> 
>ModuleB
> 
>   /
> 
>  /
> 
>(test scope)
> 
>/
> 
>  \/_
> 
> TestSupportModule2
> 
> If you were to make a src code change to the following test support modules:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
> 
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
>  *   ModuleB
>  *   App
> 
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.
> 
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':
> 
>  *   TestSupportModule1 followed by ModuleB
>  *   TestSupportModule1 followed by App
> 
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':
> 
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> 
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).
> 
> Issue
> 
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:
> 
>  *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)
>  *   If the 'App' build starts after ModuleB has compiled its src classes but 
> before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory
>  *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> 
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
> empty ModuleB.jar file.
> 
> Proposed solution
> 
> Ideally we would like the Maven reactor to retain isolation between the two 
> distinct 'dependency graphs' it constructs at instantiation throughout the 
> entire Maven build. This would mean, in the simple example above, that the 
> 'App' would always resolves ModuleB from the external repo (regardless of 
> whether the reactor has built ModuleB or not in a separate 'dependency 

Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Joseph Leonard]

Hi all,

It would be great to get any thoughts on whether the following is a defect:


Issue details:
tl;dr

Maven can resolve dependencies either from:

  *   an external repo
  *   a class directory of a module being built within the reactor
  *   a packaged jar of a module being built within the reactor

If you run a concurrent multi-module build it is possible to get a race 
condition whereby the build of module Foo may resolve module Bar from either of 
the three resolution channels. This inconsistency can result in the Maven war 
plugin sometimes failing to build a functional war file. I would expect a 
consistent resolution would always take place.

Full details
Scenario

Consider you have a repo with the following structure:

   App

 / \

/   \

   (compile scope)  (test scope)

  /   \

\/_   _\/

 ModuleA  TestSupportModule1

/

   /

(compile scope)

 /

   \/_

ModuleB

   /

  /

(test scope)

/

  \/_

TestSupportModule2

If you were to make a src code change to the following test support modules:

  *   TestSupportModule1
  *   TestSupportModule2

Then the minimum number of modules we need to build to verify the change set is 
OK is:

  *   TestSupportModule1
  *   TestSupportModule2
  *   ModuleB
  *   App

i.e. there is no requirement to build ModuleA because we know that none of the 
src code changes could impact the classpaths used in its maven build.

We know that despite 'App' depending (transitively) on ModuleB there is no need 
for the 'App' build to wait for ModuleB to complete its build because the src 
code change to TestSupportModule2 will not impact any of the classpaths used in 
the App maven build. Therefore to get the most efficient build possible we 
ideally would invoke Maven to run with 2 threads and with instruction to build 
two distinct 'dependency graphs':

  *   TestSupportModule1 followed by ModuleB
  *   TestSupportModule1 followed by App

The following Maven command achieves exactly what we want because the reactor 
build order is based only on the direct (i.e. non-transitive) dependencies of 
the modules provided to the reactor in the build command. Therefore the absence 
of ModuleA results in two distinct 'dependency graphs':

mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2

Note: In reality the code base I maintain has a very large monobuild with 100s 
of modules and this type of build optimisation makes a significant difference 
to the speed of our monobuild (we use 
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
automate the logic of determining which modules to include in the reactor based 
on our change set).

Issue

We have encountered an issue in the above scenario because the 'App' build has 
a race condition with the ModuleB build which will result in one of the 
following three outcomes:

  *   If the 'App' build starts before the ModuleB build has compiled its src 
classes then the 'App' build will resolve ModuleB from the external repo (i.e. 
equivalent to ModuleB not being in the reactor at all)
  *   If the 'App' build starts after ModuleB has compiled its src classes but 
before it has packaged these classes into a jar then the 'App' build will 
resolve ModuleB's target/classes directory
  *   If the 'App' build starts after ModuleB has packaged its jar file then 
the 'App' build will resolve ModuleB's target/ModuleB.jar file.

In many scenarios this dependency resolution inconsistency doesn't represent a 
challenge. However, it does cause an issue in our case because the 'App' POM 
has its Maven packaging stanza configured to war and in the scenario where 
ModuleB's target/classes directory is resolved by the 'App' then this results 
in the resultant 'App' war file being packaged with a completely empty 
ModuleB.jar file.

Proposed solution

Ideally we would like the Maven reactor to retain isolation between the two 
distinct 'dependency graphs' it constructs at instantiation throughout the 
entire Maven build. This would mean, in the simple example above, that the 
'App' would always resolves ModuleB from the external repo (regardless of 
whether the reactor has built ModuleB or not in a separate 'dependency graph' 
in the reactor).



Joseph Leonard
Manager

Alfa

e: joseph.leon...@alfasystems.com | w: 
alfasystems.com
t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB


The contents of this communication are not intended to be binding or constitute 
any form of offer or acceptance or give rise to any legal obligations on behalf 
of the sender or Alfa. The views or opinions expressed represent those of the 
author and not necessarily 

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Greg Chabala]

My two cents:

a very large monobuild with 100s of modules


These are the kinds of problems you find when you're abusing the
multi-module system. Multi-module builds are a last resort for me, when
there are couplings between artifacts that need to be released
simultaneously, e.g. API and implementation artifacts. Do you have 100
artifacts that all depend on each other and need simultaneous release? That
sounds like a tightly coupled mess. Keep your builds in independent
projects instead of modules and avoid these issues.

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Joseph Leonard]

Thanks Nils,
maven-build-cache-extension looks very interesting generally – I will have a 
play with it.
With regards to this issue, the maven-build-cache-extension overview references 
“Subtree support for multimodule projects builds part of the codebase in 
isolation” which sounded similar to the solution I am proposing for this issue. 
Unfortunately, after enabling the maven-build-cache-extension I still hit the 
same issue.
Joe

On 2024/02/06 12:54:59 Nils Breunese wrote:
> I can’t comment on your question directly, but I just wanted to say that your 
> use case sounds like it could benefit from the Maven Build Cache Extension 
> (https://maven.apache.org/extensions/maven-build-cache-extension/).

>
> Just my 2 cents.
>
> Nils.
>
> > Op 6 feb 2024 om 11:40 heeft Joseph Leonard  het 
> > volgende geschreven:
> >
> > Hi all,
> >
> > It would be great to get any thoughts on whether the following is a defect:
> >
> >
> > Issue details:
> > tl;dr
> >
> > Maven can resolve dependencies either from:
> >
> >  *   an external repo
> >  *   a class directory of a module being built within the reactor
> >  *   a packaged jar of a module being built within the reactor
> >
> > If you run a concurrent multi-module build it is possible to get a race 
> > condition whereby the build of module Foo may resolve module Bar from 
> > either of the three resolution channels. This inconsistency can result in 
> > the Maven war plugin sometimes failing to build a functional war file. I 
> > would expect a consistent resolution would always take place.

> >
> > Full details
> > Scenario
> >
> > Consider you have a repo with the following structure:
> >
> >   App
> >
> > / \
> >
> >/   \
> >
> >   (compile scope)  (test scope)
> >
> >  /   \
> >
> >\/_   _\/
> >
> > ModuleA  TestSupportModule1
> >
> >/
> >
> >   /
> >
> >(compile scope)
> >
> > /
> >
> >   \/_
> >
> >ModuleB
> >
> >   /
> >
> >  /
> >
> >(test scope)
> >
> >/
> >
> >  \/_
> >
> > TestSupportModule2
> >
> > If you were to make a src code change to the following test support modules:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >
> > Then the minimum number of modules we need to build to verify the change 
> > set is OK is:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >  *   ModuleB
> >  *   App
> >
> > i.e. there is no requirement to build ModuleA because we know that none of 
> > the src code changes could impact the classpaths used in its maven build.

> >
> > We know that despite 'App' depending (transitively) on ModuleB there is no 
> > need for the 'App' build to wait for ModuleB to complete its build because 
> > the src code change to TestSupportModule2 will not impact any of the 
> > classpaths used in the App maven build. Therefore to get the most efficient 
> > build possible we ideally would invoke Maven to run with 2 threads and with 
> > instruction to build two distinct 'dependency graphs':

> >
> >  *   TestSupportModule1 followed by ModuleB
> >  *   TestSupportModule1 followed by App
> >
> > The following Maven command achieves exactly what we want because the 
> > reactor build order is based only on the direct (i.e. non-transitive) 
> > dependencies of the modules provided to the reactor in the build command. 
> > Therefore the absence of ModuleA results in two distinct 'dependency 
> > graphs':

> >
> > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> >
> > Note: In reality the code base I maintain has a very large monobuild with 
> > 100s of modules and this type of build optimisation makes a significant 
> > difference to the speed of our monobuild (we use 
> > https://github.com/gitflow-incremental-builder/gitflow-incremental-builder 
> > to automate the logic of determining which modules to include in the 
> > reactor based on our change set).

> >
> > Issue
> >
> > We have encountered an issue in the above scenario because the 'App' build 
> > has a race condition with the ModuleB build which will result in one of the 
> > following three outcomes:

> >
> >  *   If the 'App' build starts before the ModuleB build has compiled its 
> > src classes then the 'App' build will resolve ModuleB from the external 
> > repo (i.e. equivalent to ModuleB not being in the reactor at all)

> >  *   If the 'App' build starts after ModuleB has compiled its src classes 
> > but before it has packaged these classes into a jar then the 'App' build 
> > will resolve ModuleB's target/classes directory

> >  *   If the 'App' build starts after ModuleB has packaged its jar file then 
> > the 'App' build will resolve ModuleB's target/ModuleB.jar file.

> >
> > In many scenarios this dependency resolution inconsistency doesn't 
> > represent a challenge. However, it does 

RE: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Joseph Leonard]

Note that my diagram formatting is very hard to read in the default formatting 
on this mailing list. If you view my email in 'raw source' then it is easier to 
understand!

On 2024/02/06 10:40:14 Joseph Leonard wrote:
> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.

>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.

>
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':

>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':

>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).

>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:

>
>   *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)

>   *   If the 'App' build starts after ModuleB has compiled its src classes 
> but before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory

>   *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.

>
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
> empty ModuleB.jar file.

>
> Proposed solution
>
> Ideally we would like the Maven reactor to retain isolation between the two 
> distinct 'dependency graphs' it constructs at instantiation throughout the 
> entire Maven build. This would mean, in the simple example above, that the 
> 'App' would always resolves ModuleB from the external repo (regardless of 
> whether the reactor has built ModuleB or not in a separate 'dependency graph' 
> in the reactor).

>
>
>
> Joseph Leonard
> Manager
>
> Alfa
> 
> e: 

Re: Can a plugin permit a dependency override by the user setting a simple option?

[Jörg Schaible]

Hi Alexander,

On Tuesday, 6. February 2024, 02:39:09 CET Alexander Kriegisch wrote:
> Jörg,
> 
> I asked for a working example and not theory for a reason: The plugin
> POM already uses properties, and it simply does not work to override
> them.

Since you seem to use a 3rd party parent, is it public? Then you could tell us 
which one...

[snip example]

> Overriding the property in the project using the plugin does not seem to
> have any effect. I verified that the plugin POM still contains the
> property and the version number is not flattened in any way.
> 
> Is this even supposed to work like that? Are plugin properties
> overridable like this? It would be nice, but I guess they are not part
> of the reactor. That is also the reason why my project can use one
> version of a dependency and a plugin can use another one without them
> affecting each other.

This failed for me only, when I tried to make the version of a Maven extension 
configurable.

> So please, if you have a working example for what you say should work,
> please provide it, so I can reproducer what you recommend me to do.

Give me a head start by pointing me to the parent pom.

Regards,
Jörg



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

RE: Invoking POJO test from batch file not working

[Neil Aggarwal]

Nevermind.  I had the package name wrong.  I used the package name from my
main classes in addition to the test class.



Sorry for the confusion.



Thank you,

   Neil



--

Neil Aggarwal, 972-834-1565, http://propfinancing.com

We offer 30 year loans on single family houses!



*From:* Neil Aggarwal 
*Sent:* Tuesday, February 6, 2024 12:49 PM
*To:* 'Maven Users List' 
*Subject:* Invoking POJO test from batch file not working



I have a test class krazydad.slitherlink.SolverTest

It has a method public void testRun()



Reading the Maven page, that should be enough to run it as a POJO test.



If I use this command line to invoke Maven:

mvn test -Dtest=com._3dmathpuzzles.krazydad.slitherlink.SolverTest



It does not run and I get this output:

[INFO] Scanning for projects...

[INFO]

[INFO] -< com.3dmathpuzzles:3DMathPuzzlesWeb
>-

[INFO] Building 3DMathPuzzlesWeb 2.0.0

[INFO]   from pom.xml

[INFO] [ war
]-

[INFO]

[INFO] --- resources:3.3.0:resources (default-resources) @ 3DMathPuzzlesWeb
---

[INFO] Copying 0 resource

[INFO] Copying 42 resources

[INFO]

[INFO] --- compiler:3.10.1:compile (default-compile) @ 3DMathPuzzlesWeb ---

[INFO] Nothing to compile - all classes are up to date

[INFO]

[INFO] --- resources:3.3.0:testResources (default-testResources) @
3DMathPuzzlesWeb ---

[INFO] Copying 3 resources

[INFO]

[INFO] --- compiler:3.10.1:testCompile (default-testCompile) @
3DMathPuzzlesWeb ---

[INFO] Nothing to compile - all classes are up to date

[INFO]

[INFO] --- surefire:2.22.2:test (default-test) @ 3DMathPuzzlesWeb ---

[INFO]


[INFO] BUILD FAILURE

[INFO]


[INFO] Total time:  1.428 s

[INFO] Finished at: 2024-02-06T12:47:32-06:00

[INFO]


[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
on project 3DMathPuzzlesWeb: No tests were executed!  (Set
-DfailIfNoTests=false to ignore this error.) -> [Help 1]

[ERROR]

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR]

[ERROR] For more information about the errors and possible solutions,
please read the following articles:

[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



My pom has this to make sure junit and testNG are disabled:

  

org.apache.maven.plugins

maven-surefire-plugin



none:none

none:none



  



Any help on why this did not work?



Thank you,

   Neil



--

Neil Aggarwal, 972-834-1565, http://propfinancing.com

We offer 30 year loans on single family houses!

Re: How to completely override/replace parent's site.xml

[Jörg Schaible]

Hi Alexander,

On Tuesday, 6. February 2024, 02:18:36 CET Alexander Kriegisch wrote:
> Thanks Jörg,
> 
> but that does not answer my question. I do not want to generate a site
> for the parent. I am talking about the module using the parent POM. BTW,
> the parent POM is not even under my control, it is from another
> organisation.

OK, this is something I absolutely avoid. Typically I have a standalone parent 
for the company/entity/whatever that can be used for all projects sharing 
global stuff like emails, SCM URLs, URLs for distributions sites, versions, 
etc. And it is a great place for profile definitions with preconfigured plugins 
to build all kind of artifact types relevant for your entity.

> I am consuming it, because I like the defaults for plugin
> and dependency versions and configurations.

If I really need something, I copy it over and adjust it to our naming 
conventions. Always keep control of your own build.

I know that projects like spring-boot give a different advice, but typically 
you're then left alone with all the other configuration stuff. Then you will 
have to add entries to your own POMs everywhere e.g. for deployment, 
distribution, etc. and cannot use properties for the shared stuff like domains 
in emails, all kind of URLs. Maintenance is getting harder, if something of 
this changes.

> Only the site.xml annoys me.
> I do not want their menu structure and logo in my app's Maven site. The
> problem is, as I described: I do not know how to use the parent POM
> without also being forced to use the paren site.xml, which is attached
> to the artifact. This inheritance is nice, but I need a way to avoid,
> override or overrule it and make Maven Site Plugin use my own site.xml
> exclusively.

No help for this case, sorry.

Regards,
Jörg



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

Invoking POJO test from batch file not working

[Neil Aggarwal]

I have a test class krazydad.slitherlink.SolverTest

It has a method public void testRun()



Reading the Maven page, that should be enough to run it as a POJO test.



If I use this command line to invoke Maven:

mvn test -Dtest=com._3dmathpuzzles.krazydad.slitherlink.SolverTest



It does not run and I get this output:

[INFO] Scanning for projects...

[INFO]

[INFO] -< com.3dmathpuzzles:3DMathPuzzlesWeb
>-

[INFO] Building 3DMathPuzzlesWeb 2.0.0

[INFO]   from pom.xml

[INFO] [ war
]-

[INFO]

[INFO] --- resources:3.3.0:resources (default-resources) @ 3DMathPuzzlesWeb
---

[INFO] Copying 0 resource

[INFO] Copying 42 resources

[INFO]

[INFO] --- compiler:3.10.1:compile (default-compile) @ 3DMathPuzzlesWeb ---

[INFO] Nothing to compile - all classes are up to date

[INFO]

[INFO] --- resources:3.3.0:testResources (default-testResources) @
3DMathPuzzlesWeb ---

[INFO] Copying 3 resources

[INFO]

[INFO] --- compiler:3.10.1:testCompile (default-testCompile) @
3DMathPuzzlesWeb ---

[INFO] Nothing to compile - all classes are up to date

[INFO]

[INFO] --- surefire:2.22.2:test (default-test) @ 3DMathPuzzlesWeb ---

[INFO]


[INFO] BUILD FAILURE

[INFO]


[INFO] Total time:  1.428 s

[INFO] Finished at: 2024-02-06T12:47:32-06:00

[INFO]


[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
on project 3DMathPuzzlesWeb: No tests were executed!  (Set
-DfailIfNoTests=false to ignore this error.) -> [Help 1]

[ERROR]

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR]

[ERROR] For more information about the errors and possible solutions,
please read the following articles:

[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



My pom has this to make sure junit and testNG are disabled:

  

org.apache.maven.plugins

maven-surefire-plugin



none:none

none:none



  



Any help on why this did not work?



Thank you,

   Neil



--

Neil Aggarwal, 972-834-1565, http://propfinancing.com

We offer 30 year loans on single family houses!

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Tamás Cservenák]

Howdy,

To me this looks like Maven is not aware that the App depends on ModuleB...
Are they "plain dependency" linked? Or what kind of dependency we talk
about here?
In short: why would App start while ModuleB (upstream dep) is not done?
Something is fishy here.

T


On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race
> condition whereby the build of module Foo may resolve module Bar from
> either of the three resolution channels. This inconsistency can result in
> the Maven war plugin sometimes failing to build a functional war file. I
> would expect a consistent resolution would always take place.
>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support
> modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change
> set is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of
> the src code changes could impact the classpaths used in its maven build.
>
> We know that despite 'App' depending (transitively) on ModuleB there is no
> need for the 'App' build to wait for ModuleB to complete its build because
> the src code change to TestSupportModule2 will not impact any of the
> classpaths used in the App maven build. Therefore to get the most efficient
> build possible we ideally would invoke Maven to run with 2 threads and with
> instruction to build two distinct 'dependency graphs':
>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the
> reactor build order is based only on the direct (i.e. non-transitive)
> dependencies of the modules provided to the reactor in the build command.
> Therefore the absence of ModuleA results in two distinct 'dependency
> graphs':
>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with
> 100s of modules and this type of build optimisation makes a significant
> difference to the speed of our monobuild (we use
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> to automate the logic of determining which modules to include in the
> reactor based on our change set).
>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build
> has a race condition with the ModuleB build which will result in one of the
> following three outcomes:
>
>   *   If the 'App' build starts before the ModuleB build has compiled its
> src classes then the 'App' build will resolve ModuleB from the external
> repo (i.e. equivalent to ModuleB not being in the reactor at all)
>   *   If the 'App' build starts after ModuleB has compiled its src classes
> but before it has packaged these classes into a jar then the 'App' build
> will resolve ModuleB's target/classes directory
>   *   If the 'App' build starts after ModuleB has packaged its jar file
> then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
>
> In many scenarios this dependency resolution inconsistency doesn't
> represent a challenge. However, it does cause an issue in our case because
> the 'App' POM has its Maven packaging stanza configured to war and in the
> scenario where ModuleB's target/classes directory is resolved by the 'App'
> then this results in the resultant 'App' war file being packaged with a
> completely empty ModuleB.jar file.
>
> Proposed solution
>
> Ideally we would like the Maven reactor to retain isolation between the
> two distinct 'dependency graphs' it constructs at instantiation throughout
> the entire Maven build. This would mean, in the simple example above, that
> the 'App' would always resolves ModuleB from the external repo (regardless
> of whether the reactor has built ModuleB or not in a separate 'dependency
> graph' in 

Re: How to completely override/replace parent's site.xml

[Alexander Kriegisch]

That you avoid it, does not mean that everyone does. It also is not about the 
parent POM, but the parent site.xml forced upon me. A POM is never a problem, 
because everything from a POM can be overridden in consuming projects. My 
question focuses on ways to override things I do not like in site.xml, a case 
which can also occur within projects of the same organisation. I am still 
confident that there is a way to override or undefine what I do not need from 
the site.xml, which is why I asked here. If you do not know, you can just say 
so. Thanks for your advice to copy things from the parent POM and site I like, 
I did that already days ago. But it is not what I want, because 99% of the 
defaults are OK for me. I would not have asked, if this DRY violation would not 
bug me so much.

-- 
Alexander Kriegisch
https://scrum-master.de


Jörg Schaible schrieb am 07.02.2024 01:24 (GMT +07:00):

> Hi Alexander,
> 
> On Tuesday, 6. February 2024, 02:18:36 CET Alexander Kriegisch wrote:
>> Thanks Jörg,
>> 
>> but that does not answer my question. I do not want to generate a site
>> for the parent. I am talking about the module using the parent POM. BTW,
>> the parent POM is not even under my control, it is from another
>> organisation.
> 
> OK, this is something I absolutely avoid. Typically I have a standalone 
> parent 
> for the company/entity/whatever that can be used for all projects sharing 
> global stuff like emails, SCM URLs, URLs for distributions sites, versions, 
> etc. And it is a great place for profile definitions with preconfigured 
> plugins
> 
> to build all kind of artifact types relevant for your entity.
> 
>> I am consuming it, because I like the defaults for plugin
>> and dependency versions and configurations.
> 
> If I really need something, I copy it over and adjust it to our naming 
> conventions. Always keep control of your own build.
> 
> I know that projects like spring-boot give a different advice, but typically 
> you're then left alone with all the other configuration stuff. Then you will 
> have to add entries to your own POMs everywhere e.g. for deployment, 
> distribution, etc. and cannot use properties for the shared stuff like 
> domains 
> in emails, all kind of URLs. Maintenance is getting harder, if something of 
> this changes.
> 
>> Only the site.xml annoys me.
>> I do not want their menu structure and logo in my app's Maven site. The
>> problem is, as I described: I do not know how to use the parent POM
>> without also being forced to use the paren site.xml, which is attached
>> to the artifact. This inheritance is nice, but I need a way to avoid,
>> override or overrule it and make Maven Site Plugin use my own site.xml
>> exclusively.
> 
> No help for this case, sorry.
> 
> Regards,
> Jörg
> 
> 
> 
> -
> 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: Can a plugin permit a dependency override by the user setting a simple option?

[Alexander Kriegisch]

3rd party parent? Are you maybe mixing up my questions about different topics? 
There is not parent POM involved here, it is about a plugin and an application 
using it. Very simple and straightforward. I even gave an example of what does 
not work for me but you say should. So does it? If you do not know, it is OK. 
But if you want to help, the ball is in your court now. A counter-example 
showing me how to do what you suggested right would be most welcome.

-- 
Alexander Kriegisch
https://scrum-master.de

Jörg Schaible schrieb am 07.02.2024 01:32 (GMT +07:00):

> Hi Alexander,
> 
> On Tuesday, 6. February 2024, 02:39:09 CET Alexander Kriegisch wrote:
>> Jörg,
>> 
>> I asked for a working example and not theory for a reason: The plugin
>> POM already uses properties, and it simply does not work to override
>> them.
> 
> Since you seem to use a 3rd party parent, is it public? Then you could tell 
> us 
> which one...
> 
> [snip example]
> 
>> Overriding the property in the project using the plugin does not seem to
>> have any effect. I verified that the plugin POM still contains the
>> property and the version number is not flattened in any way.
>> 
>> Is this even supposed to work like that? Are plugin properties
>> overridable like this? It would be nice, but I guess they are not part
>> of the reactor. That is also the reason why my project can use one
>> version of a dependency and a plugin can use another one without them
>> affecting each other.
> 
> This failed for me only, when I tried to make the version of a Maven 
> extension 
> configurable.
> 
>> So please, if you have a working example for what you say should work,
>> please provide it, so I can reproducer what you recommend me to do.
> 
> Give me a head start by pointing me to the parent pom.
> 
> Regards,
> Jörg
> 
> 
> 
> -
> 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