Community
Participate
Working Groups
Build Identifier: The case is about putting such entry in MANIFEST.MF of plug-in: Bundle-ClassPath: external: $user.home$/somefile which is compilant with OSGi concept. The attempt of building this plug-in by tycho ends with IOException throwing from org.eclipse.tycho.core.osgitools.DefaultBundleReader#getEntry (line 203) Reproducible: Always Steps to Reproduce: 1.create plugin project with manifest.mf file containing Bundle-ClassPath: external:$user.home$/somefile entry 2. Try to build it to eclipse plugin using tycho 0.13.0
Did I miss something in the OSGi spec? OSGi spec 4.1, chapter 3.8.1 "3.8.1 Bundle Class Path Intra bundle class path dependencies are declared in the Bundle-Classpath manifest header. This declaration allows a bundle to declare its embedded class path using one or more JAR files or directories that are contained in the bundle’s JAR file. The Bundle-Classpath manifest header is a list of comma-separated file names. A file name can be either: • The dot (’.’ \u002E), representing the bundle’s JAR file itself, is the default value if no Bundle-Classpath is specified. • A path to a JAR file contained in the bundle’s JAR file. • A path to a directory contained in the bundle’s JAR file."
I believe this is specific to equinox, see bug 109743 .
(In reply to comment #2) > I believe this is specific to equinox, see bug 109743 . ... so I wouldn't necessarily expect that Tycho to supports this, which makes this an enhancement request. But what is the use case for this again?
Unless someone can give a good usecase that cannot be solved with other means I tend towards won't fix. external references will make the build unreproducible.
Hi, i'm facing this, too. My use case is that i use a third party plugin using this technique, and tycho fails to resolve the dependencies of this third party. Of course, this third party is commercial-not-open-source plugin.... Can tycho just ignore these entries if you don't want to resolve them as equinox does using a -Duser.home="path/to/user" as eclipse vmarg ?
If this is a commercial plugin, you should ask for a fix if you pay for a maintenance
(In reply to Stephane Bouchet from comment #5) > Hi, > > i'm facing this, too. > > My use case is that i use a third party plugin using this technique, and > tycho fails to resolve the dependencies of this third party. > > Of course, this third party is commercial-not-open-source plugin.... > > Can tycho just ignore these entries if you don't want to resolve them as > equinox does using a -Duser.home="path/to/user" as eclipse vmarg ? explicitly ignoring classpath entries starting with "external:" and logging a warning seems OK to me.
@jeff : :) i'll ask, but i'm not sure they will do it ( eclipse is not the primary target of the product, they offer the integration at minima. @jan : thanks, it will at least prevent users they are using something not supported. By now, i will modify the plugin myself, by including the libs myself directly in the plugin, waiting for a fix.
(In reply to Stephane Bouchet from comment #8) > @jan : thanks, it will at least prevent users they are using something not > supported. it's not supported right now and the build will always fail. I proposed to chnage the error to a warning. That means either the build wil fail later (because of missing classpath entries required for compilation) or it will pass if the external classpath entry is required at runtime only.
Right now the build failed during dependencies computation with this error : [ERROR] Internal error: java.lang.RuntimeException: IOException while extracting 'external:$ant.home$/lib/ant.jar' from C:\Users\sbouchet\.m2\repository\p2\osgi\bundle\somebundle\1.0.0\somebundle-1.0.0.jar: La syntaxe du nom de fichier, de r�pertoire ou de volume est incorrecte -> [Help 1] I understand if the builds fails later because of compilation issues. it is suitable for me to show a warning and continue the build.
We would like to use this in a number of bundles where we are not allowed to distribute the jar files in question with our product, but have to download it from the vendors web site and integrate it at runtime. In our case, it is JDBC drivers, but it could be other 3rd party commercial jars as well. And no, we can not expect the world to provide OSGi compliant bundles instead of plain jars... there are still a rather large part of the world that have not seen the light yet... and a significant part that will never see any light... never... For JDBC drivers, the content of the jar file is not exported, so we can work around this by dynamically adding to the classpath of the bundle and use reflection to access the few things that is needed from the jars. But it would be so much easier to have the 3rd party jars on the classpath.
(In reply to Tonny Madsen from comment #11) > We would like to use this in a number of bundles where we are not allowed to > distribute the jar files in question with our product, but have to download > it from the vendors web site and integrate it at runtime. this sounds to me like it's a runtime-only dependency (jars required at runtime but not on compile classpath) > For JDBC drivers, the content of the jar file is not exported, so we can > work around this by dynamically adding to the classpath of the bundle and > use reflection to access the few things that is needed from the jars. But it > would be so much easier to have the 3rd party jars on the classpath. Do you need the JDBC driver on the compile classpath (which I doubt as normally you should be compiling against the JDBC interfaces) or do you need the JDBC driver on the runtime classpath only? If it's a runtime-only dependency, the proposed warning behaviour from comment #7 would help.
https://git.eclipse.org/r/#/c/17351/
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=51ffd7907631b0f14508821010331087d5201340
(In reply to Jan Sievers from comment #4) > Unless someone can give a good usecase that cannot be solved with other > means I tend towards won't fix. > > external references will make the build unreproducible. FYI, one of our GSoC project for Code Recommenders came up with a good use case: OSGi-ifying the JDK's tools.jar in order to integrate with Javadoc. The details of the setup, which works fine with Tycho 0.18.1, BTW, are described in a blog post [1]. Will test this setup with Tycho 0.19.0 now. [1] <http://www.codetrails.com/blog/osgi-ify-your-tools-jar>
(In reply to Andreas Sewe from comment #15) > (In reply to Jan Sievers from comment #4) > > Unless someone can give a good usecase that cannot be solved with other > > means I tend towards won't fix. > > > > external references will make the build unreproducible. > > FYI, one of our GSoC project for Code Recommenders came up with a good use > case: OSGi-ifying the JDK's tools.jar in order to integrate with Javadoc. > The details of the setup, which works fine with Tycho 0.18.1, BTW, are > described in a blog post [1]. Will test this setup with Tycho 0.19.0 now. > > [1] <http://www.codetrails.com/blog/osgi-ify-your-tools-jar> this should still work as far as I can see. This bug was about consuming a bundle with external classpath entries, not producing it.
(In reply to Jan Sievers from comment #16) > this should still work as far as I can see. > > This bug was about consuming a bundle with external classpath entries, not > producing it. Yes, you are right. And it still works with 0.19.0. :-)
(In reply to Jan Sievers from comment #12) > (In reply to Tonny Madsen from comment #11) > > We would like to use this in a number of bundles where we are not allowed to > > distribute the jar files in question with our product, but have to download > > it from the vendors web site and integrate it at runtime. > > this sounds to me like it's a runtime-only dependency (jars required at > runtime but not on compile classpath) There are a few vendor specific JDBC extensions that we like to use, but we can work around these with use of reflections. We have just come up with another example - sorry I cannot give the details for commercial reasons - where the jar is very much needed at compile time. > Do you need the JDBC driver on the compile classpath (which I doubt as > normally you should be compiling against the JDBC interfaces) or do you need > the JDBC driver on the runtime classpath only? > > If it's a runtime-only dependency, the proposed warning behaviour from > comment #7 would help. For JDBC, we could live with this - for the new commercial jar, this would be a problem.
(In reply to Tonny Madsen from comment #18) > For JDBC, we could live with this - for the new commercial jar, this would > be a problem. I think the workaround using extraClasspathElements described in http://www.codetrails.com/blog/osgi-ify-your-tools-jar is worth trying.
To summarize and clarify what has been changed in 0.19.0: "Bundle-ClassPath: external:" entries in referenced bundles were never supported (and silently ignored at best). However there were also situations where they would fail the build because "external:..." was interpreted as a normal path to a nested jar when extracting nested jars for compilation (and this behaviour was depending on filesystem implementation details like e.g. which characters are allowed in a filename). What we changed in 0.19.0 is to safely detect external: classpath entries, log a warning and ignore them.
(In reply to Jan Sievers from comment #19) > (In reply to Tonny Madsen from comment #18) > > For JDBC, we could live with this - for the new commercial jar, this would > > be a problem. > > I think the workaround using extraClasspathElements described in > > http://www.codetrails.com/blog/osgi-ify-your-tools-jar > > is worth trying. It does work in the current scenario, but I foresee some big problems further down the road when we have to support different variants/versions of the base commercial jar. This we expect to do with a single bundle with the interface and a number of plug-ins with implementations for the different variants/versions (where the implementations "iron out" and/or stub the small differences in the variants/versions). I cannot really see how this will work with the extraClasspathElements method as we want to refer to different versions of the base jar depending on which version a specific developer have installed. (We also want to execute a number of test bundles for all our implementation bundles, but that is a different story...)
*** Bug 550833 has been marked as a duplicate of this bug. ***
