- Areas of improvement
- "Flakiness" of the default project build lifecycle mapping
- Automatic discovery and installation of require project configurators
- Specific changes
- Introduce notions of "interesting" and "not-interesting" mojo executions
- Per-packaging type build lifecycle mapping
- Explicit lifecycle mapping inheritance
- All interesting mojo executions must be accounted for
- plexus-build-api support
- Discovery and installation of project configurators and lifecycle mapping strategies
|"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.
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.
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.
marks interesting and not-interesting phases
|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.|
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 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.
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.
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,
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.