[
https://issues.apache.org/jira/browse/SLING-13233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18087022#comment-18087022
]
Robert Munteanu commented on SLING-13233:
-----------------------------------------
[~royteeuwen] - thanks for the comprehensive analysis. That's a lot, hopefully
I got the gist of it - the slingfeature-maven-plugin reads the list of features
dynamically at start time while you need something that is built in the
reactor.
I looked at the PR for the slingfeature-maven-plugin and it would be my
preference; I was wondering whether it is possible to have some sort of build
participant dynamically add projects that are built in the reactor? That would
be slightly more manageable compared to the manual definition of additional
features and would also keep away the complexity for the feature launcher. The
dynamic addition could have a flag that disables it, in case there are issues
in projects that use it.
> 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)
