[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Support for Java 9 modules
|
We (JDT) have just been toying with the opposite direction:
add module-info.java to an existing OSGi bundle.
I only then noticed that none of our OSGi bundles can be
consumed as automatic JPMS modules, because the algorithm
for names of automatic modules, fails to cut off the version
from jar files like
org.eclipse.equinox.common.3.9.0.v20170207.jar
Due to lack of a separating "-" we end up with an illegal
module name of
org.eclipse.equinox.common.3.9.0.v20170207
I'm not even sure if this is a useful exercise, but in case
it might be: should we recommend / request that all future
releases of Eclipse plug-ins specify a legal module name
via Automatic-Module-Name manifest attribute?
Or could the names of jar files be adjusted to use "-" as in
org.eclipse.equinox.common-3.9.0.v20170207.jar
I believe, p2 could absorb this change, no? It would then be
an issue of convincing tools like PDE and tycho to produce jars
with a modified naming scheme? (Or CBI aggregator for that matter).
best,
Stephan
On 05.10.2017 15:12, Thomas Watson wrote:
Not sure if you are aware of the work I have done for JPMS inter-op [1]
During my prototyping of inter-op I also did try implementing what you suggest, by adapting Java 9 modules to OSGi bundles on the
fly (See [2]). I know this is possible to do, but much more thought is needed before making any concrete proposal. In my
experiment the equinox hook discovers the JPMS modules in the VM and then virtualizes them into bundles represented in the OSGi
Framework. The other part of the solution is to adapt module jars that are installed as bundles by discovering their Java 9
ModuleDescriptor and generating the equivalent OSGi meta-data for the Framework. Then when the bundles representing the JPMS
modules are resolved they can properly resolve against the virtualized JPMS modules I created for the boot layer modules.
But there are gotchas to this approach that make it seem less useful than you would think. The tool for interactions between Java 9
modules is to use ServiceLoader. I've not cracked that nut to get ServiceLoader to work correctly when you do this type of
virtualization of the Java 9 modules into an OSGi Framework's module system. If that is not made to work seamlessly then I question
the value of using pure JPMS modules in an OSGi Framework without some kind of more advanced transformation of the module.
Beyond that you would need a load of work to get the tools for building your OSGi bundles which depend on the pure JPMS modules such
that the tools know that at runtime this module will really be a bundle with a certain set of capabilities. That is why I suggested
an easier approach is to build up the tools to make it easy for module developers to insert the necessary OSGi meta-data into their
own Java 9 modules along side their module-info.class files. This will allow all the existing tools to work with such module jars
along with the existing OSGi Framework implementations.
I do welcome others to come and assist in this experiment though. If we get something that is more useful then we can consider
bringing it into Equinox or take the steps to standardizing the approach at the OSGi Alliance.
Tom
[1] http://blog.osgi.org/2016/08/osgi-with-java-modules-all-way-down.html
[2] https://github.com/tjwatson/osgi-jpms-layer/blob/master/osgi.jpms.layer/src/osgi/jpms/internal/layer/EquinoxJPMSSupport.java#L113
----- Original message -----
From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [equinox-dev] Support for Java 9 modules
Date: Thu, Oct 5, 2017 3:59 AM
Thanks Tom, for the answer.
I was hoping to simplify the consumption of Maven central for RCP
development. From my Android development experience, I can tell that
it is pure fun to try out a new library (simply by adding it to the
Gradle build file). Doing the same for RCP is relatively
time-consuming (convert the lib and all of its dependencies to become
an OSGi bundle and at it to the target platform).
But from your answer, I understand that OSGi / Equinox does currently
not plan to simplify the consumption of the Java 9 modules. So we have
to stay with the old conversion process.
Thanks again for the answer, Lars
On Wed, Oct 4, 2017 at 8:20 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
> Something like that could be done, but I question the approach. Seem like
> something that made it easy to stick OSGi meta-data into a module archive
> (jar) would be better. Something like Eclipse Bundle Recipes or using BND
> tools directly.
>
> Tom
>
>
>
>
> ----- Original message -----
> From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> Cc:
> Subject: [equinox-dev] Support for Java 9 modules
> Date: Wed, Oct 4, 2017 11:22 AM
>
> Hi,
>
> are there plans to support Java 9 modules in OSGi / Equinox?
>
> We used to have the Eclipse 2.0 compatibility layer which converted a
> 2.0 style plug-in to a valid OSGi bundle.
>
> Maybe Equinox could provide a similar thing for converting Java 9
> modules to valid OSGi bundles.
>
> Best regards, Lars
>
> --
> Eclipse Platform UI and e4 project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vogella.com&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs&m=ugHZ-frWDCYQS_Cb3hPN0I0WewjdYO92jPqvcVSG3bw&s=OzGhQ_mFH_MF8rUrBUtTi_AF3V4lp7nX0vY08nARvJ8&e=
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> 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_equinox-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs&m=ugHZ-frWDCYQS_Cb3hPN0I0WewjdYO92jPqvcVSG3bw&s=nRuE9sxo1_EZtTqHz2I_vl8BbMdP4swTZ9H4ihTn4Gw&e=
>
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> 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_equinox-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs&m=iL7hwl0mlpW0bH4CPjZe35EpWH6ntszDLZkvE5cCl3E&s=sXO4wmVohtTRa9rVyazQAJ2Ybdbl_w6IEB5xhfv8lWw&e=
--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vogella.com&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs&m=iL7hwl0mlpW0bH4CPjZe35EpWH6ntszDLZkvE5cCl3E&s=eI3GYolqq9AXzanUetHY54uwL1ZOZCxYexsu5LwDjRU&e=
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
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_equinox-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs&m=iL7hwl0mlpW0bH4CPjZe35EpWH6ntszDLZkvE5cCl3E&s=sXO4wmVohtTRa9rVyazQAJ2Ybdbl_w6IEB5xhfv8lWw&e=
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
