Uploaded image for project: 'Sling'
  1. Sling
  2. SLING-8874

Support a manifest property that indicates alternate source artifacts



    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Feature Model
    • Labels:


      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.




            • Assignee:
              rombert Robert Munteanu
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: