[
https://issues.apache.org/jira/browse/FELIX-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-2996.
--------------------------------------
Resolution: Won't Fix
Assignee: Clement Escoffier
The manipulator was reimplemented in the mean time, and the way we're computing
imported packages has changed. Please check if the issue is still valid.
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
