Tycho 3.0.0 incompatibilities

[bjmi]

Running p2:site with Maven 3.8.6 and Tycho 3.0.0 ends up with

[INFO] --- p2-maven-plugin:2.0.0:site (default-cli) @ tycho-modules-site ---
[WARNING] Error injecting: org.reficio.p2.P2Mojo
com.google.inject.ProvisionException: Unable to provision, see the following errors:

1) No implementation for org.eclipse.sisu.equinox.launching.internal.P2ApplicationLauncher was bound.
  while locating org.reficio.p2.P2Mojo

1 error
    at com.google.inject.internal.InternalProvisionException.toProvisionException (InternalProvisionException.java:226)
    at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
    at com.google.inject.internal.InjectorImpl.getInstance (InjectorImpl.java:1086)
    at org.eclipse.sisu.space.AbstractDeferredClass.get (AbstractDeferredClass.java:48)
    at com.google.inject.internal.ProviderInternalFactory.provision (ProviderInternalFactory.java:85)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision (InternalFactoryToInitializableAdapter.java:57)
    at com.google.inject.internal.ProviderInternalFactory$1.call (ProviderInternalFactory.java:66)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision (ProvisionListenerStackCallback.java:112)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision (ProvisionListenerStackCallback.java:127)
    at com.google.inject.internal.ProvisionListenerStackCallback.provision (ProvisionListenerStackCallback.java:66)
    at com.google.inject.internal.ProviderInternalFactory.circularGet (ProviderInternalFactory.java:61)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.get (InternalFactoryToInitializableAdapter.java:47)
    at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
    at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
    at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
    at org.eclipse.sisu.plexus.LazyPlexusBean.getValue (LazyPlexusBean.java:51)
    at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:263)
    at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:255)
    at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo (DefaultMavenPluginManager.java:520)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:124)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:370)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:351)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:171)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

[gtsh]

Can corroborate and evaluate:
Tried several versions of Maven and Tycho. Tycho 2.5.0 seems to require a Maven at least after 3.2.5.
For 3.2.5, I see a weird NullPointerException at startup of Tycho during initialization.

It started working for me with Maven 3.6.3. (Skipped the intervening versions, because I was too lazy to install them and it is a Tycho/Maven issue anyway, but it serves to demonstrate, that the promise of Reficio, that it is going to work with Maven up to 3.2 is likely void for recent versions of Tycho)

It is also working with Tycho 2.7.5 and Maven 3.8.6

But it actually stops working with Tycho 3.0.0 -> Obviously, Tycho 3.0.0 breaks the Reficio:p2-maven-plugin.

[bjmi]

In eclipse-tycho/tycho@72747e7 org.eclipse.sisu.equinox.launching.internal.P2ApplicationLauncher has been removed.

[gtsh]

It is more complicated than just that, I investigated further:

• between 2.5 and 3.0, they (Tycho) switched the version of Maven, they compile against.
• also, they now require JDK 17.
  In their pom, you'll see:

		<min.jdk.version>17</min.jdk.version>
                ...
                <maven-version>3.8.6</maven-version>

• and:, the TychoConstants suffered a package move.
  Upgrading, kicking and rattling the dependencies and some minor code adaptions seem to work out, though.
  I'm working on a patch, but not yet quite there.

[sparsick]

Thanks for analyzing the problem. Would it be helpful for your patch to prepare an update to the last 2.x version of Tycho (including a release) and update the master branch to Java 17. It seems that Java 17 is mandatory for Tycho 3.x

[gtsh]

It would certainly not hurt. To an extend, it would depend on how comfortable you feel about switching to 17 coming from 8, in my carrer, I encountered a lot of organizations really conservative on JDK updates, that weren't too lucky about getting that pushed down their throat. I found that a surpringly bold move on part of tycho. Just as surprising as skiping to Maven 3.8.3 from 3.2.x. But I'm the last one to complain, and would be comfortable leaving them behind.

When switching to 2.7.5, the last pre 3.0 Tycho release, make sure to match their maven-version on your build, so you can rely on Javas compile time guarantees.

But you should point out these changes on your readme, i. e. updating your prerequisites. (Tycho seemes to miss this too).

The patch is going to take some time. Following @bjmjs hint shows, that Tycho replaced the P2ApplicationLauncher essentially with nothing.
So I got to figure out an alternate way of invocation from scratch.

[bjmi]

As a workaround we could split our build into a "p2" build and "tycho" build and could circumvent the tycho version dependence.

[gtsh]

Hm. I'm not that familiar with all that stuff, I'm still struggling to wrap my head around the mess that is stacking OSGi, Equinox and Tycho on top of each other, let alone to start an OSGi service within a maven build. Is a catalog an Equinoxe or a Tycho thing?
If the former, using Tycho would be a pure thing of convenience, i. e. not requiring to roll your own catalog builder. If there is enough support for this in the lower tiers, say Equinox, we might collapse a whole tier, and cutting out Tycho as an intermediate.

So it boils down to the question: how expensive is it to do this without Tycho?

[sparsick]

@gtsh p2 maven plugin tried to reuse already existing implementation from maven bundle plugin and Tycho.

IMHO Tycho started a new way how to handle maven artifacts in a Tycho build (see this blog post and a Twitter discussion). Also, they created a bunch of new p2 plugins (Had no time to analyze them).

First Idea: Maybe we can move the deleted code to this plugin and try to reduce the dependency to Tycho. I need some time to analyze that.

[gtsh]

Meanwhile I experimented a bit on my own, and found out, that this might be way over my head.
My first attempt at trivially replacing the P2-Launcher by instantiating CategoryPublisherApplication my self failed, since I should have done this in an Equinoxe/OSGi-container. Currently, I don't even know, how I get one within Maven.
If this is a recurring thing with Tycho, there should be some other way to start one from within Maven, that can be reused?
Time to analyze the Tycho-Plugins to find out?

[gtsh]

Some more hints, you might already know: https://rtist.hcldoc.com/help/topic/org.eclipse.platform.doc.isv/guide/p2_publisher.html#category_publisher has the command line invocation of the CategoryPublisherApplication.

The startup - as mentioned above - actually fails for me, because the org.eclipse.equinox.internal.p2.publisher.Activator hasn't its BundleContext set.

[sparsick]

Thanks, @gtsh, for your analysis. I found the issue where the P2ApplicationLauncher was replaced. They use now a TychoFeaturesAndBundlesPublisherApplication that is part of an also called p2-maven-plugin. It seems for me that is a 1:1 replacement.

[sparsick]

@gtsh I had some time to go deeper into the analysis. I t seems we can use the CatogoryPublisherApplication directly in the code if an embedded Equinox is started (therefore you got a NullPointerException). Tycho has already implemented an equinox sisu integration. I need some time to figure out how it works (currently I don't find a documentation about it)

[gtsh]

I actually figured as much, but was not able to pinpoint, how Tycho starts its OSGi-Context. A detail of that is the question, whether this would be a unique OSGi container started once for the complete maven lifecycle and then reused, or whether you may have one just for that one mojo execution.

In the back of my mind is, that it might be possible, to inject Tycho's mojo into ours, then delegate. If we are lucky, the mojo knows, how and when to create the container, or to join an existing one.

Else, it might be possible, to build a trivial project with just that mojo, to explore with the debugger.

[sparsick]

Hi @gtsh,

I tried out to call 'mvn org.eclipse.tycho:tycho-p2-plugin:3.0.0:category-p2-metadata' manually. But without a Tycho context, I get a NullPointerExeption. I think this problem is similar to the problem that is described in this Tycho issue

Currently, it seems, I had to move the old Tycho logic to this plugin or find out how to use the equinox sisu integration.

[daniel-matheis-vivavis]

Any more progress or new ideas how to get this solved?
Or are there alternative ways to replace p2-maven-plugin features in the future?

[raner]

I just ran into this issue myself. I'm working on a project that will typically perform a major upgrade of all its dependencies once a year, and sadly this is the third year in a row where p2-maven-plugin broke in one way or another due to the update. The reliance on internal implementation details of other plug-ins and modules is probably the main contributing factor for these repeated breakages.

I had to upgrade to Tycho 3.0.5 (from 2.7.5) for other reasons, and as @gtsh and @bjmi have already pointed out, the 3.0.5 version of tycho-core no longer contains P2ApplicationLauncher. I may be naive here, but I don't fully understand how p2-maven-plugin picks up the new Tycho version in the first place. Doesn't Maven's Plexus DI/dependency management system have a similar hierarchical class loading/class isolation feature as OSGi? (maybe that's my misconception?) I guess I don't fully understand how a ${tycho.version} variable that's used by tycho-compiler-plugin overrides p2-maven-plugin's own declared Tycho 2.7.5 dependency when p2-maven-plugin:site is executed.

At any rate, does anyone have any progress to report this issue? (fork with a fix, work-around, alternative plugin?)
Staying on Tycho 2.7.5 for the build is unfortunately not an option for me.

[sparsick]

Hi @daniel-matheis-vivavis, @raner,

I started an implementation, where I try to merge Tycho old logic in this plugin. It doesn't work well.

In https://github.com/sparsick/p2-maven-plugin/tree/297-updateTycho3 you can find the current state of my implementation.

Which options we have?

• maybe someone have time to finish the above started implementation
• you migrate your project to this approach: https://läubisoft.gmbh/en/articles/using-maven-artifacts-in-pde-rcp-and-tycho-builds/

Currently, I can't find time to finish it (this issue has currently not so high priority in my projects). But I could answer questions if someone want to finish it.

[raner]

Thanks for your prompt reply, @sparsick :-) and thanks for sharing a starting point for an implementation.

It seems that the key will be to find a replacement for P2ApplicationLauncher, but I'm hesitant to go down that road, since it will still depend on other modules' internal implementation details and might break again with the next release.

I'm still looking at the läubisoft blog article you shared, but it seems it has a lot of manual steps, which might not work for me since I need to be able to consume updated versions of dependencies in a fully automated fashion from within the Maven build. If a version update of a dependency requires a manual step, this approach won't really work.

In the meantime, I might have found a way to stay on Tycho 2.7.5 for my project. If I can make that work, hopefully, p2-maven-plugin should still work as desired.

[sparsick]

My naive approach was to just copy and paste the deleted classes from the Tycho project to the plugin.

But the integration tests fail with errors (I don't have them to hand right now).

This commit removes the original P2ApplicationLauncher.