Does anyone know any sane reason for such bundling decision? Google engineers act wisely in most cases, so this kinda surprized me.
This would cause collisions with other versions of servlet API pulled via Maven dependencies:
webapp classpath will likely contain
version which is bundled with GWT;
container may refuse to load the GWT
jar as it contains the javax.servlet
package;
in most cases this will
likely deviate classpaths across your
IDE's debugger and the really
executing VM.
Link to the jar in question (just so you see the same thing after unzipping as I do, if you don't believe that GWT contains servlet API classes in the same jar):
http://repo1.maven.org/maven2/com/google/gwt/gwt-user/1.7.0/gwt-user-1.7.0.jar
You shouldn't be including gwt-dev.jar or gwt-user.jar in your war file. You only need gwt-servlet.jar in your war, and that too only if you are using RPC. If you notice, gwt-servlet.jar (ironically) does not contain any of the servlet classes.
gwt-dev.jar contains the compilers and linkers. Your code will never need this to compile.
gwt-user.jar contains the gwt framework that ultimately gets translated to javascript. You only need this during development mode.
gwt-servlet.jar contains the server side code that is needed if you use RPC framework. This is the only jar that should be present in your war file.
The reason the classes are in the package is to provide a full working solution for users who only use the gwt-user file in development. Without it GWT RPC wouldn't compile. This is/was the general view of the GWT team as can be found in this lively discussion on the GWT issue tracker: http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
However, GWT 1.7 also contains the javax source files, which can cause additional problems. For example for maven and probably also for the points you mention. This was addressed in the GWT issue and in later version of GWT the javax source files have been removed from the gwt-user jar file.
For deployment you should use the gwt-servlet jar, which doesn't contain the javax classes or any other third party libraries. In the past several it could happen GWT files designed for client side use also used on the server side were missing from the gwt-servlet jar file. Losts of these issues have been addressed and classes were added to the servlet jar file. If you still find a GWT class you need is missing from the gwt-servlet you should file an issue report. In your case, assuming you're using 1.7, it might mean to upgrade to a newer version of GWT.
Related
I am learning AOP with Spring framework and I want to set the javadoc for AOP in eclipse. So what I did I downloaded aspectj-1.8.10.jar from eclipse web site https://eclipse.org/aspectj/downloads.php#install then I installed that jar and got 4 new jar files: aspectjrt.jar, aspectjtools.jar, aspectjweaver.jar, org.aspectj.matcher.jar which I added to my class path in eclipse. Now what I want is to add source files for these jars so, for example, when I hover over #Aspect I want to be able to see what this annotation represents. Unfortunately I can not find the source files for these jars, on the eclipse website mentioned above there is a file aspectj-1.8.10-src.jar but I'm not sure what to do with it, I tried to attach this file directly in the build path for each of the jars mentioned above but it didn't do the trick. Also I thought that maybe I had to install aspectj-1.8.10-src.jar the way I installed aspectj-1.8.10.jar so I would get 4 source files, but I'm not sure how (if possible) to install it, when I double click aspectj-1.8.10-src.jar, installation does not get triggered.
So can you please help me out to add javadoc for AspectJ 1.8.10 in Eclipse?
Select the library in your Eclipse project explorer window, click right button, select properties, select javasource attachment or javadoc location and enter the path to the source or javadoc file.
But I would suggest to use maven to maintain the dependencies of your project. It makes getting javadoc much easier, because libraries, source code and javadoc are fetch from a central repository. You just add the library you need in your project configuration (pom.xml file) and the other files are fetched for you.
You do not need all those libraries. Please first learn which one serves which purpose. E.g. aspectjrt is the runtime. When using Spring AOP you actually do not really use AspectJ, only a subset of its syntax. Thus, the runtime is needed for identifying some of the annotation classes. However, aspectjweaver is only needed if you want to use full AspectJ in a load-time weaving (LTW) scenario, with or without Spring. The weaver lib is a superset of the runtime, so you only need one of them. Last, but not least, aspectjtools again is a superset of the weaver lib and contains the AspectJ compiler (among other tools). This is only needed for compile-time weaving as part of your toolchain.
I do not think that source code and Javadoc will help you much in learning AspectJ. I suggest you read the Spring manual's AOP chapter describing both proxy-based Spring AOP and full AspectJ integration via LTW. If you want to learn AspectJ basics and maybe just use AspectJ without Spring (which is what I do), read the AspectJ documentation.
If you are still not convinced and want to add source and JavaDoc to your Eclipse project, why don't you follow jaysee's advice and use Maven? Then you get all the source/javadoc libs for free. But anyway, you can also load those JARs directly from Maven Central, e.g. the source and javadoc for AspectJ runtime 1.8.10. Good luck! But I assume you will be disappointed because the AspectJ JavaDoc is really bad for learning purposes and not suited to understanding how to actually use AspectJ.
Let me explain first what I mean by necessary libs. I'm creating my first project using the Google App Engine for Java with the official Google Maven Plugin, the main problem that have Maven as a packaging solution (or maybe the Java development as a whole) is that if the dependency tree grows too much, the release process may be harder.
Let me illustrate it with an example. Let's start with the Jackson JSON library (it's a good starting point since it has no parent dependencies), now someone makes a JSON-RPC library and uses Jackson for the JSON serialization/deserialization. Imagine that this library not just provides a JSON-RPC client implementation, but also a server, that means that the POM of this lib will add some Java EE related libraries such us Jetty as dependencies.
Probably the guidelines say that the application should be either divided into modules or mark the server related deps as optional, but you know that many people don't follow the standards.
Now someone need a JSON-RPC client for his/her project, call it Project X, and uses the lib mentioned above, at compile time there will be no problems, Maven will successfully download the required libs and the application will compile fine, but the problem comes when that person wants to release the application. Which dependencies should be distributed along with the package (in a lib folder for example)?
Actually that's something that happened to me, I wasn't too much familiar with Maven so I used the Eclipse Runnable Jar Exporter, that produced jar file with all the maven libs copied to a lb subfolder, so the workaround that I did then was to just delete the libs that looked unnecessary and then tested if the application was still working. If there are classes that are not executed, as far as I know they are not loaded by the ClassLoader so they could be omitted and are unnecessary
I can't use the same trick now since the scenario is much more complex, we are talking of a Java Web Application, not a desktop application like the other one, and the library that I want to include is a Liquid Template Engine, which uses the ANTLR framework to generate the parsers plus Jackson for the JSON handler and Jsoup for HTML parsing.
Which libs should be packaged inside the WEB-INF/lib folder? I'm sure that I will need Jackson for JSON parsing but I'm not so sure about Jsoup, and what about ANTLR, it is necessary or is used just at compile time?
Update: I think I need to re-formulate my question, actually what I want is to determine which dependencies are really necessary for the application, and package those into the app WEB-INF/lib folder
Solution: It seems that the POM file that is packaged in the WAR file of the web app is used once the app is in the Google App Engine production environment to retrieve the necessary dependencies, and probably the appengine:update goal only packages those dependencies that can't be retrieved from the maven central repo, so there is no need to worry about that.
Thanks to David to point this.
You should check Maven's dependency scopes. Here's an extract from the documentation :
There are 6 scopes available:
compile This is the default scope, used if none is specified. Compile
dependencies are available in all classpaths of a project.
Furthermore, those dependencies are propagated to dependent projects.
provided This is much like compile, but indicates you expect the JDK
or a container to provide the dependency at runtime. For example, when
building a web application for the Java Enterprise Edition, you would
set the dependency on the Servlet API and related Java EE APIs to
scope provided because the web container provides those classes. This
scope is only available on the compilation and test classpath, and is
not transitive.
runtime This scope indicates that the dependency is
not required for compilation, but is for execution. It is in the
runtime and test classpaths, but not the compile classpath.
test This
scope indicates that the dependency is not required for normal use of
the application, and is only available for the test compilation and
execution phases.
system This scope is similar to provided except that
you have to provide the JAR which contains it explicitly. The artifact
is always available and is not looked up in a repository.
import (only
available in Maven 2.0.9 or later) This scope is only used on a
dependency of type pom in the section. It
indicates that the specified POM should be replaced with the
dependencies in that POM's section. Since they
are replaced, dependencies with a scope of import do not actually
participate in limiting the transitivity of a dependency.
So in a Maven project, the developer indicates which dependencies should be bundled in the application and which should not.
Basically there are two cases here :
If you're building a web application (WAR or EAR format) and want to deploy it, or if you're building an actual runnable jar, then you will need to bundle it with all the dependencies with scope compile and runtime.
If you're building a library, then you do not package any dependency with your library. Instead you include the pom.xml so that others know what dependency your library requires. For Maven to know how to find the associated POM for a given jar, the best and most common solution is to deploy the library to a Maven repository. Repos have a directory structure that helps Maven find the right version of a library, and find the POM that indicates the required dependencies.
Depending on wether your library is open source or not, you will be able to be hosted for free by some repositories such as Sonatype (complete list here). But you can also setup your own repository either by installing a dedicated software such as Nexus or by configuring a Github project as the repo, as is explained on this blog.
You can exclude any transitive dependency.
For your case, to remove jetty from this json-rpc-library, you need:
<dependency>
<groupId>com.somecomp</groupId>
<artifactId>jsonrpclib</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
</exclusion>
</exclusions>
</dependency>
See docs: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
I'm trying to troubleshoot a GWT-based app I'm writing in Eclipse. It currently uses Spring Framework 3.1.1 and Hibernate 4.1.6 on the back-end side. I'm currently having troubles with the dreaded "javax.validation.ValidationException: Unable to find a default provider" that seems to plague a lot of folks but is caused by different problems. I've tried the various solutions of using different versions of the JSR 303 implementation (e.g. diff. versions of Hibernate Validator) but it doesn't seem to make a difference.
And after debugging, I'm seeing why. Once execution gets to javax.validation.Validation.getValidationProviders():317 (in validation-api-1.0.0.GA), the app (running on an Eclipse internal Jetty server) attempts to read the META-INF/services/javax.validation.spi.ValidationProvider resource from the classpath and comes back empty. I am absolutely certain that the different validator implementations I've put (e.g. hibernate-validator-4.3.0.Final.jar) have that resource and it does contain a value (e.g. org.hibernate.validator.HibernateValidator), but is not appearing to the classloader in question. The way I've included the JAR in the classpath is by adding it to the project's Build Path which seems to add it to the Jetty runtime when I execute the applications.
My question is: Is there a way to view the classpath in Eclipse debug mode visible to a certain classloader? Secondly, does anyone know why the Hibernate Validator's resource is not first and foremost in the classloader that Validation is using?
The webapp classpath is composed by the directory WEB-INF/classes and by all the jars in WEB-INF/lib. If you want a jar to be available at runtime, you must NOT add it to the build path, but to WEB-INF/lib.
Dropping a jar in WebContent/WEB-INF/lib in Eclipse will make it automatically part of the buid path of your webapp, and available at runtime.
I have an Eclipse RAP product, I like to export as a web app for use inside Tomcat. For this I use the warproduct exporter in Eclipse, which until now have worked fine.
I have a problem with compilation of one of the OSGi bundles in the product as this refers to a set of external jars using a variable substitution. This is shown in the following fragment from a MANIFEST.MF:
Bundle-Name: ...
Bundle-SymbolicName: ...
Bundle-ClassPath2: external:/A/test1/jakarta-tomcat/shared/lib/a_base.jar
Bundle-ClassPath: external:$A_HOME$/jakarta-tomcat/shared/lib/a_base.jar
If I use the first classpath instead and have the correct /A/test1/jakarta-tomcat/shared/lib/a_base.jar in place, then everything is fine during the compilation... And I can even manually change the MANIFEST.MF afterwards to the correct version with the substitution.
But, I would really like to avoid this extra step, if at all possible!
I think the question is how to pass in a proper value for A_HOME during the compilation?
(Why do this? Above, I just shown a single jar file, but we have a larger number of jar files we want to share between our older Tomcat applications and the newer RAP based application. We know, there are other ways of sharing jars in this situation - e.g. via an OSGi framework extender or the extendedFrameworkExports initialization parameter in web.xml - but we need the chosen method as we use EMF and therefore cannot share the EMF meta data between Tomcat and Eclipse... And thus not the class objects...)
this feature is currently not support within the WAR Products Tooling. I recommend to open a bug against Eclipse Libra and to define the feature request their. Anyway, we have created an example how to build a RAP application with tycho which is pretty easy, maybe you want to take a look: https://github.com/eclipsesource/rap-mobile-demos
Cheers Holger
How do we add an external .jar package in Google Web Toolkit (GWT)? I have followed the steps
1) added the .jar in classpath
2) added <inherits name='org.scribe.model' /> in my test.gwt.xml
I get this error:
Loading inherited module 'org.scribe.model'
[ERROR] Unable to find 'org/scribe/model.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?
[ERROR] Line 8: Unexpected exception while processing element 'inherits'
However, I have found from many sources that you need the source files to compile the client side gwt. My question is what if one cannot get a source file of the .jar package? What is the workaround?
Thanks in advance.
If it is a GWT module it is packaged with sources. Check the jar Java files should be in it.
There are two ways to use a 3rd party dependency in your GWT application.
It is either a GWT module already which contains a module xml file along with the source files. In this case you just refer to it using inherits.
Or it is some regular 3rd party dependency in this case you need the source code and you also have to play with the package names since GWT requires source code to be under client package. Even you do so since the artifact is not developed GWT in mind, it might most likely contain code that is not allowed by GWT, e.g. you cannot use Threads in GWT.
There is no workaround. You need source files.. At least you can decompile class files..
My suggestion would be to handle intense logic on server side (within server package)
On the server side , you can use classes that are not supported by GWT front-end (classes in client package).
E.g
When I tried to use BufferedReader in client, I got exceptions, I then moved it to server package and retuned the result. The same was for RE which didn't work in client code too.
Keep your client code as simple as possible.
Hope this helps.
Cheers
PB