felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clement Escoffier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-2996) iPOJO doesn't generate Import-Package correctly
Date Mon, 27 Jun 2011 16:56:48 GMT

    [ https://issues.apache.org/jira/browse/FELIX-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055659#comment-13055659

Clement Escoffier commented on FELIX-2996:


I don't quite get it. Could you give a test case to help me reproducing the issue ?


> 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
>              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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message