Message-ID: <1839509036.657.1369182570409.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_656_1634967143.1369182570409" ------=_Part_656_1634967143.1369182570409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Currently, plugin versions, if unspecified, resolve to the "latest&= quot; from the repository, which (depending on the repositories included) c= an include snapshots. It also means that builds change change without the P= OM changing.
In addition to the ones the users specify, several plugins with no versi= on attached are implied by the lifecycle, making it quite cumbersome to spe= cify all the plugins that a build might use in the POM to ensure that the v= ersions are locked down over time.
While this situation is problematic, the alternative of requiring every = single plugin version be provided is too cumbersome and verbose a task in m= any situations - particularly in the case of the implied plugins.
It should also be noted that anything in the Maven installation itself (= such as the settings, or in the past the plugin registry) is not an adequat= e solution - the POM must be the definitive reference for how to build the = software and changing Maven installations should have no effect.
The original discussion also touched on the following, which are related= but separate issues:
After implementation, Maven will require the version in plugin definitio= ns that are bound to the lifecycle in the POM from modelVersion 4.1.0+. Plu= gins will not be resolved to the latest version (except for the CLI excepti= on listed below).
However, in 4.0.0 modelVersions, Maven will continue to allow the RELEAS= E as the version for backwards compatibility.
The Super POM should declare a default version of the clean plugin as a = special case. This will not be the case for the site plugin, or standard pa= ckaging plugins.
The additional requirement to declare all versions is not an inconvenien= ce when the plugin is already declared - just one additional line.
However, for the implied plugins (jar, compile, resources, etc) - this w= ould involve an undesirable amount of boilerplate. To better facilitate thi= s, we should add the concept of plugin packs.
After the releases of one or more included plugins, a pack release can b= e made that includes the plugins and their versions. This is achieved throu= gh the deployment of a POM project that declares a number of plugins - this= has the advantage of having the same syntax, as well as easy cut-and-paste= if necessary. For example, the Java plugin pack:
To incorporate this into a project:
Only the build and reporting plugins sections of the POM will be incorpo= rated into the project - not the plugin management or other sections such a= s configuration. In addition, if multiple plugin packs are declared, they s= hould be applied sequentially, overriding any prior.
Note: this facility could later be addressed by mixins in the POM.
The plugin management section, when declaring a version, must always win= over all plugin packs.
A version will not be required in the plugin management section (which c= an still be used to apply configuration to an already-defined plugin, inclu= ding those called from the CLI).
When running a goal from the command line, it should seek the plugin fro= m those defined in the POM (including their versions). If the plugin is not= defined in the project at all (or in the case that there is no project, su= ch as with archetype:create), at present the current rules will be retained= . It should be a recommended best practice to declare any plugins you use f= rom the command line in the POM that are not once-off goals.
A future enhancement may be to be able to (and if so, require) plugin ve= rsions to be declared in the Maven settings files.
The definition of lifecycles and packaging types currently occurs in the= maven-core's components.xml, with others defined in plugins via extensions= . With the possible exception of the POM packaging, these can all be moved = into the plugins that define the main package goal.
Given this, the user will be required to declare the plugin that contain= s the packaging (including it's version). Like the earlier requirement, thi= s must not apply to POM's with the previous model version.
Note that a plugin may still contain one or more packaging.
The lifecycle still does not declare plugin versions - this is to be def= ined in the plugin packs.
It would be beneficial to write a plugin that can look at the current ve= rsions in a project, and suggest possible updates available in the reposito= ry (and apply them in an interactive fashion). This may suit the maven-pom-= plugin.
jason (in its current form)