Develop Reference

How to fix the "the-default-package-is-not-permitted-by-the-import-package-syntax" error while using geojson library?

I was upgrading to new library of geojson from version 14.2 to 20.2. And I was keep of getting below maven build error which is failing at the bundle processing with the message "the-default-package . -is-not-permitted-by-the-import-package-syntax".
I expect the maven build with bundle processing to be successful but the actual output is "the-default-package-is-not-permitted-by-the-import-package-syntax" error.

While upgrading the geotools library from old version 14.2 to new version 20.2, there were lot of changes has been made.
GeoTools Upgrade
This was one of the link that would help everyone to do it very easily. But with the upgradation of geotools, we also update the gt-geojson library too. This library contains the class "Skunkwork" without any package name which result in above error during bundle processing of maven build. To avoid this error,i have to remove this class. And it works fine.
Before Fix
POM Configuration:
<dependency>
<groupId>org.geotools</groupId>
<artifactId>gt-geojson</artifactId>
<version>20.2</version>
</dependency>
After Fix
POM Configuration:
<dependency>
<groupId>org.geotools</groupId>
<artifactId>gt-geojson</artifactId>
<version>20.2-fixed</version>
</dependency>
Note: This jar needs to be manually installed to your local repository. And as well as you need to install the fixed jar to remote artifactory if used by your code base such as Nexus, JFrog etc.

Upgrading gwt from 2.1.1 to 2.8.0: ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype

After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?

I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)

I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.

I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)

I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.

org.apache.sling.api.resource,version=[2.3,3) -- Cannot be resolved

Hi I am not able to access content of my project, I have uploaded all the packages which are required to access content from CQ. Only thing I can see is
org.apache.sling.api.resource,version=[2.3,3) -- Cannot be resolved
Can this be the reason for exception and if yes please let me know how to resolve it.
CQ version 5.6

The error message means that the OSGi framework is unable to supply a version >= 2.3 and < 3 of the org.apache.sling.api.resource Java package for a bundle B that wants to import it.
As a result, bundle B cannot be activated, and parts of your system won't work.
Looking at the webconsole (under /system/console by default in Sling and CQ) you can see that this package is provided by the org.apache.sling.api bundle, so either you have an old version of that bundle in your system, or you have installed incompatible bundles that require a newer version of that package.

You can add the missing package by explicilty importring it. Accecess the pom.xml file in the core folder of your project core/pom.xml and list the dependency under Import-Package
<configuration>
<bnd><![CDATA[
Import-Package:
javax.annotation;version=0.0.0,
org.apache.sling.api.servlets;version="[2.3,3)",*
]]></bnd>
</configuration>

Check version of org.apache.sling.api.resource in package-info.class file in org.apache.sling.api.resource package in uber-jar.
You might have version between 2.3 and 3. Try installing lower version uber-jar that has package version <2.3

javax.servlet.http package in Apache Karaf 2.3.0

I've installed Apache Karaf 2.3.0. One of my bundles that needs to be installed in it uses classes from javax.servlet.http package. When I try to install the bundle it gives me the error message:
karaf#root> ERROR: Bundle com.groupgti.esb.purge [207] Error starting mvn:com.groupgti.esb/esb.purge/1.0.0 (org.osgi.framework.BundleException: Unresolved constraint in b
undle com.groupgti.esb.purge [207]: Unable to resolve 207.0: missing requirement [207.0] osgi.wiring.package; (osgi.wiring.package=com.groupgti.esb.cxf.interceptors) [cau
sed by: Unable to resolve 212.0: missing requirement [212.0] osgi.wiring.package; (&(osgi.wiring.package=javax.servlet.http)(version>=2.6.0)(!(version>=3.0.0)))])
org.osgi.framework.BundleException: Unresolved constraint in bundle com.groupgti.esb.purge [207]: Unable to resolve 207.0: missing requirement [207.0] osgi.wiring.package
; (osgi.wiring.package=com.groupgti.esb.cxf.interceptors) [caused by: Unable to resolve 212.0: missing requirement [212.0] osgi.wiring.package; (&(osgi.wiring.package=jav
ax.servlet.http)(version>=2.6.0)(!(version>=3.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
javax.servlet.http package is exported from: mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2 system bundle. The problem is that its version is 2.5 but and my bundle requires at least 2.6.0. Is there a workaround or something to update the geronimo-servlet to the higher version that would be compatible with my bundle? (This is the system bundle).
Additional information:
CXF Version: 2.7.0
Camel Version 2.10.2
EDIT:
I forgot to mention the important thing. I also updated CXF to 2.7.0 version and CXF is the one which is introducing the dependency of Servlet 3.0. This is the graph from dependency tree:
Maybe will give you some idea on how get around this? The only thing that I could think of is to go back to CXF 2.6.x.

If your bundle really needs something newer than 2.5, you may have problems running it on Karaf 2.3.0. Karaf 2.3 uses Jetty 7.6.7 which is based on Servlet 2.5. It doesn't support any of the newer Servlet 3 based API's and such. You can upgrade the servlet-api bundle and it MAY work, but if your bundle/app uses any of the Servlet 3 functionality, it will likely not work.
Karaf 3 will be upgrading to Jetty 8.1 which does support the Servlet 3 stuff. Any help testing that and getting that out would be greatly appreciated by the Karaf community. :-)

Do you really need to use geronimo servlet spec ? Try replacing it with this:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>

Package uses conflict: Import-Package: de.foo.bar; version="0.0.0"

I try to install a bundle in an OSGi environment (FUSE ESB) but do not manage to get it resolved. The error message is:
The bundle could not be resolved. Reason: Package uses conflict: Import-Package: de.foo.bar; version="0.0.0"
My bundle imports the package de.foo.bar.
The bundle which exports the package de.foo.bar does this with a 'uses' directive.
Export-Package = de.foo.bar;uses:="{other packages}";version="2.4.0"
As I understood I have to ensure that my bundle must import all other packages mentioned in the 'uses' directive of the de.foo.bar package (in the right version).
I checked this and also tried several version changes (0.0.0 and the real version numbers) but can not get it to work.
So, what does the error message realy means (maybe I understood it wrong)? What do I have to check?
Thanks for any help
Klaus
System Information:
FUSE ESB 4.2.0 (based on servicemix)
using maven-bundle-plugin 2.1.0 to generate OSGi MANIFEST header

I finally found what was wrong.
My bundle is a Spring Dynamic Module bundle and I did a mistake in the spring bean configuration (use a 'ref' instead a 'value' in a constructor-arg). Normally spring configuration errors are reported as such - I do not know why the current error resulted in the misleading message.
EDIT:
The faulty Spring configuration does not cause the uses conflict. It finally was the import of the package org.apache.log4j which is exported by different bundles (in my FUSE ESB container) and apparently was different wired to the bundles I tried to install.
Trying to solve my problem I found the article Diagnosing OSGi uses conflicts which I found helpfull to understand the problem.