chore: enforce assembly execution order

[Roiocam]

Motivation

• Avoid repeatedly modifying packageBin semantics
• Avoid executing assembly on other module
• Enforce dependency order: osgiBundle -> assembly -> compile

Verified

Execute sbt protobuf-v3 / packageBin, and then we will be observed the execution result like assembly -> osgiBundle.

It won't break assembly when executing packageBin or osgiBundle.

[Roiocam]

Draft because sbt-depend-walker not publish yet.

[mdedetrich]

@Roiocam Have you tried the sbt-osgi caching option, i.e. sbt/sbt-osgi#100 ? I believe this was explicitly designed to solve this issue and may be less heavy handed?

[Roiocam]

@Roiocam Have you tried the sbt-osgi caching option, i.e. sbt/sbt-osgi#100 ? I believe this was explicitly designed to solve this issue and may be less heavy handed?

Thanks, I have enabled this, it will reduce the execution of the osgiBundle.

[mdedetrich]

@Roiocam So I don't want to stop the PR, but I just want to make you aware (if you aren't already) that there generally is an issue with how sbt-osgi interacts with other packaging type of tasks i.e. ssembly,multi-release-jar/jdk9 etc etc when it comes to ordering and there are long discussions on this i.e.

• Compile / sbt.Keys.packageBin := bundle.value can cause infinite recursive loop sbt/sbt-osgi#104 (comment)
• Fix regression when using Jar's to force proper manifest files sbt/sbt-osgi#102 (comment)

The reason why I am pointing this out is that it may make sense to take a step back and resolve this problem in a principled way within sbt-osgi (although this can be done later!). For example as a quick idea that came to the top of my head, it makes sense to add the capability of adding sbt Configuration's aka Config's to sbt-osgi in a similar way that is done with sbt-header so that sbt-osgi is aware of other configs and then can handle ordering issues accordingly/correctly

Also note I am a maintainer on sbt-osgi so if you open up PR's there with tests I can review them

[Roiocam]

@Roiocam So I don't want to stop the PR, but I just want to make you aware (if you aren't already) that there generally is an issue with how sbt-osgi interacts with other packaging type of tasks i.e. ssembly,multi-release-jar/jdk9 etc etc when it comes to ordering and there are long discussions on this i.e.

How should we solve this problem? In my opinion, the real issue is sbt-osgi overwrited the Task( Compile / packageBin), and not calling (Compile / fullClasspath). JDK9 plugin broken by this, and sbt-assembly too.

Why sbt-assembly doesn't overwrite packageBin but instead let user choose? I think the sbt-osgi should be doing this too.

As for fullClasspath blocker issue, i think this sbt/sbt-osgi#103 doesn't help. Why not change like this:

  lazy val defaultOsgiSettings: Seq[Setting[_]] = {
    import OsgiKeys._
    Seq(
+     (Compile / exportJars) := false,
      bundle := Osgi.bundleTask(
        manifestHeaders.value,
        additionalHeaders.value,
 -      (Compile / dependencyClasspathAsJars).value.map(_.data) ++ (Compile / products).value,
+       (Compile / fullClasspath).value.map(_.data) ++ (Compile / internalDependencyAsJars).value.map(_.data),
        (Compile / packageBin / artifactPath).value,
        (Compile / resourceDirectories).value,
        embeddedJars.value,
        explodedJars.value,
        failOnUndecidedPackage.value,
        (Compile / sourceDirectories).value,
        (Compile /  packageBin / packageOptions).value,
        packageWithJVMJar.value,
        cacheStrategy.value,
        streams.value),
-     Compile / sbt.Keys.packageBin := bundle.value,

Let me explain that osgiBundle itself will be packaged thing into the jar, so we could avoid the task graph like packageBin -> osgiBundle -> fullClasspath -> exportProduct -> packageBin.

As for internalDependencyAsJars, because fullClasspath doesn't contain manifest. And the dependencyClasspathAsJars just a concat of internalDependencyAsJars and externalDependencyClasspath.

So we could replace them. This should fix the issues of JDK9 and assembly not executing issue, because when we execute osgiBundle, we will execute compile/fullClasspath.

[Roiocam]

So we could replace them. This should fix the issues of JDK9 and assembly not executing issue, because when we execute osgiBundle, we will execute compile/fullClasspath.

I haven't verified yet.

[Roiocam]

So we could replace them. This should fix the issues of JDK9 and assembly not executing issue because when we execute osgiBundle, we will execute compile/fullClasspath.

Yes, I have confirm this, and the manifest has been keep too.

> diff newpb/META-INF/MANIFEST.MF oldpb/META-INF/MANIFEST.MF
5c5
< Bnd-LastModified: 1706633706879
---
> Bnd-LastModified: 1706633635527
7c7
<  0-8a759bad20240131-0054-SNAPSHOT",org.apache.pekko.protobufv3.internal.
---
>  0-8a759bad20240130-2351-SNAPSHOT",org.apache.pekko.protobufv3.internal.
9c9
<  310-8a759bad20240131-0054-SNAPSHOT"
---
>  310-8a759bad20240130-2351-SNAPSHOT"
15c15
< Specification-Version: 1.1.0-M0+310-8a759bad+20240131-0054-SNAPSHOT
---
> Specification-Version: 1.1.0-M0+310-8a759bad+20240130-2351-SNAPSHOT
22,23c22,23
< Bundle-Version: 1.1.0.M0310-8a759bad20240131-0054-SNAPSHOT
< Implementation-Version: 1.1.0-M0+310-8a759bad+20240131-0054-SNAPSHOT
---
> Bundle-Version: 1.1.0.M0310-8a759bad20240130-2351-SNAPSHOT
> Implementation-Version: 1.1.0-M0+310-8a759bad+20240130-2351-SNAPSHOT
32c32
<  20240131-0054-SNAPSHOT
---
>  20240130-2351-SNAPSHOT
~

[Roiocam]

Blocked by sbt/sbt-osgi#131

[He-Pin]

@Roiocam You can change it to draft.

[Roiocam]

@Roiocam You can change it to draft.

I don't think this PR is necessary after reviewing #1125 and trying it on my local, so I closed it.