[
https://issues.apache.org/jira/browse/FELIX-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Cook updated FELIX-5081:
------------------------------
Description:
Running the iPojo ant task using a metadata file that include Composite
definitions, it finds all elements in the metadata that have a 'specification'
attribute and adds it to the Import-Packages header.
Composites have two elements which support a 'specification' attribute:
# <subservice action="import" specification="com.abc.import.ImportA">
# <provides action="export" specification="com.abc.export.ExportZ">
iPojo blindly adding the packages specified by these attributes to the
Import-Package header causes the following issues:
# if a java.* class is exported then if it is added then Felix throws an
exception since it is invalid to import a java.* class
# if the manifest already contained an Import-Package header which had version
constraints on a package that was included in a <subservice> declaration then
iPojo overwrites the Import-Package header without the original version
constraints for that package.
was:
Running the iPojo ant task using a metadata file that include Composite
definitions, it finds all elements in the metadata that have a 'specification'
attribute and adds it to the Import-Packages header.
Composites have two elements which support a 'specification' attribute:
# <subservice action="import" specification="com.abc.import.ImportA">
# <provides action="export" specification="com.abc.export.ExportZ">
iPojo blindly adding the packages specified by these attributes to the
Import-Package header causes the following issues:
# if a java.* class is exported then if it is added then Felix throws an
exception since it is invalid to import a java.* class
In addition, if the manifest already contained an Import-Package header
generated by bnd which had version constraints and the package was included in
the <subservice> declaration then iPojo overwrites the Import-Package header
without the original version constraints for that package.
> iPojo manipulation adds incorrect Import-Package declarations when using
> Composites
> -----------------------------------------------------------------------------------
>
> Key: FELIX-5081
> URL: https://issues.apache.org/jira/browse/FELIX-5081
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
> Affects Versions: ipojo-manipulator-1.12.0
> Reporter: David Cook
>
> Running the iPojo ant task using a metadata file that include Composite
> definitions, it finds all elements in the metadata that have a
> 'specification' attribute and adds it to the Import-Packages header.
> Composites have two elements which support a 'specification' attribute:
> # <subservice action="import" specification="com.abc.import.ImportA">
> # <provides action="export" specification="com.abc.export.ExportZ">
> iPojo blindly adding the packages specified by these attributes to the
> Import-Package header causes the following issues:
> # if a java.* class is exported then if it is added then Felix throws an
> exception since it is invalid to import a java.* class
> # if the manifest already contained an Import-Package header which had
> version constraints on a package that was included in a <subservice>
> declaration then iPojo overwrites the Import-Package header without the
> original version constraints for that package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
