[
https://issues.apache.org/jira/browse/KARAF-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252137#comment-13252137
]
Brian Topping commented on KARAF-1351:
--------------------------------------
With this in hand and after reviewing the code more deeply, I've figured out
the proper configuration to get this pretty close with the existing code. It
turns out that the existing dependencies of the features project *are* parsed
and included by reference if they exist, but the transitive dependency graph is
not pruned in the manner I described here.
I'm going to code up this pruning to see what I can come up with.
> 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
>
> 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
