In https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41 <https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/lifecycle-mapping-metadata.xml#L41> we have referenced the explicit lifecycle mapping id from https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62 <https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L62> which references the class https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java <https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java>. The latter is empty. I am wondering why the lifecycle mapping extension point was ever necessary because we do nothing specific in ContentPackageLifecycleMapping.java <https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/ContentPackageLifecycleMapping.java> and m2e should be able to come up with a a default lifecycle id based on the configured plugin executions.
If there is no good reason for that, I would rather get rid of the explicit lifecycle mapping id and only configure the plugin execution similar to the one for maven-bundle-plugin. @Georg Henzler: Because the original source code was contributed by you in https://issues.apache.org/jira/browse/SLING-3100 <https://issues.apache.org/jira/browse/SLING-3100> maybe you can share your thoughts. Thanks, Konrad
