No source code available for Scribe in GWT - java

I'm getting this error trying to Compile my GWT Project:
No source code is available for type org.scribe.oauth.OAuthService; did you forget to inherit a required module?
I have included the scribe .jar file in my "war/WEB-INF/lib", and imported it. Maybe I have to add it to the app_name.gwt.xml? I have tried to do it, but Scribe does not contains any .gwt.xml file.

In GWT you are restricted to use only some of the java classes since it is not possible to convert all the java classes to javascript. You can find a list of the allowed classes in this link: List of Classes
And it is not possible use classes related to Threads,IO,Network, etc...because of the compatabilty.

I use Scribe with no problems. But it's a server-side library. You should have no references to it in your GWT code.

You have to have the Java source code for Scribe in order for the GWT compiler to compile it (translate it into javascript). If it is available then you can add it to your source tree and and specify that it is "inherited" in the gwt.xml document.
Of course, check with Google's GWT forum for any updates. I know they are working on a better solution to this problem.
I just checked and Google has OAuth available as an extension to GWT. That is your best solution. Look here:
code.google.com/p/gwt-oauth2/

Related

How do you share Java functions without giving others source code?

When programming in C++ we have header files and source files. When our company sells our product (which is just a library of useful functions essentially) we provide the client only our header files and compiled source code (not the actual source code). This way clients buying the code see the function definitions in the header files and can make calls to these functions using the compiled code.
How would a company who is developing in Java go about sharing their library functionality without giving out their code? Since there are no header files in Java is this just done through documentation; i.e, provide the client with an API document showing all the function signatures and also provide a jar file with the compiled classes?
In Java you don't need source code to compile against - the bytecode contains all the metadata you need.
So for example, if I create an interface with some methods in, compile it into a class file, then package that up into a jar file and give you that jar file, you can use that interface and see all it's members etc without having the source code.
Typically you'd also provide documentation to explain the meaning of the methods etc, but they're not required in order to compile against the jar file.
Take for example YWorks YFiles, they offer their proprietary lib but they do some obfuscation on their distribution(using their own obfuscator).
As for guidance how to use their lib, they ship their lib with javadocs, some howto documents and some sample code.

Compile a GWT library into a JavaScript library

I want to know what is the best approach to take to build a GWT library into a JavaScript library. When this GWT library to be compiled into Java script does not have any GWT server side component in it.
Just plain front-end components. Including only things like AJAX calls, etc.
In Java the GWT library is used like this:
TheGWTLibrary api = new TheGWTLibrary();
api.setServer("http://www.somewhere/api");
api.post(stuff, new Callback(){
void success(){
}
void fail(){
}
});
api.get(new Callback(){
void success(){
}
void fail(){
}
});
Such that the GWT library project would be usable in any HTML project without making it a GWT app.
If this is possible where will the dependencies of this GWT library be compiled to? Will it be included in a one single JavaScript (js) file?
[EDIT 2016]
The way to go with new GWT (2.8.0) is using JsInterop, read the documentation API. Note that it's still in 2.8.0-SNAPSHOT but will be released in few weeks. Also, JsInterop in 2.7.0 has been deprecated and removed in 2.8, so don't use it.
[END EDIT]
Apart from writing your JSI method, there are two easy ways to deal with this.
1.- GwtExporter
You might be interested on reading this article I wrote some years ago:
https://code.google.com/p/gwtchismes/wiki/Tutorial_ExportingGwtLibrariesToJavascript_en
It uses gwt-exporter, and you can take a look to a couple of projects using this approach:
JsUpload wich is a port of gwtUpload:
https://code.google.com/p/gwtupload/wiki/JsUpload_Documentation
https://github.com/manolo/gwtupload/tree/master/jsupload
GwtChismes is a very old library useless right now and not maintained anymore, but it is exported as well
https://code.google.com/p/gwtchismes/wiki/JsChismes_Documentation
https://code.google.com/p/gwtchismes/source/browse/#svn%2Ftrunk%2FGWTChismes%2Fsrc%2Fjschismes
I also did some experiments exporting gwtquery to js (jsQuery):
https://code.google.com/p/gwtquery/wiki/JsQuery
Chronoscope was another gwt library using this approach
https://code.google.com/p/gwt-chronoscope/wiki/JavaScriptAPI
2.- JsInterop
If you want to play with new stuff, you might read about JsInterop a beta feature in GWT-2.7 which will be fully functional in GWT-3.0.
It allows you to export java classes to JS. You have to use the -XjsInteropMode JS and some annotations.
There is no so much documentation right now, but there is a document explaining the API, and an interesting presentation.
https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit
http://gokdogan.appspot.com/gwtcreate2013/#1
It sounds like you're looking for something like GWT Exporter. It allows you to export a GWT library as a publicly accessible javascript API.
It looks like you'll still need to compile the GWT library as a web application to use it, but if you don't have any server-side code, it should be as simple as compiling your API, copying the war folder and adding a reference to war/[yourapp].nocache.js.
If that's not what you're looking for, you can check out this question for other options.

How to add external tags file into CEDET in Emacs

I tried to use CEDET to get auto completion in Emacs and that works fine for C/C++. But I cannot find anything about how to use CEDET with Java without the help of JDEE, which is thought out of date and not compatible to CEDET 1.1. I got a tags file using utility found here but I don't know how to integrate that into CEDET system. According to CEDET's website, that's possible. But they don't explain how to do it. Is there someone willing to answer this question?
Here is some sample of the tags file generated by that utility:
java.applet.Applet$AccessibleApplet
protected java.applet.Applet$AccessibleApplet(java.applet.Applet)
public java.applet.Applet$AccessibleApplet.getAccessibleRole() returns javax.accessibility.AccessibleRole
public java.applet.Applet$AccessibleApplet.getAccessibleStateSet() returns javax.accessibility.AccessibleStateSet
It is possible to have CEDET pull in tags from a .jar file. It works by using javap to extract the tags in text form, and then it parses that data.
It isn't very easy to set up since in CEDET, the concept of where to find your library files is part of EDE, the project management system, not the parser and smart completion system. The only Java based project supported in CEDET 1.1 is Android.
The basics is to first enable the javap database by loading it with (require 'semanticdb-javap) in CEDET 1.1, or (require 'semantic/db-javap) in the bzr version of CEDET.
Once you've done that, you can configure it via the cedet-java-classpath-extension. I'm a little fuzzy on the details of what happens next, but folks have reported success on the mailing list.
If you use CEDET from the bzr repository, there is the ede-java-root project, which is similar to the ede-cpp-root project. That project type lets you configure what your library path is. The doc for that is in the ede/java-root.el file with the project type, and shows you the basics of how to use it.

How can I use Android with Java and a core made with Scala?

I made a small project using Scala (SBT + IntellijIDEA) that provides me a set of classes and other functions that I want to use in Android. I will call this project $core.
So, keeping that in mind I tried to first only use scala. I tried to create an Android Project using android-plugin and I got it.
But what I really want is to use my $core in an Android Project AND expand the $core classes using Java. $core provides an API that I would like more people to use and they probably don't know Scala so Java would be perfect. Besides, I need to go into a safe route with Android. I saw some info that scala takes a lot of time to compile into Android and has some limitations (like with parceblles).
I already tried to use the classes in eclipse with the import class folder option. I even tried to generate a jar so at least I would have a way to run it and no success. Always the NoClassDef error when I try to use one class from the $core. I have tried to import also the scala compiler library, but didn't work out aswell...
Core isn't finished yet and I would like to develop on a single environment that allowed me to debug on the android device. How can I setup all of this?
PS: Changing to eclipse now maybe is better? Never tried android on intellijIDEA and In scala I can't debug over there, at least using ScalaCheck...
Is it possible that you are getting an noclassdeffound error when working with Scala code from java because you didn't add the Scala library to the java project or at least included the party of it that it's used in the Scala code in the jar?
Could you post the rest of the error?
You could package the core to .jar together with Scala library, use Proguard to remove all unused Scala library classes from it, and then use that jar as a regular library.

Google App Engine "repackaged" package

What is the purpose of the classes in this package?
I want to use Base64 encoding in my app. As I'm typing away in Eclipse, I am prompted if I want to import a class called "com.google.appengine.repackaged.com.google.common.util.Base64"
I can't find any documentation about what this class does. No javadoc, or no mention in the Google App Engine manual (that I can see). Is this some kind of "hidden" API that I'm not supposed to have access to?
Is this some kind of "hidden" API that I'm not supposed to have access to?
Yes.
The purpose of repackaging Java classes is to have a private copy of a library that otherwise might conflict with another version of that some library (that the application developer adds to his project as a jar file).
It is one possible answer to JAR-hell.
Even the JDK makes use of this mechanism, e.g. with com.sun.org.apache.xerces which is an XML parsing library developed by the Apache Project that Sun choose to include (repackaged).
Do not call these classes directly. (You could, and they would probably work okay, but as they are not part of the official API, they could disappear in the next version).

Categories