Docker lifecycle #433
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| <component-set> | ||
| <components> | ||
| <component> | ||
| <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role> | ||
| <role-hint>docker</role-hint> | ||
| <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation> | ||
| <configuration> | ||
| <lifecycles> | ||
| <lifecycle> | ||
| <id>default</id> | ||
| <!-- | ||
| phase mappings extend from jar mappings | ||
| http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Default_Lifecycle_Bindings_-_Packaging_ejb__ejb3__jar__par__rar__war | ||
| --> | ||
| <phases> | ||
| <generate-source>${project.groupId}:${project.artifactId}:${project.version}:source</generate-source> | ||
| <process-resources>org.apache.maven.plugins:maven-resources-plugin:2.7:resources</process-resources> | ||
| <compile>org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile</compile> | ||
| <process-test-resources>org.apache.maven.plugins:maven-resources-plugin:2.7:testResources</process-test-resources> | ||
| <test-compile>org.apache.maven.plugins:maven-compiler-plugin:3.5.1:testCompile</test-compile> | ||
| <test>org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test</test> | ||
| <package>org.apache.maven.plugins:maven-jar-plugin:2.6:jar,${project.groupId}:${project.artifactId}:${project.version}:build</package> | ||
| <pre-integration-test>${project.groupId}:${project.artifactId}:${project.version}:start</pre-integration-test> | ||
| <integration-test>org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test</integration-test> | ||
| <!-- post-integration-test is opportunity for code coverage, such as jacoco, to collect statistics from running container --> | ||
| <post-integration-test></post-integration-test> | ||
| <verify>${project.groupId}:${project.artifactId}:${project.version}:stop,org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify</verify> | ||
|
There was a problem hiding this comment. Any particular reason why "stop" is not in I ask because if you only run There was a problem hiding this comment. Ok, just checked it: any extra post-integration binding goes after the default one (strange behaviour btw, would expect for But if you need a customization you can still bind e.g. jacoco to the I adapted the lifecycle accordingly and also removed There was a problem hiding this comment. It's documented that order of plugins is those specified by packaging, followed by order declared in pom. Maven Failsafe, usually binds with integration-test and verify. Jacoco report-integration-mojo likewise binds to verify. So, current practice is that running and actually verifying integration tests requires using verify phase. I was guided in my choices by what other container technologies use; Cargo recommends associating start goal with pre-integration-test and stop goal with post-integration-test. Tomcat maven plugin recommends associating run-war-only goal with pre-integration-test and shutdown goal with post-integration-test. I would prefer not to bind jacoco:dump with integration-test. This goal must be called after failsafe runs the tests and before the container is stopped. It's often difficult to ensure the ordering of goals within a phase, particularly when parent poms and profiles are involved. You already understand the problem with binding to post-integration-test. There was a problem hiding this comment.
That is exactly now what I suggest, too. I know there wont be a perfect solution for the lifecycle choice, but as an alternative you could use a preStop command to get data out of the container before it stops. Or you mount the the directory where jacoco dumps its data as a volume dir within wdyt, would this be ok ? Btw, I introduced two other packagings, too: 'docker-build' for only building images and 'docker-tar' for creating a docker tar as artifact (Dockerfile + support files). Thanks btw for the nice PR, makes things quite simpler :) There was a problem hiding this comment. Even after moving Unfortunately, mounting the directory is a non-starter in our build chain. Let me look at preStop tonight. There was a problem hiding this comment.
Yes, you are right, one would have to call There was a problem hiding this comment. We use jacoco:dump to connect to port 6300. Reviewing my personal usage of phases: mostly it's mvn clean install. For jenkins it's mvn clean deploy. If I want to build without releasing to my local respository it's mvn clean verify. I use verify because I want to look at the jacoco and failsafe reports generated from the integration tests. Occasionally while debugging an aspect of the build I might use mvn package. I almost never use any of the really long named phases; they take too long to type and I usually mis-remember the actual name. I suspect that these phases are more about sequencing than about the expectation of use from the command line. In the Maven Introduction to the Build Lifecycle, you don't see any of the pre-*, post-*, or process-* phases mentioned until the reference section. There was a problem hiding this comment. ok, you convinced me ;-). I will put The last question is whether Will revert to you original suggetion. thanks :) There was a problem hiding this comment. Thanks for working through this with me. I appreciate the time you've taken. I'm now working with maven team to update lifecycle documentation. |
||
| <deploy>${project.groupId}:${project.artifactId}:${project.version}:push</deploy> | ||
| </phases> | ||
| </lifecycle> | ||
| </lifecycles> | ||
| </configuration> | ||
| </component> | ||
| </components> | ||
| </component-set> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, got your intention to leave the hook free for others to kick in. However, putting it into
verifyhas the nasty side effect thatmvn integration-testwont call this phase so the container keeps running. It also feels more natural to put it intopreandpostgoals. Couldn't a user still bind to thepost-integration-testphase so that both goals are called ?