Robert Munteanu created SLING-8874:
--------------------------------------
Summary: Support a manifest property that indicates alternate
source artifacts
Key: SLING-8874
URL: https://issues.apache.org/jira/browse/SLING-8874
Project: Sling
Issue Type: Improvement
Components: Feature Model
Reporter: Robert Munteanu
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.
{code}
Alternate-Source-Artifacts: bundle-a, bundle-b, bundle-c
{code}
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|https://github.com/apache/sling-org-apache-sling-javax-activation]
2. The artifact includes some code and in addition repackages some artifacts,
e.g.
[org.apache.httpcomponents.httpclient-osgi|https://github.com/apache/httpcomponents-client/tree/4.5.x/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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
