karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (KARAF-1351) Improvements to features-generate-descriptor
Date Wed, 11 Apr 2012 02:16:19 GMT
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

        

Mime
View raw message