karlpauls commented on pull request #56: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/56#issuecomment-1061166934
@rombert, I'm not against this change however, as I pointed out to @kwin oob already, it is a change in how this was handled in sling since the dawn of time. Basically, how it currently is working (and IIRC, has been since a long time) is that we have a fixed list of packages we export and users can extend this list using the packages.extra property. With JPMS, I massaged it so that we can effectively set the upper bound on the packages we export - so it is still a fixed list but will only contain the packages that are actually on the module path (or rather, their modules are, to be precise). This PR will change that to basically export from the system bundle all package of modules all modules on the module path plus some potential duplicate exports for the xml packages (to fix the versions). Furthermore, as it is using the packages extras for that, it will require users to either duplicate that part (or not have it) if they use the packages extra themselves. In a sense, it is a continuation of what I started with this in the first (using the packages provided by Felix instead of a list maintained in Sling) - however, the reason I did it the way I did was to maintain backwards compatibility. This will break it up to a point (which might be fine for Sling) but would be more maintainable. Otherwise, I think it should be ok with the possible exception of maybe some split package problems - not sure about that. -- 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...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
