Project build lifecycle mapping

Skip to end of metadata
Go to start of metadata

Areas of improvement

"Flakiness" of the default project build lifecycle mapping

"Default" means no explicit project build lifecycle mapping configuration in pom.xml.

This covers problems with missing or incorrect workspace project configuration after project import and/or project configuration update. Missing/stale generated sources and files under target/classes also fail under this category.

Our goal is to make sure m2e either works or fails fast and with clear error message. This includes changes to pom.xml after initial project import.

It is important to understand that default project build lifecycle will not work for all projects. Some projects will require explicit (a.k.a "custom") build lifecycle mapping configuration and some projects will not work unless new m2e extensions are made available to support these projects. In either case m2e should provide clear explanation of the problem and provide guidance to remediate it.

Automatic discovery and installation of require project configurators

Project configurators framework introduced in m2e 0.9.4 and customizable build lifecycle mapping introduced in 0.10.0 require users to manually install m2e extensions (i.e. Eclipse features and plugins) to work. In order to be able to retire "generic" project build lifecycle mapping, m2e needs to discover and install (or at least offer) additional required project configurators automatically.

Specific changes

Introduce notions of "interesting" and "not-interesting" mojo executions

Overall m2e goal is to enable developers write and test code inside Eclipse IDE. This means we can ignore mojos bound to certain build phases because they (almost certainly) do not contribute anything towards compilation or running the tests.

Maven 3.0 Default Lifecycle

marks interesting and not-interesting phases

  Phase Description
validate validate the project is correct and all necessary information is available.
initialize initialize build state, e.g. set properties or create directories.
generate-sources generate any source code for inclusion in compilation.
process-sources process the source code, for example to filter any values.
generate-resources generate resources for inclusion in the package.
process-resources copy and process the resources into the destination directory, ready for packaging.
compile compile the source code of the project.
process-classes post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources generate any test source code for inclusion in compilation.
process-test-sources process the test source code, for example to filter any values.
generate-test-resources create resources for testing.
process-test-resources copy and process the resources into the test destination directory.
test-compile compile the test source code into the test destination directory
process-test-classes post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify run any checks to verify the package is valid and meets quality criteria.
install install the package into the local repository, for use as a dependency in other projects locally.
deploy done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Per-packaging type build lifecycle mapping

Project packaging defines plugin goals bound to project build lifecycle by default and at least as of Maven 3.0 it is not possible to "unbind" such plugin goals. In m2e 0.12.0 it is already possible to associate default lifecycle mapping strategy with project packaging type and this will become a requirement. In other words, default lifecycle mapping will be provided for known, supported packaging types only.

If project uses packaging type unknown to m2e, the user will have to either install additional Eclipse plugins that provide support for this packaging type or configure lifecycle mapping explicitly.

TODO decide what to do if there are multiple "default" strategies. We can provide UI that will let uses pick one, similar to Java runtime environments. Alternatively,we can force users to configure lifecycle mapping explicitly.

Explicit lifecycle mapping inheritance

Explicit lifecycle mapping configuration defined in a parent pom.xml file currently applies to all child modules regardless of their packaging type. This proved to be problematic when same parent has children with significantly different packaging and thus lifecycle mapping requirement. For example, nexus-oss codebase is a mixture of projects with jar, nexus-plugin and war packagings. This is likely a very common arrangement and m2e needs to provide direct support for it.

All interesting mojo executions must be accounted for

Project build lifecycle strategies will generally require that all interesting mojos bound to the project build lifecycle are supported either by the strategy itself or by a project configurator enabled for the project. Unsupported interesting mojos will be treated as project configuration errors (with corresponding red cross on the project) and the user will be required to either install/configure additional project configurators or explicitly mark the mojos as not-interesting in the explicit project build lifecycle mapping.

This requires new API to determine what interesting mojo executions are covered by lifecycle mapping strategy and what are not.

TODO modello, antlr and few other code generation mojos could be handled by single parametrized project configurator. Investigate how to make discovery and installation of such project configurator possible.

plexus-build-api support

Maven plugin metadata does not provide direct/explicit way to tell if a plugin is expected to work inside Eclipse workspace or not. Dependency on plexus-build-api does not provide strong-enough indication if it is sufficient to execute mojos or additional setup is required. For example, it is enough to execute maven-resources-plugin during the build, while modello-maven-plugin requires a project configurator to setup JDT source folders.

This means m2e can't use plexus-build-api as the primary indicator, but explicit project configurator will be required for each plugin. TODO investigate possibility of metatada-only to parametrize common/shared project configurator for multiple maven plugins, sort of like current mojoExecution, only generic, unrelated to any particular project.

Given how common resource-plugin is, it probably makes sense to hardcode it into m2e-core.

For other plugins,

Discovery and installation of project configurators and lifecycle mapping strategies

For default lifecycle mapping, discovery will be based both on project packaging type and plugins goals bound to build lifecycle explicitly. Based on our preliminary analysis, packaging types and plugin goals appear to map to P2 capabilities nicely.

For explicit lifecycle mapping, discovery will be based on configured mapping strategy and ids of enabled project configurators. Likewise, p2 capabilities appear to provide appropriate abstraction. m2e lifecycle mapping configuration will have to capture information about versions of mapping strategy and project configurator.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.