[
https://issues.apache.org/jira/browse/KARAF-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Topping closed KARAF-1351.
--------------------------------
Resolution: Not A Problem
Fix Version/s: 3.0.0
Deep in the bowels of the beast were more clues. Pruning is accomplished by
setting a dependency to "provided" scope. I guess this is all is really
necessary.
If there's some desire for documentation, please create an issue and assign it
to me!
> Improvements to features-generate-descriptor
> --------------------------------------------
>
> Key: KARAF-1351
> URL: https://issues.apache.org/jira/browse/KARAF-1351
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-tooling
> Affects Versions: 3.0.0
> Reporter: Brian Topping
> Fix For: 3.0.0
>
>
> In getting familiar with the features-generate-descriptor goal of
> karaf-maven-plugin, I found some things to be desired with the output. It
> very much seems to be an improvement over the 2.2.x plugin with the Maven
> properties filtering, JAXB parsing model, and template merging, but it still
> appears to be lacking the means to include features in the output instead of
> bundles.
> Although I never got it to work fully, some of that functionality did appear
> to be attempted in the 2.2.x branch. This issue focuses on finding a robust
> combination of these works.
> As a use case, consider a bundle under development that depends on a specific
> Aries dependency. Consider further that dependency is already included in an
> existing feature.xml generated by an external entity and we would like to use
> it.
> Under the current implementation, both <bundle> and <feature> elements may be
> included in the template, and a <feature> element could be included in the
> template that references Aries. But because the processor has no way to
> interpret the element, it is for all intents ignored. In turn, because the
> feature is ignored in processing, the transitive closure of the specific
> Aries dependency is generated into the final feature.xml, which in the most
> benign case, simply specifies bundles to be loaded which are already loaded
> by the <feature> from the template. In a degenerate situation, the versions
> of the dependencies generated into the feature.xml might be mismatched with
> the <feature> element that was specified (or already loaded by the system),
> thereby resulting in additional unwanted libraries being loaded (which often
> leads to "multiple path" errors at bundle resolution).
> With the facilities provided by current versions of Maven, we are able to
> recover transitive dependencies as a graph rather than a basic list. This
> will be important so as to prune a dependency analysis as soon as a
> dependency is found to be a part of a <feature>. But we must know the feature
> that is desired, and this author does not know if features are resolvable
> given a path to a dependency or not (assumption is not).
> Therefore, a means to resolve the URLs to features must also be made
> available to the plugin. In the 2.2.x branch, this was done in later versions
> by including a POM dependency on the kernel with scope of "provided", and the
> default configuration for that kernel was read and the features made
> available for processing. But this does not seem to be helpful in our use
> case, because Aries is not a part of the features repositories that are
> included with the base distribution. We need a build-dependent means to
> specify the collection of features repositories that should be included as a
> part of the feature resolution process.
> Noting the experience from 2.2.x with "provided" scope dependencies, it seems
> that the resolution of features should be done in the same manner whereby
> <dependencyManagement> or other version properties can be used to maintain
> the version number of an included feature, relying on the scope to make sure
> they are not otherwise included in the built output.
> An outline of the features processor could (very) roughly take on the
> following form:
> # On plugin startup, dependencies of the plugin project with "provided" scope
> dependencies and "features" classifier are collected.
> # For each dependency, a features.xml artifact is loaded and processed with
> the existing JAXB code, generating a dependency node graph for each feature
> set.
> # A visitor is applied to the collection of graphs to generate an index of
> the dependencies across the graphs. This index is used to resolve which
> feature provides a given dependency.
> # The template features are interpolated and loaded using the existing JAXB.
> # A visitor is applied to the template graph, which pre-populates the
> template feature nodes with dependencies.
> # Now the visitor for the Macen dependency tree is run. This visitor is
> currently smart enough to know not to add a dependency more than once. In
> addition, the visitor is modified to check the index of dependencies created
> earlier. If it exists and the version range matches, it is ignored with a
> message to the debug log.
> This should result in in two distinct behaviors, depending on whether there
> is a feature element in the template that matches the features supplied with
> "provided" scope or not.
> * If there is, the existence of the feature and the bundles it provides means
> that the runtime linkage will be satisfied (the dependency and it's closure
> are provided by the feature).
> * Even if the "provided" scope dependency on the feature is available to the
> plugin, if it is not supplied in a specific feature in a template, it will be
> ignored. In that case, the full transitive closure of the dependencies will
> be listed as they are today.
> In this manner, the versions of the features are manageable by normal Maven
> practice, the application of those features can be done in a focused manner,
> and the end result will be features generation with minimized transitive
> duplication via the use of feature element references.
> If these goals and changes look reasonable, I'll code something up, and this
> text can eventually be used as a basis for the documentation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
