I just downloaded Netty for a personal client-server-project from here:
http://netty.io/downloads/netty-3.3.0.Final-dist.tar.bz2
On the download page http://netty.io/downloads/ it says there are "no mandatory external dependencies". You only need a JDK 1.5 or higher. So I just set up a java project in eclipse IDE using my 1.6 JDK and got multiple errors saying "import cannot be resolved".
Examples:
org.jboss.logging, com.google, org.osgi, javax.servlet
That tells me that there are actually some external libraries needed. Or am I doing anything wrong?
Can anyone tell me where to find all these libraries since I could not find any clues on the Netty pages where to get them (I know that javax.servlet is part of Tomcat and JBoss AS distribution, but why do they then say that no external libraries are needed).
Are you trying to build netty from source? There's a pom.xml file in the root, implying that netty can be built by maven. You'll find all those dependencies in the pom file. "No mandatory external dependencies" means that you need no jar other than the netty jar to run your application. External dependecies is probably needed for some of the examples, definitively for testing and perhaps for some special, but optional, run time features.
The dependencies are only used for building and are marked as optional. The dependencies are only needed if you want for example use slf4j for logging in netty. Beside this netty can be used within your project without pulling in any third-party dependencies.
Related
So first off, a little background.
I am working on converting an Eclipse Java Web Project to Gradle. We use the Vaadin framework and currently manage the project with Ant/Maven/Ivy. We have another project that contains common code that the web project depends on. In both projects our library files, JARs, are simply included in the source and committed to our VCS. With the switch to Gradle we will be using the preferred method of pulling our dependencies from a repository; mainly Maven Central.
I have completed creating the Gradle build scripts that correspond to our current Ant build scripts. I have one Gradle build script for each project, as well as one at the root for configuration injection along with the settings file. I am using the java and eclipse plugins for both projects and additionally the war and vaadin plugins for the web project.
Now to the problem. When I use Gradle to construct the WAR it works perfectly and the WEB-INF/lib directory contains only the JARs that I would expect, based on the dependency configuration. However, when I use Tomcat inside Eclipse to publish the project I end up with a bunch of additional JARs in the WEB-INF/lib directory. Most of the JARs are harmless and just unnecessary, which is why I have excluded them from the WAR, but there are a couple that are actually problematic because Tomcat already has them. In one case it just ignores the JAR and I get the usual message of:
[Tomcat] validateJarFile(*) - jar not loaded.
In the other case I actually receive exceptions in the console, which is troubling even if the application appears to work correctly. I also noticed that all the dependencies associated with the testCompile configuration are also being published, which really doesn't seem right.
The exact offending JARs are tomcat-jdbc and servlet-api-2.5. The tomcat-jdbc JAR is required for compiling our common code. The servlet-api-2.5 JAR is actually just a transitive dependency of vaadin-client-compiler. I have removed the dependency for the vaadin-client-compiler in our web project, because it doesn't appear to be necessary, but it looks like it is still being pulled in by a configuration in the vaadin plugin for Gradle. However, in both cases I am using the providedCompile configuration of the war plugin to exclude them form the WAR.
So my question is, how do I keep Tomcat/Eclipse from publishing these JARs? How do Gradle and Tomcat/Eclipse communicate, or do they at all? From what I can gather it seems that Gradle and Tomcat/Eclipse only communicate indirectly via the .classpath, that the eclipse plugin for Gradle modifies. Also, I have tried the eclipse-wtp plugin for Gradle. It did not seem to resolve the issue because the problematic JARs were still being copied. I am actually not even sure whether I need to use this plugin or if I can just simply use the eclipse plugin.
I should also add that I did install the Gradle Integration for Eclipse "plugin" via the Eclipse Marketplace. With that I used the Configure -> Convert to Gradle Project option that it adds as well as the Gradle -> Refresh Dependencies functionality that it provides. Other than that, I found it to be a little buggy so I've mostly been running Gradle via the command line.
Below is the output of running gradle -v on my machine:
------------------------------------------------------------
Gradle 1.10
------------------------------------------------------------
Build time: 2013-12-17 09:28:15 UTC
Build number: none
Revision: 36ced393628875ff15575fa03d16c1349ffe8bb6
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.8.0_05 (Oracle Corporation 25.5-b02)
OS: Mac OS X 10.9.3 x86_64
Please let me know if additional clarification is required. I assume I must be doing something wrong or missing some configuration because surely my scenario is quite common. Many developers use Tomcat inside Eclipse to test web applications locally and with the popularity of Gradle I would be surprised if someone hasn't run into this before. It would seem the main difference with our switch to Gradle, as far as Tomcat/Eclipse are concerned, is that our dependencies are now being loaded from a repository instead of being linked directly in the source.
Any help is greatly appreciated.
However, when I use Tomcat inside Eclipse to publish the project I end up with a bunch of additional JARs in the WEB-INF/lib directory. Most of the JARs are harmless and just unnecessary, which is why I have excluded them from the WAR, but there are a couple that are actually problematic because Tomcat already has them.
This is a known problem with the gradle eclipse tooling. The problem is that it doesn't understand about dependencies with 'provided' scope. See this issue for some details:
https://issuetracker.springsource.com/browse/STS-2380
There is a workaround for this problem. Some common dependencies that 'cause problems' can be globally excluded via a list of regexps you specify in the preferences. Open menu "Window >> Preferences >> Gradle >> WTP". That's where you can add regexps that will be used to exclude jars from the 'deployment assembly'.
I know this question was asked a lot of times, since I searched for hours for a solution, but it was never answered (or at least not for my situation).
I am using Wildfly 8.0 (ex JBoss), so I understand that I do not need to add jstl jars nor JSF jars since the implementation is already shipped with JBoss.
Now even when telling eclipse to use the Wildfly runtime libraries, I get the above error. I checked and the jboss-jstl-api_1.2_spec-1.0.4.Final.jar is part of the library
How can I get through this? I tried putting downloading jstl jars (from https://jstl.java.net/) and putting them in the lib directory but it is not working.
Copying the jars into "lib" works perfectly when I use Tomcat which doesn't have its jstl implementation. But not with Wildfly (maybe because eclipse ignores the jars I put in the lib directory since Wildfly has its own jars? But then why do I get the error in the first place? I am confused).
Thanks to anyone who could help me with this.
Edit: I forgot to precise that even with these errors on all my JSPs, the project builds and works perfectly on the server.
These errors are eclipse specific, it does not recognize the taglibs and displays annoying error messages at taglib declarations and warnings when using these (unknown to eclipse) tags. Plus, I can't use code completion.
Edit: I bypassed the problem, for the moment, by adding standalone myfaces and jstl libraries to the build path. I would like though that eclipse uses the jars available on server side. (For JPA for example I did not need to add the hibernate library to the build path, I simply told eclipse that the JPA implementation si available on server runtime and it worked fine with code completion and everything).
Alright, to not have to add any additional libraries (that are not needed by the server) here's what I had to do in addition to adding the Wildfly runtime library to the project:
Go to Project/Properties/Project Facets/Java Server Faces and chose Library Provided by Target Runtime in the library type (instead of a User Library).
I'm truly disappointed JSF support in eclipse. I'm encountering such caveats all the time.
I'm using JBoss 7.1.1 and even adding JBoss as the Target Runtime of the project didn't help.
The only solution that worked for me, was to define new JSF library inside Eclipse: Window Preferences -> Java -> Build Path -> User Libraries -> click New (pointing to the jsf-impl.jar and jsf-api.jar). And then adding such library to the build path of the project.
It solved all annoying eclipse errors can not find tag library. So it is pretty similar to the #Riccatti first solution.
Btw: answer which I found on the eclipse forum says that this error is usually caused by not existing JSF tag libraries (that are present in jsf-impl.jar) on the classpath.
I am getting the following error:
java.lang.NoSuchMethodError: org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(Ljavax/servlet/http/HttpServletRequest;)Lorg/apache/commons/fileupload/FileItemIterator
though I have added commons-io 1.2 jar and commons-Fileupload 1.2.1 jar in my buildpath.
Please help me out.
There is probably an incompatibility between the file-upload version you're using and the servlet.jar you have on your server.
I can't tell you if it is between the "commons" jars or between the server jars and "commons".
Anyway, I suggest you use a maven (or gradle even better) project at least to get your jars in a consistent way. If your project is not ready, you can still pack your application as a war and get the correct jars from the zipped output fil of your maven compiling.
I've been beating my head against a wall for about 6 months now and have not found a concise way of understanding the mechanism for developing an eclipse plugin with third-party resources.
We are attempting to develop an Eclipse ODA to ride on top of in-house Spring-based code that accesses a REST based info set.
In broad strokes - this is what I feel that we need to be able to do:
Augment our maven artifacts with Eclipse bundle information using tycho or a the felix bundle plugin.
Set up a plugin project through Eclipse for the ODA Implementation & UI.
Have Tycho generate the poms etc for the plugin.
Now here's where I get muddy. I understand that there are two approaches
Manifest-First - which is the standard mechanism for defining a plugin's dependencies
POM-First - which provides dependencies via Maven's resolution mechanisms.
I'm not entirely sure where to begin trying to start doing this as I've never worked on developing an eclipse plugin.
One of the other questions I have is, how does a developer of an eclipse plugin (maven aside) leverage already existing third-party code (i.e. Apache HttpClient 4.x)? Do they have to download the jars, dump them into a directory within the project, add to classpath, then go from there or is there a "repository" mechanism similar to what is used with ivy, maven, gradle?
Thanks in advance and I apologize if I was rambling a bit with that.
Disclaimer: Your question is very broad, so it is impossible to answer it completely. Still, I can give you some hints so that you know what to search for.
In the Eclipse universe, the primary source for libraries (in the sense of binary dependencies) are p2 repositories. However, since p2 repositories are rarely used outside of the Eclipse context, you won't e.g. find a p2 repository on the Apache HTTP Client project's download page.
To account for this problem, there is the Eclipse Orbit Project which provides libraries used by Eclipse projects in p2 repositories.
If you can't find the library or library version in the Eclipse Orbit, you may also be able to use the libraries from Maven repositories. This is for example supported by Tycho via the pomDependencies=consider mechanism.
Note however that Eclipse plug-ins can only depend on libraries which are OSGi bundles. So if the library in the Maven repository is not yet an OSGi bundle, you need to convert it to an OSGi bundle first, e.g. with the maven-bundle-plugin and the Embed-Dependency mechanism.
The best way for an Eclipse plugin to consume libraries is as OSGi bundles. You just install those bundles into your target platform and reference them in the same way as eclipse.org plugins. Some of the library providers already offer their libraries as OSGi bundles. Absent that, you can typically turn a plain library jar into an OSGi bundle simply by adding a few manifest entries.
Depending on the build system you use and whether the libraries you need are available as OSGi bundles packaged into an online p2 repository, you can reference the URL and rely on your build to download and install the bundle.
If question of choosing a build system for Eclipse plugins with dependencies is still relevant:
Today I released new gradle plugin: Wuff version 0.0.1, which (I think) completely solves the problem. It allows to build Eclipse bundles and applications as they would be "normal" Gradle projects. All OSGi woodoo is auto-generated (although customizable). All dependencies are usual maven dependencies - regardless of whether dependency is OSGi or "normal" library.
Sources and doc: https://github.com/akhikhl/wuff
I've created a new Vaadin (6.6.5) project in eclipse and I've tried to deploy it on JBoss 7.0 but it gives me a GWT ClassNotFoundException
Caused by: java.lang.ClassNotFoundException: com.google.gwt.user.client.ui.HasWidgets from [Module "deployment.test.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
... 64 more
Do I need to do something extra to deploy the gwt libraries?
Seems that some GWT classes in gwt-user.jar required for compiling the Vaadin client side widgetset are loaded by the JBoss7 unnecessarily.
vaadin.jar contains references to gwt-user.jar but it's not required during runtime, only during widgetset compilation time. Still JBoss wants to load these classes causing the problem.
There's a bug report in JBoss for this: http://community.jboss.org/thread/169575?tstart=0
As mentioned there, workaround is to include gwt-user.jar to the deployment package in WEB-INF/lib folder with the vaadin.jar, seems to work.
Vaadin Eclipse plugin creates library dependencies to gwt jar files and generally Eclipse should take care of the runtime classpath when deploying.
As the package name com.google.gwt.user.client suggest this should be in gwt-user.jar.
The gwt-dev.jar should only be needed when compiling client-side code with GWT.
Are you using add-ons? Add-ons (and their dependencies) should be always added to WEB-INF/lib to make the server-side classes available to the application and client-side code available to the GWT compiler.
On possible cause of the problem is (unnecessary) dependency to client-side class which is not available in the server at runtime. So, you might also check your code for unnecessary server-side dependencies to client-side GWT classes (like HasWidgets).
Check your code to ensure that you do not accidentally access this com.google.gwt.** class from your code. As said above, there is no need to deploy gwt libraries in the server.
Vaadin has now published an add-on to fix this, see https://vaadin.com/directory#!addon/vaadin-application-server-class-loader-workaround