537320 : Regression on support for "external" bundle-classpath about tycho

[laeubi]

You should really upgrade to tycho 2.3.0, previous versions are no longer officially supported.

Can you give a reference on PDE or JDT that describes the semantic and support of Bundle-ClassPath : external:$user.dir I have never heard about it and you are most probably the only consumer of that feature given that it is broken for such a long time.
Can you describe the usecase? Tycho might support better alternatives maybe?

[mickaelistria]

@laeubi see https://bugs.eclipse.org/bugs/show_bug.cgi?id=537320#c13 for details of where external: is used by Equinox.

[laeubi]

I have checked the code and it seems this is intended for Bundle-Native code indeed that it works for Bundle-ClassPath seems not be covered by any test, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=238675 that mentions this feature...

[laeubi]

@lazyleo13 can you provide a Pull Reqeust with a failing test-case in https://github.com/eclipse/tycho/tree/master/tycho-its that shows the problem?

[laeubi]

it seems org.eclipse.osgi.internal.framework.EquinoxConfiguration.ConfigValues is responsible for parsing this, we might can copy the code here, but I still get the impression that this is solely for native code as the real entry where this is used resides in org.eclipse.osgi.storage.NativeCodeFinder

[Kellindil]

Please note that a failing test case is available on the original bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=537320

[Kellindil]

This actually seems to be a regression in the jdt instead of tycho.

Specifically, org.eclipse.jdt.internal.compiler.apt.util.EclipseFileManager.setLocation(Location, Iterable<? extends File>) has changed in such a way that it tries to parse the classpath entries as java.nio.file.Path... which cannot work with "external:" references. This regression was introduced by https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c798229d351d6daa2232cff6c15750336659223e .

I am not sure where to go from there. It seems like we would have to actually parse the classpath entry before we even pass it to org.eclipse.jdt.internal.compiler.batch.Main (from org.eclipse.tycho.compiler.jdt.JDTCompiler.compileInProcess(String[], CustomCompilerConfiguration)) in order to either a) send a resolved entry or b) not send it at all ?

[laeubi]

@Kellindil if its a problem with JDT it should be resolved/reported there. Once it is fixed and released, we can integrate this in tycho.

[Kellindil]

I have raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=575072 to track this against the JDT

[Kellindil]

For anyone else stumbling on this and until bug 575072 is fixed by the JDT team. If what you are building is a product, you can use the following to workaround this issue:

• remove the "external:" prefix from the MANIFEST.MF classpath entries (so that the build through tycho can finish)
• add the "Eclipse-BundleShape: dir" entry to the same MANIFEST.MF (which means in the product generated by your build, the plugin will be there in the form of a plain folder instead of a jar file in the "plugins" folder)
• use the maven-replacer-plugin to manually prefix all classpath entries with "external:" in that MANIFEST in the generated product (these classpath entries will be read and resolved when first starting the product, so as long as the external prefix is there, eclipse will properly resolve against an external path). Make sure it is called in the "package" phase.

Here is how it looks like in my build for reference. all of my "external:" entries start with a vm variable so I can match "$var" to easily locate the lines I need to prefix, adjust for your scenario :)

<plugin>
        <groupId>com.google.code.maven-replacer-plugin</groupId>
        <artifactId>replacer</artifactId>
        <version>1.5.3</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>replace</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <includes>
            <include>${project.build.directory}/products/${product-bundle-id}/linux/gtk/x86_64/plugins/my.plugin.id_${qualifiedVersion}/META-INF/MANIFEST.MF</include>
            <include>${project.build.directory}/products/${product-bundle-id}/win32/win32/x86_64/plugins/my.plugin.id_${qualifiedVersion}/META-INF/MANIFEST.MF</include>
          </includes>
          <replacements>
            <replacement>
              <!--
                Due to the formatting of manifest files, we may have an EOL at any offset in our token, hence this ugly looking regex.
                We try and match "$var" regardless of whitespaces.
                Note that we do not need to reformat the MANIFEST after adding the "external:" prefix as the MANIFEST reading is lenient on the 72 char limit for lines.
              -->
              <token>(\$\s*?v\s*?a\s*?r)</token>
              <value>external:$1</value>
            </replacement>
          </replacements>
        </configuration>
      </plugin>

[laeubi]

As no action for more than a year I'll close this for now as it seems JDT still don't support this. But feel free to report back here if there is still something to do and we can make progress e.g. by provide an integration-test to demonstrate the issue and JDT has fixed the problem.