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
I think that’s an overstatement of what Tom said. It’s not that OSGi doesn’t
plan to simplify consumption of JPMS modules. OSGi is certainly looking at
possible ways forward for interoperability with JPMS modules, but those
discussions are in their early stages.
I don’t speak for the OSGi
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
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
I think we should be explicit in deciding what our automatic module name is instead of depending on what the file name is on disk. Anyone can rename our bundle file names on disk, that does not change what its OSGi Bundle-SymbolicName is. Therefore I would advocate we use the
On 05.10.2017 22:26, Thomas Watson wrote:
I think we should be explicit in deciding what our automatic module name is instead of depending on what the file name is on disk.
Anyone can rename our bundle file names on disk, that does not change what its OSGi Bundle-SymbolicName is. Therefore I
