[ 
https://issues.apache.org/jira/browse/FELIX-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clement Escoffier closed FELIX-2996.
------------------------------------

    
> iPOJO doesn't generate Import-Package correctly
> -----------------------------------------------
>
>                 Key: FELIX-2996
>                 URL: https://issues.apache.org/jira/browse/FELIX-2996
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.6.0
>            Reporter: Rémy Masson
>            Assignee: Clement Escoffier
>              Labels: import, manifest, package
>
> We're having troubles with generating a manifest using BND and iPOJO. The 
> problem resides in iPOJO not adding referred packages (from @Provides 
> annotations in components in our case) to the imported packages of the 
> manifest.
> I noticed the iPOJO task is supposed to be adding them, and by checking the 
> code implementation, I found the issue in the Pojoization class which is 
> called during manipulation. When fetching referred packages, it looks for the 
> "specification" attribute instead of looking for the "specifications" 
> attribute, which results in failing to find any referred package.
> However fixing that doesn't completely solve our problem. We encountered 
> another issue (after fixing the issue locally in Pojoization.java): imports 
> are added naked, and it doesn't seem possible to add attribute such as the 
> "version=x.x.x" which we need.
> BND however implements such a mechanism - when told to process a given 
> bundle, it will take a .bnd file. The .bnd file may then contain attributes, 
> such as "im.an.example.*;version=6.6.6". It will, for packages which fit the 
> wildcard, use the provided version for added package imports. Could that be 
> implemented in some sort of way in iPOJO?
> I looked into why BND wasn't adding the package of the @Provided interfaces 
> to the imported packages: the issue lies into the @Provide annotation having 
> a CLASS retention policy. BND will only consider RUNTIME retained 
> annotations, which kind of makes sense to me. Could it be possible to have 
> that annotation retained at runtime?
> The annotation solution definitely looks simpler to do than implementing an 
> attribute mechanism. It implies that tools such as BND will be able to tell 
> which packages are needed at runtime. However, the existing implementation 
> ("specification" instead of "specifications" and import overwriting) would 
> still need fixing.
> For reference, here are the code excerpts showing the introduced existing 
> problems:
> ## Pojoization.getReferredPackages() 
> [..]
>                 String att = elems[j].getAttribute("specification");
> [..]
> ## I also noticed another issue with the Pojoization.setImports(Attribute) 
> method, which overrides any existing package import with a blank one:
>         // Add referred imports from the metadata
>         for (int i = 0; i < m_referredPackages.size(); i++) {
>             String pack = (String) m_referredPackages.get(i);
>             imports.put(pack, new TreeMap());
>         }
> ... meaning any previously existing import with specific pieces of 
> information such as the package version will get deleted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to