[SLING-8874] Support a manifest property that indicates alternate source artifacts

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: Feature Model
• Assignee: Unassigned
• Reporter: Robert Munteanu
• Created: 02/Dec/19 14:43
• Updated: 06/Dec/19 16:37

Description

The ApiJarsMojo already supports looking for alternate artifacts based on sourceId property located in feature model files. This is useful for scenarios where the bundle can not be easily changed, but has some disadvantages:

• it requires inspecting the bundle that has a {{ sourceId }} property
• it can become out of date if the bundle is changed but the sourceId is not.

Alternate-Source-Artifacts: bundle-a, bundle-b, bundle-c

This would in turn be inspected by the ApiJarsMojo and handled in the same manner that the sourceId is.

Additionally, while working with the {{ sourceId }} property I have discovered two patterns of use:

1. The artifact repackages one or more artifacts, e.g. org.apache.sling.javax.activation
2. The artifact includes some code and in addition repackages some artifacts, e.g. org.apache.httpcomponents.httpclient-osgi

I would therefore suggest that we a mode argument to both the sourceId and the manifest header:

• mode=add - adds the specified sources jars to the list of source artifacts and keeps the auto-generated one ( bundle with classifier = sources )
• mode=replace - adds the specified sources jar to the list of source artifacts and does not keep the auto-generated one

I think that - at least of jar files that we can change ourselves - this will make maintaining source artifact mappings easier.

Issue Links

• links to: bnd issue #3640 - Allow tracking the sources of wrapped jars and inlined resources