[MINSTALL-38] Install plugin behaves incorrectly in grandchildren projects that has packaging != jar

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Duplicate
• Affects Version/s: 2.1
• Assignee: Stephane Nicoll
• Reporter: Niclas Hedhman
• Created: 05/Apr/07 01:29
• Updated: 07/Apr/15 18:37
• Resolved: 01/May/07 06:09

Description

Case in hand; https://scm.ops4j.org/repos/ops4j/projects/pax/

Pax contains a handful of subprojects, which in turn contains subprojects and they are often of a custom packaging "bundle" or "osgi-bundle".

When building for instance from pax/logging as the root, things work as expected and we get the following info;
[INFO] [install:install]
[INFO] Installing /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar to /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.jar

But when building one level higher up, we get the following message;
[INFO] [install:install]
[INFO] Installing /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar to /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.bundle

Note that when building the grandchild project, the file extension is equal to the <packaging> argument, but if building a child project, it is the jar file we construct.

This problem appeared not too long ago, and may not be the problem of the Install Plugin after all, and instead is somewhere in the inheritence mechanism that got screwed up. Whatever, the problem is huge as we have this in much larger commercial projects, where it is not feasible to build project by project, and the Continuous Integration setup must be populated with hundreds of projects instead of 3.

Issue Links

• duplicates: MNG-1682 Plugins do not honor the correct extension when run as a part of a multiproject build