[ 
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MNG-8180.
--------------------------------
    Resolution: Fixed

> Resolver will blindly assume it is deploying a plugin by presence of 
> META-INF/maven/plugins.xml in JAR
> ------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-8180
>                 URL: https://issues.apache.org/jira/browse/MNG-8180
>             Project: Maven
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 
> 3.9.8
>            Reporter: Tamas Cservenak
>            Assignee: Tamas Cservenak
>            Priority: Major
>             Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of 
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may 
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR, 
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST 
> BE aligned (artifact GA == metadata GA). In this case all is happening as 
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the 
> build, as deploying "formally adhering to maven plugin JAR with rogue 
> metadata" may be very misleading. Most probably the origin of "rogue" plugin 
> metadata is by shading (like in case of Tika), or by some other rogue 
> resource, or even someone "reinventing" the plugin metadata for some other 
> purposes. Maven should simply prevent install/deploy of artifacts like these, 
> and users should fix the artifact (in case of shading, exclude that resource, 
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata 
> generation happens in maven-resolver-provider module that does not and cannot 
> depend on maven-core (is "pure" resolver), hence notion of packaging, 
> project, build etc is not available. In Maven4 with new API we MAY do 
> something more later. The two PRs against 3.9.x and 4.0.0 are currently 
> identical.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to