enapps-enorman commented on PR #314:
URL: https://github.com/apache/felix-dev/pull/314#issuecomment-2094353497

   > Since this is the light package. I would expect, that is does not contains 
the o.o.servlet package. you can get this from the o.o.servlet api jar.
   > 
   > So no export is needed an would prefere remove the o.o.sevlet packages and 
not export them .
   
   @stbischof  Yes, I suppose you could make the case that the "light" 
classifier isn't light enough.  But historically the "light" classifier has not 
been a "minimal" packaging and has always embedded the content of other bundles 
(see also the embedded org.apache.felix.http.base).  If a more minimal 
packaging is something that people want, then perhaps creating a new "lightest" 
classifier without any embedding could be tracked separately in a standalone 
issue?
   
   The reason I proposed it this way was to be consistent to how it had been 
done for the previous releases.  From what I can tell. the "light" classifier 
first arrived with org.apache.felix.http.jetty:4.1.0 and all the later versions 
I checked have all embedded and exported the org.osgi.service.http.* packages.  
   
   The difference is that org.apache.felix.http.jetty:5.0.0 began embedding and 
using the new org.osgi.service.servlet.* package as well but it was declared as 
a private package and not exported.
   
   Instead of having a private copy in org.apache.felix.http.jetty and another 
copy of the same stuff from the additional org.osgi.service.servlet bundle I 
proposed and treat those packages the same way the older packages were treated.
   
   I haven't double checked, but if there are two sources for the same 
org.osgi.service.http.context.* packages then I suspect there could be some 
classloading boundary troubles when those duplicated packages get resolved to 
different bundles?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@felix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to