Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Daniel Megert]

> Hence, I propose to make this a rule for future releases that all 
bundles
> should have this manifest header, where the value should be identical to
> the value of Bundle-SymbolicName.

+1 and +1 for having PDE support (https://bugs.eclipse.org/525660).

Dani



From:   Stephan Herrmann 
To: Cross project issues 
Date:   05.10.2017 23:10
Subject:[cross-project-issues-dev] Eclipse plug-ins as automatic 
modules in  Java 9?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

I just noticed by chance that none of the artifacts we are producing
are consumable as "automatic modules" in Java 9 speak.

The reason is: JPMS defines an algorithm how names for automatic modules
are derived from the jar file name. Unfortunately, the spec expects any
version to be separated from the name by "-", whereas our files use "_".

As a result a jar file like
org.eclipse.equinox.common_3.9.0.v20170207.jar
is interpreted as an automatic module named
org.eclipse.equinox.common.3.9.0.v20170207
(cutting off the version fails, then "_" is converted to ".").

Since that module name is not a legal Java identifier, the given jar file
cannot be referenced in any "requires" clause of a Java 9 module.

While all this is very unfortunate, Java 9 provides a means for a 
systematic
solution: adding an Automatic-Module-Name header to MANIFEST.MF.

Hence, I propose to make this a rule for future releases that all bundles
should have this manifest header, where the value should be identical to
the value of Bundle-SymbolicName.

There may not yet be any consumers of Eclipse plug-ins as Java 9 modules,
but as we know that several of our artifacts are being consumed outside 
OSGi,
I am sure that clients will expect our artifacts to be consumable as Java 
9
modules sooner or later. And then a general solution looks cleaner to me
then doing this for selected artifacts only.

best,
Stephan

Reference for naming of automatic modules:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emr_jigsaw_spec_api_java_lang_module_ModuleFinder.html-23of-2Djava.nio.file.Path...-2D=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=FWDhRdiRFAyj2GifD6YtSPozyA79w_jtZw9lzRvzXmQ=XcH8c6YPP7EckLYSnqp6AdGT8fQ934MzrpR0aoghrPg=
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=FWDhRdiRFAyj2GifD6YtSPozyA79w_jtZw9lzRvzXmQ=TUeYYSzSWs-W0BoYl-4_ccfQ3dBF8gLi1SzDLrNvedo=
 






___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Mickael Istria]

On Fri, Oct 6, 2017 at 10:23 AM, Ed Willink  wrote:

> A SimRel check requires David/Frederic to do a lot of chasing to get
> complete compliance.
>

I'd like to remind that SimRel is a community project just like any other,
and that contributions are most likely welcome from anyone. All work on
SimRel isn't to be done by David or Frederic and we (SimRel users) also
have the responsibility to contribute code to it from time to time instead
of getting someone else's todo-list explode ;)
That said, more technically, I imagine we could relatively easily copy and
adapt one of the SimRel report for labels or version that already gets into
MANIFEST.MF for all SimRel bundles, and replace the actual payload by a
simple regexp comparison.
However, before we spend some resources on that, I believe this mush be
discussed and desired by the Planning Council? Or should it be the other
way round (ie we -the community- create the report and add it to SimRel
build) and then Planning Council decides how much to enforce this report?

A Tycho check only works for Tycho users, so it does not help Tycho-1
> (Buckminster) or Tycho+1 (whatever)
>
That's right.
However, the logic behind it is simple enough to be repeated in all tools.
Adding some abstraction layer for it seems a bit overkill.
The cool thing is that having it in Tycho delivers the value to much more
users than SimRel, really helping this good practice to be adopted
everywhere, and ultimately leading to more peace between JPMS and OSGi
faster.

All that said, I think there is no bad place where adding a warning, or
report or whatever; and having it in too many places is better than having
it nowhere. Let just see where actual work happens first ;)
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Ed Willink]

Hi

https://bugs.eclipse.org/bugs/show_bug.cgi?id=525660 raised.

Since the problem is in the Manifest, manifest tools in the workspace 
seem the place to solve it.


A SimRel check requires David/Frederic to do a lot of chasing to get 
complete compliance.


A Tycho check only works for Tycho users, so it does not help Tycho-1 
(Buckminster) or Tycho+1 (whatever)


    Regards

        Ed Willink


On 06/10/2017 08:50, Mickael Istria wrote:


"I propose to make this a rule"


+1

Do you mean an informal good practice
or a Manifest editor warning and a quick fix
or a Manifest builder automated edit?


Or even a Simrel requirement with an automated check?
Or if this is a general good practice for OSGi at large (and not just 
Eclipse.org projects), a Tycho validation rule showing warning or 
error for new builds?



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Mickael Istria]

> "I propose to make this a rule"
>

+1


> Do you mean an informal good practice
> or a Manifest editor warning and a quick fix
> or a Manifest builder automated edit?


Or even a Simrel requirement with an automated check?
Or if this is a general good practice for OSGi at large (and not just
Eclipse.org projects), a Tycho validation rule showing warning or error for
new builds?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Aleksandar Kurtakov]

On Fri, Oct 6, 2017 at 10:34 AM, Ed Willink  wrote:
> Hi
>
> "I propose to make this a rule"
>
> Do you mean an informal good practice
>
> or a Manifest editor warning and a quick fix

^^ is probably best. It would be nice if someone opens PDE bug with the details.

>
> or a Manifest builder automated edit?
>
> Regards
>
> Ed Willink
>
>
>
> On 05/10/2017 22:10, Stephan Herrmann wrote:
>>
>> Hi,
>>
>> I just noticed by chance that none of the artifacts we are producing
>> are consumable as "automatic modules" in Java 9 speak.
>>
>> The reason is: JPMS defines an algorithm how names for automatic modules
>> are derived from the jar file name. Unfortunately, the spec expects any
>> version to be separated from the name by "-", whereas our files use "_".
>>
>> As a result a jar file like
>>org.eclipse.equinox.common_3.9.0.v20170207.jar
>> is interpreted as an automatic module named
>>org.eclipse.equinox.common.3.9.0.v20170207
>> (cutting off the version fails, then "_" is converted to ".").
>>
>> Since that module name is not a legal Java identifier, the given jar file
>> cannot be referenced in any "requires" clause of a Java 9 module.
>>
>> While all this is very unfortunate, Java 9 provides a means for a
>> systematic
>> solution: adding an Automatic-Module-Name header to MANIFEST.MF.
>>
>> Hence, I propose to make this a rule for future releases that all bundles
>> should have this manifest header, where the value should be identical to
>> the value of Bundle-SymbolicName.
>>
>> There may not yet be any consumers of Eclipse plug-ins as Java 9 modules,
>> but as we know that several of our artifacts are being consumed outside
>> OSGi,
>> I am sure that clients will expect our artifacts to be consumable as Java
>> 9
>> modules sooner or later. And then a general solution looks cleaner to me
>> then doing this for selected artifacts only.
>>
>> best,
>> Stephan
>>
>> Reference for naming of automatic modules:
>>
>> http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse plug-ins as automatic modules in Java 9?

[Ed Willink]

Hi

"I propose to make this a rule"

Do you mean an informal good practice

or a Manifest editor warning and a quick fix

or a Manifest builder automated edit?

    Regards

        Ed Willink


On 05/10/2017 22:10, Stephan Herrmann wrote:

Hi,

I just noticed by chance that none of the artifacts we are producing
are consumable as "automatic modules" in Java 9 speak.

The reason is: JPMS defines an algorithm how names for automatic modules
are derived from the jar file name. Unfortunately, the spec expects any
version to be separated from the name by "-", whereas our files use "_".

As a result a jar file like
   org.eclipse.equinox.common_3.9.0.v20170207.jar
is interpreted as an automatic module named
   org.eclipse.equinox.common.3.9.0.v20170207
(cutting off the version fails, then "_" is converted to ".").

Since that module name is not a legal Java identifier, the given jar file
cannot be referenced in any "requires" clause of a Java 9 module.

While all this is very unfortunate, Java 9 provides a means for a 
systematic

solution: adding an Automatic-Module-Name header to MANIFEST.MF.

Hence, I propose to make this a rule for future releases that all bundles
should have this manifest header, where the value should be identical to
the value of Bundle-SymbolicName.

There may not yet be any consumers of Eclipse plug-ins as Java 9 modules,
but as we know that several of our artifacts are being consumed 
outside OSGi,
I am sure that clients will expect our artifacts to be consumable as 
Java 9

modules sooner or later. And then a general solution looks cleaner to me
then doing this for selected artifacts only.

best,
Stephan

Reference for naming of automatic modules:
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...- 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev