fabric8io/fabric8 — pull request #2783 by zenlambda (2014-10-10 11:40:47+00:00)
Title: Enable fabric8:deploy for Mule Apps

This a revision of PR #2740 with apply the artifactBundleType override parameter to the requirements.json file. The issue was uncovered when unapplyied the "exclude artefact" work around previously applied the the mule quickstart. Excluding the artefact has the effect of disabling requirements.json.

If the artefact is included in the profile without this patch then the requirements.json will use the packaging type "mule" for too root dependency and not the type supplied by the user "zip". The fabric8 agent will see both the zip type in the properties file and mule type in requirements.json and fail because of the mule type. This patch fixes requirements.json so it is consistent with the agent properties file when artifactBundleType build property is used.

Additionally the maven plugin adds non-provided dependencies to the requirements.json, which is unnecessary since the app is self contained.

An omitDependenciesFromRequirements property was added to the maven plugin to allow the user to optionally prevent dependencies from being added to the requirements.json. This resolves #2769. A maven invoker test is included to verify this functionality. Documentation on the property is also added in the markdown file.

Original PR text:

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 empty whereas the mule mojo had added 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 pointing 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.