[
https://issues.apache.org/jira/browse/SLING-13233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18087679#comment-18087679
]
Robert Munteanu commented on SLING-13233:
-----------------------------------------
[~royteeuwen] - I misread your comments and did not figure out the cpconverter
bits. Sorry.
Yes, I it's not desireable to magically detect the newly converted feature
files and add the to some sort of feature model aggregate.
I still prefer the changes to the slingfeature-maven-plugin, especially since
they fit in more naturally with analysis and local repository creation.
I'll add my comments to
https://github.com/apache/sling-slingfeature-maven-plugin/pull/100
> Multi-feature aggregation: add <featureFiles>, <features>,
> <osgiBsnCollisionDetection>, <artifactClashOverrides>
> -----------------------------------------------------------------------------------------------------------------
>
> Key: SLING-13233
> URL: https://issues.apache.org/jira/browse/SLING-13233
> Project: Sling
> Issue Type: New Feature
> Affects Versions: Feature Launcher Maven Plugin 1.0.4
> Reporter: Roy Teeuwen
> Assignee: Roy Teeuwen
> Priority: Major
> Fix For: Feature Launcher Maven Plugin 1.0.6
>
>
> The <launch> element currently accepts exactly one of <feature> (Maven
> coordinates) or <featureFile> (local path), validated as mutually exclusive.
> This forces users who want to aggregate (e.g. Sling Starter + a downstream
> feature, or a base feature + tweaks) to either:
> * Pre-merge externally with a script that calls FeatureBuilder.assemble
> themselves, then point <featureFile> at the result, or
> * Skip the plugin entirely and shell out to the launcher tar.gz with their
> own arg construction.
> Both lose the plugin's start/stop lifecycle, attached-artifacts dir,
> port/repo plumbing, and JAVA_HOME fallback.
> This feature is meant to add all the capabilities that the CLI already
> supports (add <featureFiles>, <features>, <osgiBsnCollisionDetection>,
> <artifactClashOverrides>)
> Backward compatibility: The only meaningful semantic change: combining
> <feature> and <featureFile> was previously rejected at validation; now it's
> accepted as a two-feature aggregation. Existing single-feature configurations
> continue to work unchanged. The new fields are all optional with empty-list /
> false defaults.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
