I found the root cause and I need your explanation and possible workaround
if it exists.
It is caused by maven-javadoc-plugin with goal "aggregate" running only in
reporting section of Parent POM, see [1].
See the build plan [2]. The children do not run Javadoc but the
maven-assembly-plugin fails in a child POM.
I also think that the call
MavenProject.getArtifact().getFile()
does not return *.war file nothing but "target/classes" in module
"audit-server". Expected is target/*.war.
Interesting thing is that another goal "javadoc" of the
maven-javadoc-plugin running in children does not cause this problem.
[1]:
<reporting>
<plugins>
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<reportSets>
<reportSet>
<id>aggregate-javadoc-report</id>
<inherited>false</inherited>
<reports>
<report>aggregate</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
[2]:
[INFO] Reactor Summary:
[INFO]
[INFO] Audit .............................................. SUCCESS [
37.068 s]
[INFO] audit-setup-integration-tests ...................... SUCCESS [
2.589 s]
[INFO] audit-logger-constants ............................. SUCCESS [
3.192 s]
[INFO] audit-annotations .................................. SUCCESS [
4.013 s]
[INFO] audit-util ......................................... SUCCESS [
3.405 s]
[INFO] audit-reader-api ................................... SUCCESS [
8.938 s]
[INFO] audit-domain ....................................... SUCCESS [
8.295 s]
[INFO] audit-reader ....................................... SUCCESS [
7.608 s]
[INFO] audit-context ...................................... SUCCESS [
1.037 s]
[INFO] audit-context-api .................................. SUCCESS [
4.038 s]
[INFO] audit-logger-api ................................... SUCCESS [
5.261 s]
[INFO] auditlog-providers ................................. SUCCESS [
1.038 s]
[INFO] auditlog-sessionscoped-provider .................... SUCCESS [
2.876 s]
[INFO] auditlog-requestscoped-provider .................... SUCCESS [
2.870 s]
[INFO] auditlog-qualified-provider ........................ SUCCESS [
2.908 s]
[INFO] audit-logger ....................................... SUCCESS [
13.374 s]
[INFO] audit-logger-providers ............................. SUCCESS [
2.403 s]
[INFO] audit-logger-console-provider ...................... SUCCESS [
2.861 s]
[INFO] audit-context-factory .............................. SUCCESS [
7.909 s]
[INFO] audit-logger-jpa-provider .......................... SUCCESS [
5.911 s]
[INFO] audit-logger-distributed-provider .................. SUCCESS [
6.136 s]
[INFO] audit-flyway ....................................... SUCCESS [
5.167 s]
[INFO] audit-server ....................................... FAILURE [
1.287 s]
[INFO] bom-audit-direct-logger ............................ SKIPPED
[INFO] bom-audit-direct-loader ............................ SKIPPED
[INFO] Audit Plugins BOM .................................. SKIPPED
[INFO] bom-audit-distributed-logger ....................... SKIPPED
[INFO] bom-audit-distributed-loader ....................... SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
On Wed, Mar 28, 2018 at 10:08 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
> Hi Tibor,
>
> On 28/03/18 21:56, Tibor Digana wrote:
>
>> It cannot be dependency issue because as I said before, (mvn install)
>> works
>> fine.
>>
>
> Exactly that's the point..that's happing occasiaonally that you do an mvn
> install which means modules will be installed into the local repository and
> if the build continues to the point where the dependency is need it will be
> solved via local repository (and not from the reactor) and in the end the
> build is successfully.
>
> The point is that I assume that during the release you don't use -T ...
>
> So during the release the build order is not correct order of modules and
> it fails cause at the point of the dependency this dependency is not built
> yet...
>
> I'm not 100% sure but I would expect that a dependency is missing in the
> for the assembly module....
>
> Can you check your build by cleaning your local cache and simply do a:
>
> mvn clean package
>
> which must be successful. Single thread nothing more ...I assume that your
> build will fail...
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> Deploy is one phase after. We have site and release extra which breaks the
>> build.
>>
>> On Wed, Mar 28, 2018 at 8:46 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
>> wrote:
>>
>> Hi,
>>>
>>> On 28/03/18 20:27, Tibor Digana wrote:
>>>
>>> yes, audit-domain is jar, but why the assembly works with mvn install,
>>>> but
>>>> why it does not work within release?
>>>>
>>>>
>>> This sounds like a dependency issue between the modules.....
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>>> No, I do not use -T, no multithreading.
>>>
>>>> It's clear to me that it looks like the domain has not been packaged but
>>>> this should not happen because audit-server is dependent on audit-domain
>>>> transitively.
>>>> I can check the build plan.
>>>>
>>>> On Wed, Mar 28, 2018 at 8:21 PM, Robert Scholte <rfscho...@apache.org>
>>>> wrote:
>>>>
>>>> based on the name 'audit-domain' I would expect it to be a jar.
>>>>
>>>>> Are you running with multiple threads and could it be that audit-domain
>>>>> hasn't been packaged yet when making your war/assembly?
>>>>> Looks like a ratrace to me.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On Wed, 28 Mar 2018 20:14:29 +0200, Tibor Digana <
>>>>> tibordig...@apache.org
>>>>>
>>>>>>
>>>>>> wrote:
>>>>>
>>>>> I am not rewriting the POM Model. I am just a Maven user.
>>>>>
>>>>> My project has WAR packaging.
>>>>>>
>>>>>> On Wed, Mar 28, 2018 at 7:16 PM, Robert Scholte <rfscho...@apache.org
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Not sure if this is the answer you are looking for, but it is good to
>>>>>>
>>>>>> know:
>>>>>>>
>>>>>>> https://maven.apache.org/plugins/maven-compiler-plugin/xref/
>>>>>>> org/apache/maven/plugin/compiler/CompilerMojo.html#L170
>>>>>>>
>>>>>>> here the outputdirectory is bound to the artifact.
>>>>>>> This is *only* useful when building up the classpath; now you can
>>>>>>> simply
>>>>>>> say: give me the file for every artifact, outputdirectory and jar are
>>>>>>> both
>>>>>>> fine.
>>>>>>> I don't like this, but that's how it works right now and rewriting it
>>>>>>> will
>>>>>>> have a huge impact.
>>>>>>> During jar:jar the jar should be attached to this artifact.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>> On Wed, 28 Mar 2018 08:08:48 +0200, Tibor Digana <
>>>>>>> tibordig...@apache.org
>>>>>>>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>> I have checked the configuration of release plugin again and the
>>>>>>> goals
>>>>>>> are
>>>>>>>
>>>>>>> set correctly, I think:
>>>>>>>
>>>>>>>>
>>>>>>>> <goals>deploy post-site site:stage site:stage-deploy
>>>>>>>> -Dwagon.webdav.continueOnFailure=true</goals>
>>>>>>>>
>>>>>>>> Why then the code *MavenProject.getArtifact().get**File()* returns
>>>>>>>> *target/classes* instead of real artifact* target/*.jar*?
>>>>>>>>
>>>>>>>>
>>>>>>>> The execution of assembly plugin is bound to the phase:
>>>>>>>>
>>>>>>>> <phase>pre-integration-test</phase>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Tibor
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 27, 2018 at 8:32 PM, Robert Scholte <
>>>>>>>> rfscho...@apache.org
>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> looks to me something during the packaging failed.
>>>>>>>>> As if MavenProject.getArtifact().getFile() still points to the
>>>>>>>>> output
>>>>>>>>> directory instead of the jar.
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, 27 Mar 2018 09:52:03 +0200, Tibor Digana <
>>>>>>>>> tibordig...@apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There is a similar issue in our Jira
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/MASSEMBLY-411
>>>>>>>>>
>>>>>>>>> Nobody has seen this? Any opinion about this or workaround?
>>>>>>>>>> Everything would help!
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 26, 2018 at 9:21 PM, Tibor Digana <
>>>>>>>>>> tibordig...@apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have a specific problem with Maven Assembly Plugin to run during
>>>>>>>>>> (mvn
>>>>>>>>>>
>>>>>>>>>> release:perform).
>>>>>>>>>>
>>>>>>>>>> If I run the build (mvn install) the plugin works as expected.
>>>>>>>>>>>
>>>>>>>>>>> I've got this error while cutting release:
>>>>>>>>>>>
>>>>>>>>>>> Failed to execute goal org.apache.maven.plugins:
>>>>>>>>>>> maven-assembly-plugin:3.1.0:single
>>>>>>>>>>> (web-archive-h2-integration-te
>>>>>>>>>>> sts)
>>>>>>>>>>> on
>>>>>>>>>>> project audit-server: Failed to create assembly: Error adding
>>>>>>>>>>> file
>>>>>>>>>>> 'com.scheidtbachmann.shared.audit:audit-domain:jar:without-
>>>>>>>>>>> validation:3.0.0-RC1'
>>>>>>>>>>> to archive: E:\vcs\gitlab\release\release-
>>>>>>>>>>> 3.0.0-RC1\target\checkout\audi
>>>>>>>>>>> t-domain\target\classes
>>>>>>>>>>> isn't a file.
>>>>>>>>>>>
>>>>>>>>>>> Have you seen such error?
>>>>>>>>>>> Do you know any workaround?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [ERROR] Failed to execute goal org.apache.maven.plugins:
>>>>>>>>>>> maven-assembly-plugin:3.1.0:single
>>>>>>>>>>> (web-archive-h2-integration-te
>>>>>>>>>>> sts)
>>>>>>>>>>> on
>>>>>>>>>>> project audit-server: Failed to create assembly: Error adding
>>>>>>>>>>> file
>>>>>>>>>>> 'com.scheidtbachmann.shared.audit:audit-domain:jar:without-
>>>>>>>>>>> validation:3.0.0-RC1'
>>>>>>>>>>> to archive:
>>>>>>>>>>> org.apache.maven.lifecycle.LifecycleExecutionException:
>>>>>>>>>>> Failed
>>>>>>>>>>> to
>>>>>>>>>>> execute goal org.apache.maven.plugins:maven
>>>>>>>>>>> -assembly-plugin:3.1.0:single
>>>>>>>>>>> (web-archive-h2-integration-tests) on project audit-server:
>>>>>>>>>>> Failed
>>>>>>>>>>> to
>>>>>>>>>>> create assembly: Error adding file 'com.scheidtbachmann.shared.
>>>>>>>>>>> audit:audit-doma
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.MojoExecutor.execute(
>>>>>>>>>>> MojoExecutor.java:213)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.MojoExecutor.execute(
>>>>>>>>>>> MojoExecutor.java:154)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.MojoExecutor.execute(
>>>>>>>>>>> MojoExecutor.java:146)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.LifecycleModuleBuilder.
>>>>>>>>>>> buildProject(LifecycleModuleBuilder.java:117)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.LifecycleModuleBuilder.
>>>>>>>>>>> buildProject(LifecycleModuleBuilder.java:81)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.builder.singlethreaded.
>>>>>>>>>>> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.LifecycleStarter.
>>>>>>>>>>> execute(LifecycleStarter.java:128)
>>>>>>>>>>> at org.apache.maven.DefaultMaven.
>>>>>>>>>>> doExecute(DefaultMaven.java:30
>>>>>>>>>>> 9)
>>>>>>>>>>> at org.apache.maven.DefaultMaven.
>>>>>>>>>>> doExecute(DefaultMaven.java:19
>>>>>>>>>>> 4)
>>>>>>>>>>> at org.apache.maven.DefaultMaven.
>>>>>>>>>>> execute(DefaultMaven.java:107)
>>>>>>>>>>> at org.apache.maven.cli.MavenCli.
>>>>>>>>>>> execute(MavenCli.java:993)
>>>>>>>>>>> at org.apache.maven.cli.MavenCli.
>>>>>>>>>>> doMain(MavenCli.java:345)
>>>>>>>>>>> at org.apache.maven.cli.MavenCli.
>>>>>>>>>>> main(MavenCli.java:191)
>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>>>>>>>> Method)
>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>>>>>>>>> NativeMethodAccessorImpl.java:62)
>>>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>>>>>>>>> DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.
>>>>>>>>>>> launchEnhanced(Launcher.java:289)
>>>>>>>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.
>>>>>>>>>>> launch(Launcher.java:229)
>>>>>>>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.
>>>>>>>>>>> mainWithExitCode(Launcher.java:415)
>>>>>>>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.
>>>>>>>>>>> main(Launcher.java:356)
>>>>>>>>>>> Caused by: org.apache.maven.plugin.MojoExecutionException:
>>>>>>>>>>> Failed
>>>>>>>>>>> to
>>>>>>>>>>> create assembly: Error adding file 'com.scheidtbachmann.shared.
>>>>>>>>>>> audit:audit-domain:jar:without-validation:3.0.0-RC1' to archive:
>>>>>>>>>>> E:\vcs\gitlab\release\release-3.0.0-RC1\target\checkout\audi
>>>>>>>>>>> t-domain\target\classes
>>>>>>>>>>> isn't a
>>>>>>>>>>> at org.apache.maven.plugins.assembly.mojos.
>>>>>>>>>>> AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:532)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.mojos.
>>>>>>>>>>> SingleAssemblyMojo.execute(SingleAssemblyMojo.java:61)
>>>>>>>>>>> at org.apache.maven.plugin.Defaul
>>>>>>>>>>> tBuildPluginManager.executeMoj
>>>>>>>>>>> o(
>>>>>>>>>>> DefaultBuildPluginManager.java:134)
>>>>>>>>>>> at org.apache.maven.lifecycle.int
>>>>>>>>>>> ernal.MojoExecutor.execute(
>>>>>>>>>>> MojoExecutor.java:208)
>>>>>>>>>>> ... 20 more
>>>>>>>>>>> Caused by: org.apache.maven.plugins.assem
>>>>>>>>>>> bly.archive.ArchiveCreationException:
>>>>>>>>>>> Error adding file 'com.scheidtbachmann.shared.au
>>>>>>>>>>> dit:audit-domain:jar:without-validation:3.0.0-RC1'
>>>>>>>>>>> to archive: E:\vcs\gitlab\release\release-
>>>>>>>>>>> 3.0.0-RC1\target\checkout\audi
>>>>>>>>>>> t-domain\target\classes
>>>>>>>>>>> isn't a file.
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>> AddArtifactTask.asFile(AddArtifactTask.java:180)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>> AddArtifactTask.execute(AddArtifactTask.java:132)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>> AddDependencySetsTask.addNormalArtifact(AddDependencySetsTas
>>>>>>>>>>> k.java:263)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>> AddDependencySetsTask.addDependencySet(AddDependencySetsTask
>>>>>>>>>>> .java:175)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>> AddDependencySetsTask.execute(AddDependencySetsTask.java:120)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.phase.
>>>>>>>>>>> DependencySetAssemblyPhase.execute(DependencySetAssemblyPhas
>>>>>>>>>>> e.java:104)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.
>>>>>>>>>>> DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchive
>>>>>>>>>>> r.java:181)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.mojos.
>>>>>>>>>>> AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:478)
>>>>>>>>>>> ... 23 more
>>>>>>>>>>> Caused by: org.codehaus.plexus.archiver.ArchiverException:
>>>>>>>>>>> E:\vcs\gitlab\release\release-3.0.0-RC1\target\checkout\audi
>>>>>>>>>>> t-domain\target\classes
>>>>>>>>>>> isn't a file.
>>>>>>>>>>> at org.codehaus.plexus.archiver.A
>>>>>>>>>>> bstractArchiver.addFile(
>>>>>>>>>>> AbstractArchiver.java:442)
>>>>>>>>>>> at org.codehaus.plexus.archiver.A
>>>>>>>>>>> bstractArchiver.addFile(
>>>>>>>>>>> AbstractArchiver.java:369)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.archiver.
>>>>>>>>>>> AssemblyProxyArchiver.addFile(AssemblyProxyArchiver.java:425)
>>>>>>>>>>> at org.apache.maven.plugins.assembly.archive.task.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
