karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Achim Nierbeck (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KARAF-1351) Improvements to features-generate-descriptor
Date Thu, 12 Apr 2012 09:01:22 GMT

    [ https://issues.apache.org/jira/browse/KARAF-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252295#comment-13252295
] 

Achim Nierbeck commented on KARAF-1351:
---------------------------------------

KARAF-1357 - please grab this one, somehow I'm not able to assign this to you :)

                
> 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

        

Mime
View raw message