felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clement Escoffier (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FELIX-2996) iPOJO doesn't generate Import-Package correctly
Date Mon, 21 Nov 2011 07:52:57 GMT

     [ 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

       

Mime
View raw message