[tycho-user] Tycho and Kotlin

[Craig Otis]

I'm researching the potential benefits/pitfalls of moving some of our
codebase, which is based heavily on Eclipse RCP and thus also OSGi, from
Java to Kotlin.

We're currently using the Tycho OSGi Compiler Plugin through Maven to
assist in dependency management (with our own custom target platform), and
project compilation. We're able to swap out the [tycho-compiler-plugin] for
a combination of the [kotlin-maven-plugin] and the standard
[maven-compiler-plugin], which works as expected for one of our projects
that has no OSGi dependencies.

However - for our projects whose dependencies are MANIFEST-based and rely
on Tycho/OSGi for dependency resolution/target platform computation, I'm
wondering if we've hit a roadblock - as Kotlin needs to compile the Java
bytecode prior to the other (Tycho/Maven) compilers kicking in, but if any
of those Kotlin classes depend on the OSGi dependencies, our concern is
that it won't be able to resolve them - so it's a bit of a chicken/egg
problem.

Are there any guides/plans for supporting a Tycho + Kotlin build
configuration, or tips to point us in the right direction?

Regards,
Craig Otis

[Mickael Istria]

Hi,

Post by Craig Otis
I'm researching the potential benefits/pitfalls of moving some of our
codebase, which is based heavily on Eclipse RCP and thus also OSGi, from
Java to Kotlin.

I think the main pitfall (general to the adoption of whatever other
language on top of the JVM in any environment, not only RCP/OSGi) is that
all this Kotlin code would only be reusable in Kotlin apps, and not in Java
apps that easily, or at least not without brinding to the JVM the necessary
Kotlin runtime classes. I don't know how well does Kotlin work in all Java
environments (OSGi/RCP, Java 9, JBoss Modules, Maven...), but if it's not
yet universally supported in any Java application, adopting it can become
an issue. So you're basically adding one layer of indirection, one layer of
dependencies, one layer of build, one layer of potential issues... Maybe
it's worth it in your case, but moving existing code from a language to
another is usually hard to be profitable.
Writing only new code in Kotlin (or whichever other JVM friendly language)
maybe a safest path if you really want to jump in the Kotlin boat.

Post by Craig Otis
We're currently using the Tycho OSGi Compiler Plugin through Maven to
assist in dependency management (with our own custom target platform), and
project compilation. We're able to swap out the [tycho-compiler-plugin] for
a combination of the [kotlin-maven-plugin] and the standard
[maven-compiler-plugin], which works as expected for one of our projects
that has no OSGi dependencies.
However - for our projects whose dependencies are MANIFEST-based and rely
on Tycho/OSGi for dependency resolution/target platform computation, I'm
wondering if we've hit a roadblock - as Kotlin needs to compile the Java
bytecode prior to the other (Tycho/Maven) compilers kicking in, but if any
of those Kotlin classes depend on the OSGi dependencies, our concern is
that it won't be able to resolve them - so it's a bit of a chicken/egg
problem.
Are there any guides/plans for supporting a Tycho + Kotlin build
configuration, or tips to point us in the right direction?

You can look at how the Kotlin-Eclipse plugin is implemented:
https://github.com/JetBrains/kotlin-eclipse/blob/master/pom.xml and
https://github.com/JetBrains/kotlin-eclipse/blob/master/kotlin-eclipse-ui/pom.xml
. Seems like they simply bind the compile step of the kotlin-maven-plugin
to the "process-sources" phase and do some AspectJ stuff.

HTH

[Sievers, Jan]

However - for our projects whose dependencies are MANIFEST-based and rely on Tycho/OSGi for dependency resolution/target platform
computation, I'm wondering if we've hit a roadblock - as Kotlin needs to compile the Java bytecode prior to the other (Tycho/Maven)
compilers kicking in, but if any of those Kotlin classes depend on the OSGi dependencies, our concern is that it won't be able to resolve
them - so it's a bit of a chicken/egg problem.

Tycho injects the resolved OSGi dependencies back into the maven project model so other (non-OSGi aware) maven plugins have access to the OSGi compile classpath. I know that e.g. the PMD and sonar plugins rely on this when run on a Tycho project.
So in principle it should be possible to run another compiler as long as it's getting its compilation classpath from
maven's standard project model

MavenProject.getCompileClasspathElements()

You could bind this compiler to a phase prior to compile to make sure it runs before tycho-compiler-plugin.
Note that I don't know anything about kotlin so I may be completely wrong.

Regards,
Jan

[Henrik Steudel]

Hi,
AFAIK dependencies injected from Tycho are in SYSTEM resolution scope.
Some non-OSGI maven plugins instead only consider COMPILE scope and
therefore do not pick dependencies.

The scope of the Kotlin compiler plugin is COMPILE:

@Mojo(name="compile", defaultPhase=LifecyclePhase.COMPILE,
requiresDependencyResolution=ResolutionScope.COMPILE
(https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-maven-plugin/src/main/java/org/jetbrains/kotlin/maven/K2JVMCompileMojo.java).

Is MavenProject.getCompileClasspathElements() delivering a different
result than project.getDependencies() when resolving dependencies and
therefore picks up these SYSTEM dependencies?


Kind regards
Henrik

Post by Sievers, Jan

However - for our projects whose dependencies are MANIFEST-based and rely on Tycho/OSGi for dependency resolution/target platform
computation, I'm wondering if we've hit a roadblock - as Kotlin needs to compile the Java bytecode prior to the other (Tycho/Maven)
compilers kicking in, but if any of those Kotlin classes depend on the OSGi dependencies, our concern is that it won't be able to resolve
them - so it's a bit of a chicken/egg problem.

Tycho injects the resolved OSGi dependencies back into the maven project model so other (non-OSGi aware) maven plugins have access to the OSGi compile classpath. I know that e.g. the PMD and sonar plugins rely on this when run on a Tycho project.
So in principle it should be possible to run another compiler as long as it's getting its compilation classpath from
maven's standard project model
MavenProject.getCompileClasspathElements()
You could bind this compiler to a phase prior to compile to make sure it runs before tycho-compiler-plugin.
Note that I don't know anything about kotlin so I may be completely wrong.
Regards,
Jan
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

--
Entimo AG
Stralauer Platz 33 - 34 | 10243 Berlin | Germany
Tel: [phone] | Fax: [phone]
***@entimo.com | http://www.entimo.com/

Vorstand: JÃŒrgen Spieler (Vors.), Marianne Neumann
Aufsichtratsvorsitzender: Erika Tannenbaum

Sitz der Gesellschaft: Berlin, Germany | Handelsregister: HRB Berlin-Charlottenburg 85073

[Carsten Reckord]

@Mojo(name = "compile", defaultPhase = LifecyclePhase.COMPILE,
requiresDependencyResolution = ResolutionScope.COMPILE
(https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-
maven-
plugin/src/main/java/org/jetbrains/kotlin/maven/K2JVMCompileMojo.java).
Is MavenProject.getCompileClasspathElements() delivering a different
result than project.getDependencies() when resolving dependencies and
therefore picks up these SYSTEM dependencies?

ResolutionScope.COMPILE documentation says so: "compile resolution scope = compile + system + provided dependencies", see [1]. And the Mojo API docs say the same about the Mojo.requiresDependencyResolution element, see [2].

[1] https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/ResolutionScope.html#COMPILE
[2] https://maven.apache.org/developers/mojo-api-specification.html

[Henrik Steudel]

Carsten,
you are correct. Thanks for clarification.
Kind regards

Post by Carsten Reckord

@Mojo(name = "compile", defaultPhase = LifecyclePhase.COMPILE,
requiresDependencyResolution = ResolutionScope.COMPILE
(https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-
maven-
plugin/src/main/java/org/jetbrains/kotlin/maven/K2JVMCompileMojo.java).
Is MavenProject.getCompileClasspathElements() delivering a different
result than project.getDependencies() when resolving dependencies and
therefore picks up these SYSTEM dependencies?

ResolutionScope.COMPILE documentation says so: "compile resolution scope = compile + system + provided dependencies", see [1]. And the Mojo API docs say the same about the Mojo.requiresDependencyResolution element, see [2].
[1] https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/ResolutionScope.html#COMPILE
[2] https://maven.apache.org/developers/mojo-api-specification.html
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

--
Entimo AG
Stralauer Platz 33 - 34 | 10243 Berlin | Germany
Tel: [phone] | Fax: [phone]
***@entimo.com | http://www.entimo.com/

Vorstand: Jürgen Spieler (Vors.), Marianne Neumann
Aufsichtratsvorsitzender: Erika Tannenbaum

Sitz der Gesellschaft: Berlin, Germany | Handelsregister: HRB Berlin-Charlottenburg 85073