fabric8io/fabric8 — pull request #2740 by zenlambda (2014-10-06 16:19:03+00:00)
Title: Enable fabric8:deploy for Mule Apps

This change actually applies the type override functionality to the mule example. This is necessary to make fabric8:deploy work because the previous workaround (disabling artefact inclusion) effectively disables the uploading of the project artifacts and profile to the fabric controller.

In order to make the deployer work a fix had to be applied to the deployer mojo. It turns out that the [mule plugin does not make the zip the primary artifact, but makes it an attachment](https://github.com/zenlambda/maven-mule-plugin/blob/master/src/main/java/org/mule/tools/maven/plugin/MuleMojo.java#L106). Before the fix this would cause an error because the deploy plugin forks a lifecycle before execution meaning that the state of the project object it has when it executes is different from what other mojos saw. Crucially, the attachedArtifacts list in the project object will be object whereas the mule mojo had add a list to the zip. The fix adds an ["executedProject" member](http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations) so that the project state from the forked lifecycle can be aquired. The executedProject member is documented in the linked page as a note next to the 'execute' mojo annotation.

I also noticed a coding error in the maven test where stub poms where point to the wrong code. This led to the discovery the that packaging types also affect url and key prefixes for the deployer. I corrected the tests accordingly.