>From Spring's side, dropping resource encapsulation would be the easiest way out. That said, I can imagine some middle ground as well since we effectively only need access to META-INF resources.
For a recent example, https://jira.spring.io/browse/SPR-14579 is about finding schema declarations behind Spring XML namespaces which currently only works in classpath mode (on mainline JDK 9). Juergen On Thu, Jun 30, 2016 at 1:46 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > On 06/30/2016 06:13 AM, Peter Levart wrote: > >> Hi, >> >> The proposal for #ResourceEncapsulation plans to drop the >> resource-encapsulation requirement. Have you thought about a "middle >> ground" ? >> > > I went into a lot of detail on this topic last year [1] but nothing much > came of it. I do agree that it would be good to have a better approach for > resources; even the more complex approach I outlined would be better than > nothing. > > [1] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2 > 015-February/000033.html > > (eom) > > > >> Possibility 1: resources in a module could be divided in two groups: >> >> always accessible: resources in "root" package and special >> directories such as META-INF/**, WEB-INF/** (dilemma: how to define >> "special directories") >> governed by qualified/unqualified package exports: other resources >> located in module subdirectories mapped to package names >> >> Possibility 2: access to classes is by default restricted and explicitly >> enabled by package exports. Access to resources could be governed by >> special module-info syntax, modeled for example by file patterns used in >> ANT build tool: >> >> module m1 { >> requires ... >> exports ... >> uses ... >> provides ... >> exportsResources *, META-INF/**, WEB-INF/**; >> } >> >> Automatic modules would "export" all resources. Module readability would >> not play any role in accessing the resources (as it is the case with >> accessing classes by reflection). >> >> Regards, Peter >> >> On 06/28/2016 11:47 PM, mark.reinh...@oracle.com wrote: >> >>> FYI, I've just posted proposals for some of the open issues in the >>> draft JPMS specification, including: >>> >>> #CompileTimeDependences >>> #ReflectiveAccessToNonExportedTypes >>> #ModuleAnnotations and #ModuleDeprecation >>> #ResourceEncapsulation and #ClassFilesAsResources >>> #ReflectiveAccessByInstrumentationAgents >>> #BootstrapClassLoaderSearchInJVMTI >>> #CustomizableAutomaticModuleNameMapping >>> >>> Links to the proposals are available in the issue summary [1]. >>> >>> Comments and discussion are welcome here on jigsaw-dev but, as usual, >>> the best way to ensure that the EG sees any specific comment is to >>> send it to the EG's "suggestion box" list, jpms-spec-comments [2]. >>> >>> If you comment on one of these proposals, via any channel, please >>> include the hashtag of the relevant issue(s) in the subject line of >>> your message, to simplify tracking. Thanks! >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ >>> [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments >>> >> >> > -- > - DML >
