Fix JDK9 plugin when using OSGi

[Roiocam]

Continue my digging: #1040 (comment)

And found a solution that can easily fix the JDK9 plugin, which changes the JDK9 product's inject place, the original inject place is fullClasspath, but sbt-osgi doesn't use them anymore, so a simple change could fix our problem and without dependency upstream update.

Compile result

Unzip Jar

[Roiocam]

cc @He-Pin @mdedetrich @pjfanning

[He-Pin]

just checked on jdk 21

The result is ok, but osgibundle took 115s+ :)

and in osgi plugin

[He-Pin]

lgtm, and thank you. the code match the one in sbt-osgi, will let @mdedetrich take a look

[Roiocam]

But looks like it can not package on JDK8 anymore:

[Roiocam]

But looks like it can not package on JDK8 anymore:

Good news, I just fixed this via a simple filter.

[mdedetrich]

Nice find I missed this part, I was trying to solve it another way.

This indeed seems to be correct location where the sbt-osgi workaround was historically done and I wasn't aware of it's existence. In general we need to look at how to solve this problem in a more sane way since the current implementation is really brittle, i.e. whenever sbt-osgi changes how something is packaged any other plugin which modifies the classpath in some way can also be inadvertently effected.

Pinging @eed3si9n since you asked before about this problem specifically incase you are still curious. There might be a case of re-thinking how to solve this problem in a more principled way, possibly for SBT 2.x.x?

[He-Pin]

@Roiocam @mdedetrich I think we can merge this first, any changes can come up after. and I can send a PR to test if the paradox fail with wrong java 9 related doc.

[mdedetrich]

@Roiocam @mdedetrich I think we can merge this first, any changes can come up after. and I can send a PR to test if the paradox fail with wrong java 9 related doc.

I will defer to @Roiocam w/e he thinks is best. @Roiocam If you want us to merge the PR as is so you can make a new one just let me know.

[Roiocam]

I will defer to @Roiocam w/e he thinks is best. @Roiocam If you want us to merge the PR as is so you can make a new one just let me know.

I have investigated the problem of protobuf-v3 for a while, and I don't think there is any problem with the existing methods.

Since the sbt-osgi upgrade, there dependency has big change, but sbt-assembly only depends on Compile / fullClasspath, we could make osgiBundle depends on sbt-assembly, but they assembly result won't compact to osgi jar. I think we could make this PR merged, and then use another issue to find out if it has a better solution for sbt-assembly or not.

10a11,12
> [info] 	protobuf-v3 / Compile / dependencyClasspathAsJars
> [info] 	protobuf-v3 / osgiCacheBundle
13d14
< [info] 	protobuf-v3 / Compile / fullClasspath
20a22
> [info] 	protobuf-v3 / Compile / products

[mdedetrich]

Fair enough, I will go ahead and merge this PR and we can discuss this point later if needed.

Thanks again for fixing this!