THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
DECISION: The 5.0.0 POM will provide the ability to define custom lifecycles directly within the POM
AFFECTS:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
DECISION: The 5.0.0 POM will provide the ability to override and completely clear the plugin bindings against individual lifecyclesand completely clear the plugin bindings against individual lifecycles
AFFECTS:
Custom scopes
One of the blockers for custom scopes has been the requirement that the 4.0.0 POM be used for both the declarative build description and the consumer's dependency graph construction. Any custom scopes introduced into the POM would either break or confuse clients that relied on the assumed 5 scopes defined in the 4.0.0 POM. The Project Dependency Trees schema removes use case of consumption of the POM by consumers of the artifacts produced by the project. This has the effect of completely removing the limits on scopes. The 4.0.0 scopes will likely remain the conventions as interoperability with older plugins as well as conventions in the default configurations of plugins will simplify their use, but in those cases where a project needs to define and consume its own scopes it should be possible to permit it.
DECISION: The 5.0.0 POM will allow the definition and consumption of custom scopes directly within the POM, parent POM, mixins, or templates
AFFECTS:
The system scope was a Java-centric special scope experiment that hit issues with consumption of dependencies across multiple platforms.
DECISION: The 5.0.0 POM will not provide any special case behaviour for a scope named system
AFFECTS:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Build vs Reporting
If we look at the two use cases of building with Maven 2/3 there are actually two distinct use-cases:
- Building the project artifacts
- Building the project site/documentation
This was shaped by having two configuration sections in the 4.0.0 POM, build and reporting. One of the issues with these two sections is that they did not have parity of configurability. Specifically, the reporting section did not have a pluginManagement. The solution of having the pluginManagement from the build section apply to the reporting section feels incorrect as now the child element of one is affecting another.
DECISION: The 5.0.0 POM will treat global plugin configuration defaults as a top level concern and have a tag equivalent to pluginManagement at the top level of the POM.
AFFECTS:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
If we seek to find a generic solution to the split between the build and reporting sections in the POM, it becomes apparent that these are all really just ways of defining bindings of plugins to the phases of various lifecycles. The build section defines the bindings against the default lifecycle, while the reporting section defines the bindings against the site lifecycle (Note: this is a simplification as the reporting plugins are actually partly invoked by the site plugin and thus are not actually specifically bound to the lifecycle, rather the site:site goal is bound to the site phase of the site lifecycle and that goal is responsible for invoking the reporting plugin goals)
As a side-effect of making it easier to produce custom lifecycles, we probably need to be able to make it easier to manage the bindings of plugins for the custom lifecycles.
DECISION: The 5.0.0 POM will remove the distinction between build and reporting relying rather on lifecycle specific binding declarations
AFFECTS:
TODO write this up... I'm just dumping stuff I have done on the mail thread here to make it easier to collaborate:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<project modelVersion="5.0.0" [groupId="..."] artifactId="..." [version="..."] packagingtemplate="..."> [<parent groupId="..." artifactId="..." [version="..."] [relativePath="...']/> [<mixin groupId="..." artifactId="..." [version="..."]/>] [<mixin groupId="..." artifactId="..." [version="..."]/>] ... [<mixin groupId="..." artifactId="..." [version="..."]/>] [<lifecycle id="..." mode="override|inherit"> <phase id="..." [after="..." | before="..."]/> <phase id="..." [after="..." | before="..."]/> ... <phase id="..." [after="..." | before="..."]/> </lifecycle>] [<lifecycle id="..."> ... </lifecycle>] ... [<lifecycle id="..."> ... </lifecycle>] [<scope id="compile" [mode="override|inherit"]> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> <!-- type is mandatory--> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> ... <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> </scope>] [<scope id="..."> ... </scope>] ... [<scope id="..."> ..."> ... </scope>] [<extensions [mode="override|inherit"]> <extension groupId="... </scope>] " artifactId="... [<scope id" version="..."/> ... </scope>extensions>] [<plugins [mode="override|inherit"]> <!-- this is what pluginManagement was --> <plugin groupId="..." artifactId="..." version="..."> ... </plugin> ... </plugins>] [<bindings [mode="override|inherit"]> <!-- this is what plugins was, we make explicit here that this is the binding of executions into the lifecycles --> </bindings>] [<platform id="..." [mode="override|inherit"]> <activation> <!-- define how we determine that this platform can be built in the current environment --> </activation> <!-- allow platform specific mixins --> [<mixin groupId="..." artifactId="..." [version="..."]/>] <!-- allow platform specific lifecycles --> [<lifecycle id="..."> ... </lifecycle>] <!-- allow platform specific dependencies --> [<scope> ... </scope>] <!-- allow platform specific bindings... but plugin management is from the root only --> [<bindings> ... </bindings>] <!-- allow most of the other root tags except platform and packaging and deployment config --> </platform>] [<platform id="..."> ... </platform>] ... [<platform id="..."> ... </platform>] <!-- packaging is only allowed in poms with an id of "parent" or "mixin". It allows a parent/mixin to be used by different packaging ids and define specialized defaults --> [<packaging id="..."> [<mixin groupId="..." artifactId="..." [version="..."]/>] <!-- allow platform specific lifecycles --> [<lifecycle id="..."> ... </lifecycle>] <!-- allow platform specific dependencies --> [<scope> ... </scope>] <!-- allow platform specific bindings... but plugin management is from the root only --> [<bindings> ... </bindings>] <!-- allow most of the other root tags except platform and packaging and deployment config --> </packaging>] [<packaging id="..."> ... </packaging>] ... [<packaging id="..."> ... </packaging>] <!-- unsure if we still need profiles --> <!-- perhaps we still need properties --> <!-- TBD deployment config, repositories, etc --> </project> |
...