Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Thu, 12 Apr 2012 03:42:40 +0000 (UTC)
From: "Brian Topping (Closed) (JIRA)" <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: 
 <1557925485.15931.1334202160166.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1898290262.10610.1334110579529.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Closed] (KARAF-1351) Improvements to
 features-generate-descriptor
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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