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
