[MNG-5697] remove LifecycleMapping and ArtifactHandler from maven-core: move to target packaging plugin

[jira-importer]

Robert Scholte opened MNG-5697 and commented

Maven Core should only be aware of the pom packaging details, the rest of the ArtifactHandlers and LifecycleMappings should be moved to their own packaging plugin:

• jar packaging: maven-jar-plugin
• ejb and ejb3 packagings: maven-ejb-plugin
• maven-plugin packaging: maven-plugin-plugin
• war packaging: maven-war-plugin
• ear packaging: maven-ear-plugin
• rar packaging: maven-rar-plugin
• par packaging: ?

LifecycleMappings http://maven.apache.org/ref/3.2.5/maven-core/default-bindings.html
ArtifactHandlers http://maven.apache.org/ref/3.2.5/maven-core/artifact-handlers.html

Maven core should then get the lifecycle mappings and artifact handlers configurations from the plugin at the beginning of the build, before begin able to calculate the build plan

---

Sub-tasks:

• MNG-7832 revert artifact handlers move to plugins

Issue Links:

• MACR-30 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MEAR-198 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MEJB-72 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MJAR-183 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MPLUGIN-275 Move LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MRAR-55 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MWAR-326 Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin
  ("is blocked by")

• MPOM-337 Load plugins containing lifecycle mapping/artifact handler with <extensions>true</extensions>
  ("causes")

• MNG-8472 Sort out the problem about packaging in Maven 4
  ("causes")

• MPLUGIN-402 report: allow to generate usage section in plugin-info.html with <extensions>true</extensions>

• MNG-7508 Validate usage of <extensions>true</extensions> on plugins

• MNG-7572 Plugin descriptor should indicate if plugin should be loaded as Maven build extension

• MNG-7574 Never expose Mojo classes via Core Classloader

• MNG-7264 Convert maven-core default-bindings.xml to Providers

• MDEPLOY-71 DeployFile Mojo Does Not Handle Non-Core Artifact Types

0 votes, 7 watchers

[jira-importer]

Robert Scholte commented

If we want to keep the minimal pom.xml as is, so without reference to a specific packaging plugin (bad practice with respect to reproducibility, though), we should only have a mapper from a packaging-type to a specific plugin+version. All other details should be moved.

[jira-importer]

Hervé Boutemy commented

the version should be detected from the build: only default groupId and artifactId has to be coded in core, and should be extensible for custom packagings

[jira-importer]

Robert Scholte commented

MDEPLOY-71 describes an important issue related to this. Right now it s impossible to do a deploy:deploy-file of a custom packaging type without having a pom + extensions. In our solution we need to solve this as well.

[jira-importer]

Elliotte Rusty Harold commented

would this be backwards compatible?

[jira-importer]

Robert Scholte commented

??would this be backwards compatible???

Yes. All our packaging-plugins already have this since their 3.0.0 version. It works already, if you add <extensions>true</extensions>. What is still missing is some propertyfile that maps the packaging-type to a versioned plugin, which activates this extension. It can be as simply as:

jar=org.apache.maven.plugins\:maven-jar-plugin\:3.2.0
#etc...

IIRC Hervé Boutemy is a bit worried that it exposes a bit too much, so this needs a lot of testing.
But it'll make Maven much cleaner, and it'll make the behavior of maven-plugins and custom plugins the same.

[jira-importer]

Hervé Boutemy commented

yes, I'm sure this nice idea has issues.
Today, re-reading it, I now see one issue: ArtifactHandler is not about packaging but about dependency type, then has a fully different target location.
But at least the part about splitting packagings' LifecycleMapping into each "main" packaging plugin seems a good idea, if we ever have time to work on it...

[jira-importer]

Hervé Boutemy commented

and yes, I'm very worried that this pushes to marking every packaging plugin as extension, then will put every plugin dependency in core classloader: by doing that, we're de-facto loosing the per-plugin classloader isolation https://maven.apache.org/guides/mini/guide-maven-classloading.html

edit: wrong reading of classloading, plugins markes as extension don't go to core classloader but plugin-specific classloader called in the doc "Build Extension Classloader"

[jira-importer]

Konrad Windszus commented

Hervé Boutemy gnodet Any concern removing those plugin specifics from Maven Core for Maven 4? All recent plugin versions (responsible for a specific packaging) ship with according components, so it is just a matter of loading those with extensions being set to true.

[jira-importer]

Guillaume Nodet commented

Yes, a bit.
What will happen to existing projects ? Won't they be broken because they won't have the <extension>true</extension> in the packaging plugin ? If they are broken, is there any way we could mitigate that ?

[jira-importer]

Hervé Boutemy commented

existing projects will require:

1. to have plugins as extension
2. to have plugins as plugins, and not only pluginManagement

on the good sides, error message when packaging is missing is really clear:

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unknown packaging: bundle @ line 27, column 16

In addition: I can understand that we want to remove Jakarta EE packaging definition from core (war, ear, rar, ...) and Maven Plugin,

but removing jar packaging (and even more its many artifact handlers that are constantly used) from core looks a very bad idea

[jira-importer]

Hervé Boutemy commented

I did more extensive tests to better clarify:

• my own mistakes (I completely misunderstood classloading: plugins are Build Extensions, not Core Extensions, thanks for clarifications in MNG-7574)
• from real problems

here are my tests: https://github.com/hboutemy/MNG-5697

There are 2 completely different aspects:

• packaging: previous comment explains it, it can be ok to remove some packaging from core (with proper documentation/communication), it will cost reasonable added complexity to users (declaring plugins: I won't fight on justifying why adding this complexity to users is worth it, but I just want to let know that the technical enhancement AFAIK goes against users).

But definitively NOT on jar packaging

• artifact handlers/dependency type: here, I feel that the whole replacement from core to packaging plugins is completely unintuitive to users, and really adds complexity and strange behaviours when not configured properly

I just did unit tests for now (mono-module project, one packaging, one dependency type), I need some time to test at larger scale to check there are no other issues (I still feel that there may be edge cases: I know i need to nail them down...)

[jira-importer]

Konrad Windszus commented

artifact handlers/dependency type: here, I feel that the whole replacement from core to packaging plugins is completely unintuitive to users

I am fine with leaving those in Core, but we should document which dependency types are supported OOTB. Update: From the ones documented at https://maven.apache.org/ref/3-LATEST/maven-core/artifact-handlers.html we should IMHO remove the following:

• ejb
• ejb-client
• war
• ear
• rar

The rest should probably be considered java default.

[jira-importer]

Hervé Boutemy commented

removing without really knowing who uses, and what we propose to users?

for what benefit? (these dependency handlers are not costing much in Maven core)

IMHO, we'll need at least a deprecation phase with warnings

[jira-importer]

Konrad Windszus commented

Won't they be broken because they won't have the <extension>true</extension> in the packaging plugin ? If they are broken, is there any way we could mitigate that ?

One mitigation (only affecting ASF projects though): apache/maven-apache-parent#92, another more complete but still WIP is #833.

[jira-importer]

Hervé Boutemy commented

MNG-7832 created to revert artifact handlers side of the current issue: please review and confirm it makes sense