Proposals for some open JPMS issues, #ResourceEncapsulation

[Juergen Hoeller]

>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.lloyd at 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.reinhold at 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
>