Skip to content

Conversation

hferentschik
Copy link
Contributor

During the 4.0.2.Beta1 release we had another Maven issue :(
This time the assembly did not complete using Maven 3.x. The reason was that for some reason the forked assembly build did not have all test dependencies set.
Anyways, this is an attempt to this this by aligning with recommendations from http://www.sonatype.com/books/mvnref-book/reference/assemblies-set-dist-assemblies.html. The old Core 3.6 build also uses this approach. It is still not optimal, because to make it work you have to repeat dependencies in the pom of the distribution module. Also the process of actually including dependencies in the assembly descriptor (dist.xml) is as fiddly as before. It seems there is no perfect solution for this.
A nice side effect of this approach is that the assembly is bound to a lifecycle phase. This means that the assembly plugin is not forking the build and re-running the build up to the package phase. It's a considerable time gain for deploying.
WDYT?

…dicated distribution module

Within the assembly we cannot use moduleset anymore we have to use dependencyset. See also discussion under http://www.sonatype.com/books/mvnref-book/reference/assemblies-set-dist-assemblies.html
This is also not a perfect solution, because I have for example to repeat the dependencies in the distribution pom in oder to use them in the distribution.
This is the same as suggested in http://www.sonatype.com/books/mvnref-book/reference/assemblies-set-dist-assemblies.html and the same we do in Core 3.6
Not perfect, but it is very tiresome to fight maven all the time
…dicated distribution module

The deploy plugin doe not have to call assembly anymore directly. Instead the assembly is bound to a life cycle in the distribution module
Also updating some plugin version (compiler plugin)
@gunnarmorling
Copy link
Member

Seems good, I could build the distribution locally without problems with mvn assembly:assembly from within the distribution module. I think specifying the optional dependencies again in the distribution's pom.xml makes actually sense in a way, as there might be optional dependencies that shouldn't go into the distribution. But there is still some redundancy in the distribution's pom.xml and the dist.xml, sigh.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants