Hi I looked into one example, where this happens: The Sling auth.core bundle has the following export:
> org.apache.sling.engine.auth; > version="2.0.6"; > uses:="javax.jcr,javax.servlet.http,org.apache.sling.api" Could it be that the unconditional Import-Package is driven by this uses constraint ? That would make sense to me to some extent (without having looked to deep into the actual code etc.) Regards Felix Am 06.09.2013 um 12:26 schrieb Felix Meschberger: > Hi > > Is the import hard or resolution:=optional ? I could make an argument for the > latter in that it would resolve the import upfront if available but delay to > dynamic resolution if not available yet. > > WDYT ? > > Regards > Felix > > Am 06.09.2013 um 08:31 schrieb Carsten Ziegeler: > >> Hi, >> >> in Apache Sling we switched now from version 2.3.7 to 2.4.0 of the maven >> bundle plugin and it seems there is a difference in the handling of dynamic >> import packages between those versions. >> >> With previous versions of the plugin, the Import-Package was calculated >> with taking DynamicImport-Package in mind, which means a package declared >> as dynamic import was not added to the import list. >> With 2.4.0 this changed, and the package is listed in both statements. >> >> So I'm wondering what is the correct behaviour? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org >
smime.p7s
Description: S/MIME cryptographic signature
