'The class folder is not associated to any output library entry

My Eclipse plugin project which holds libraries used by other OSGi plugins gives me the following warning:

The class folder 'lib/' is not associated to any output library entry.

What does it mean? Can I safely ignore it?

The whole feature consisting from 20 plugins works well, but I do not like to have any warnings in my code.

My build.properties file is:

source.. = src/
output.. = bin/
bin.includes = META-INF/,\
           bin/,\
           lib/,\
           .

The search on google gave me this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=297483, but I'm still not sure how to fix this warning.

javaeclipseosgi


Solution 1:[1]

I found this hint to be helpfull (first google hit, as of 03-SEP-2013) http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01822.html

I removed META-INF from my bundle build path, cleaned (rebuilt) the project and the warning disappeared.

Solution 2:[2]

About the build.properties:

META-INF/ should be included in the bin.includes because actually this folder includes all the information associated to the classpath and runtime information. If not, another warning appears.

Icons must be added as well in the bin.includes.

Actually, we should try to avoid the addition of icons in the runtime information:

Statically declared plug-in icons are not meant to be in the runtime JAR >because Eclipse wants to load plug-ins lazily. In other words, during >loading of the platform, the platform loader reads only the plugin.xml >file and will use the icons that are declared there.

Taken from: https://wiki.eclipse.org/FAQ_Can_I_add_icons_declared_by_my_plugin.xml_in_the_runtime_JAR%3F

Example of one of my plugins:

Figure 1. Adding information in the bin.includes property

The reason is simple. Think about we want to deploy our plugin somewhere else. Then, we need to maintain a track about all the information that needs our plugin to be executed.

About the MANIFEST.MF:

There is another trick to organize the information that appears in the MANIFEST.MF besides the information that appears in the build.properties:

PDE provides an Organize Manifests wizard to help ensure that the >information in your Manifest is up to date. The wizard is available >through the Plug-in Tools menu after right clicking on a plug-in project's MANIFEST.MF or plugin.xml files.

Taken from: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpde_actions%2Forganize_manifests.htm

Example of one of my plugins:

Figure 2. Organizing MANIFEST.MF

Solution 3:[3]

I think your issue is that in your MANIFEST.MF the section Bundle-ClassPath does not include a listing of the libraries. This means OSGi will not know if these classes are meant to be on the internal classpath. You will have to provide that information.

  • If you export everything in lib, every single one has to be listed in the MANIFEST.MF and the wildcard lib/ is fine for the PDE builder.

  • If you only want some in lib/ then you need to list those only, and the builder will either need an explicit list, or an exclude clause for the ones that you do not want.

  • If you are just using the libraries internally, but do not want to export them, then the settings for the exported packages are used.

I am unsure what to do in the case where you are packing up a jar file but actually do not want it on the classpath. I am guessing that a source.exclude with the name of the library might help. This is a really unusual corner case.

Bundle-ClassPath: lib/amf-aml_2.12-4.1.19.jar,
 lib/amf-core_2.12-4.1.20.jar,
 lib/amf-validation_2.12-4.0.3.jar,
 lib/amf-webapi_2.12-4.0.3.jar,
 lib/antlr4-runtime-4.5.3.jar,
 lib/collection-0.7.jar,
 lib/commons-beanutils-1.9.3.jar,
 lib/commons-cli-1.4.jar,
 lib/commons-codec-1.11.jar,
 lib/commons-collections-3.2.2.jar,
 lib/commons-compress-1.19.jar,
 lib/commons-csv-1.5.jar,
 lib/commons-digester-1.8.1.jar,
 lib/commons-io-2.6.jar,
 lib/commons-lang3-3.4.jar,
 lib/commons-logging-1.2.jar,
 lib/commons-validator-1.6.jar,
 lib/handy-uri-templates-2.1.6.jar,
 lib/httpclient-4.5.5.jar,
 lib/httpclient-cache-4.5.5.jar,
 lib/httpcore-4.4.9.jar,
 lib/jackson-annotations-2.9.0.jar,
 lib/jackson-core-2.9.8.jar,
 lib/jackson-databind-2.9.8.jar,
 lib/jcl-over-slf4j-1.7.26.jar,
 lib/jena-arq-3.11.0.jar,
 lib/jena-base-3.11.0.jar,
 lib/jena-core-3.11.0.jar,
 lib/jena-iri-3.11.0.jar,
 lib/jena-shaded-guava-3.11.0.jar,
 lib/joda-time-2.9.4.jar,
 lib/json-20180130.jar,
 lib/json4s-ast_2.12-3.5.4.jar,
 lib/json4s-core_2.12-3.5.4.jar,
 lib/json4s-native_2.12-3.5.4.jar,
 lib/json4s-scalap_2.12-3.5.4.jar,
 lib/jsonld-java-0.12.3.jar,
 lib/libthrift-0.12.0.jar,
 lib/org.everit.json.schema-1.9.2.jar,
 lib/paranamer-2.8.jar,
 lib/re2j-1.1.jar,
 lib/scala-common_2.12-0.5.64.jar,
 lib/scalactic_2.12-3.0.5.jar,
 lib/scala-java8-compat_2.12-0.8.0.jar,
 lib/scalajs-stubs_2.12-0.6.29.jar,
 lib/scala-library-2.12.6.jar,
 lib/scala-reflect-2.12.8.jar,
 lib/scalatest_2.12-3.0.5.jar,
 lib/scala-xml_2.12-1.0.6.jar,
 lib/scopt_2.12-3.7.0.jar,
 lib/shacl-1.3.0.jar,
 lib/slf4j-api-1.7.26.jar,
 lib/slf4j-simple-1.7.12.jar,
 lib/syaml_2.12-0.7.270.jar,
 lib/webapi-parser-0.5.0.jar,
 lib/webapi-parser-0.5.0-javadoc.jar,
 lib/webapi-parser-0.5.0-sources.jar,
 .

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Fred Klein
Solution 2 Community
Solution 3 Jörn Guy Süß

Related Questions