Message-ID: <1468722881.1669.1369246083837.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1668_971930109.1369246083836" ------=_Part_1668_971930109.1369246083836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We need to provide a standardized way to suppress one or more executions= of a given mojo. This is usually required when a mojo is bound to the buil= d via packaging or something in the POMs ancestry.
Need a way to organize the order of operations within a single lifecycle= phase, in order to specify when a mojo binding should precede the standard= bindings, etc.
Provide a mechanism for external tools that embed Maven, so they can reg= ister pre- or post-build hooks per project.
Need more information about specific needs here...it may be better to en= able this within the embedder itself, rather than interfering with the stan= dard lifecycle.
If we find that we must include build extensions in Maven's core classlo= ader, then we'll need a way to adjust the artifact filter used to avoid dou= ble-loading a given dependency in the plugin and the core. In other words, = this filter prevents the loading of plugin dependencies into the plugin's c= lassloader in cases where that dependency already exists in the core...in c= ases where build extensions are used, we need to ensure that this filter ta= kes those loaded extensions into consideration.
It would be useful to define the APIs exposed for plugin parameter injec= tion using some sort of annotation or other tools. This would enable us to = render a guide to plugin parameter expressions, and would remove the String= -based logic associated with parameter injection. (Need more details here.)=------=_Part_1668_971930109.1369246083836--