I'm building a DSL using xtext 2.12 in eclipse oxygen following the smalljava examples in the Bettini book (2nd ed). Most everything works until I added a library as described in chapter 10. In unit tests that load the library explicitly, everything works: the library file loads, the implicit import succeeds, and I can refer to the types defined in the lib in DSL code.
However, when I now open the IDE it does not automatically load the library, and I end up with a NPE when the library tries to load implicit classes. It's clear that the loadLib method that gets called explicitly in the unit tests is not being called anywhere from the IDE because the log message is never emitted.
How do I get the IDE to load the library on startup? Specifically, I know what to call, I just don't know where to call it from in the IDE.
thanks!
Please make sure the package containing the library is exported by the plugin containing the library file and the plugin containing the test model file has a dependency to the plugin containing the library file
load lib is never called by the ide. the ide direcly builds the file from the classpath of the model containing project
Related
I designed a small DSL in Xtext and wrote a sample DSL application that is successfully converted to C++ code by using Xtend code generator. What I would like is to be able to click "Run" inside Eclipse and then to automatically compile the generated .cpp file and run it. How to do it?
The first what comes in my mind is to install the CDT plugin and get C++ sources compiled, generally.
Then, you may add the CDT nature to your project where the. C++ code was generated in.
After that, use the CDT menu actions to compile and run the code.
I wrapped a source github for b4a with Eclipse.
I added core.jar but when I compile the project in b4a it shows this error:
trouble processing "java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class": Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
This is often due to inadvertently including a core library file in your application's project, when using an IDE (such as Eclipse). If you are sure you're not intentionally defining a core class, then this is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core namespace, the source of which you may have taken, for example, from a non-Android virtual machine project. This will most assuredly not work. At a minimum, it jeopradizes the compatibility of your app with future versions of the platform.
I changed package name from
java.com.lsjwzh.widget.materialloadingprogressbar
to
com.lsjwzh.widget.materialloadingprogressbar
Why show in error -
"java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class"
?
I rebuilt the project in eclipse and compile with SimpleLibraryCompiler for b4a.
I forgot use
#DependsOn
for calling Additional jar in folder libs.
I am writing a small framework to handle asychron calls. To show how the framework works, I created a showcase. Inside the showcase I want to show the code (from the Java source files) and and what will happen when the code is executed. Something similar to the GWT Showcase.
To show the code, I use an IncrementalGenerator to read the java source files and generate the code for a widget to represent the code. To do that, I used the same code to read the Java filed as I did before in other projects.
It looks like that:
InputStream in = classLoader.getResourceAsStream(path);
if (in == null) {
logger.log(TreeLogger.ERROR, "Resource not found: " + path);
throw new UnableToCompleteException();
}
where path is the relative path of the file I want to read. In case of SuperDevMode the InputStream is always null. I also tried to work with the old Generator class but this did not work also. It looks like the files are not available inside the classpath when the generator is executed in case the code server is started.
I tried the same code with Dev-Mode-Plugin and it works fine!
so, how can I access the Java source files of a project inside an IncrementalGenerator using SuperDevMode?
I use GWT 2.6.1, IntelliJ v13.1 Ultimate.
Thanks in advance
If you're giving the sources to the CodeServer using its -src argument, then they won't be in the classpath; if you expect them in the ClassLoader, then they have to be in the classpath (like you give them to the GWT Compiler or DevMode). To make your generator robust, you should first try the ResourceOracle and then fallback to the ClassLoader.
FYI, some built-in generators are currently loading from the classpath and are being modified to load from the ResourceOracle for better incremental compilation: https://gwt-review.googlesource.com/8811
I spend another few hours to find a workaround for this problem.
At the end, it was not related to GWT. I discovered, that the -src argument has no impact on the content of the classpath. Inside the compiler settings of the IntelliJ project, I found a setting, which control the type of resources that are copy to the classpath. After I removed the pattern which let stop IntelliJ copying the *.java files to the classpath, everything works fine.
It looks like the output of the classpath could not be controlled with the -src argument in IntelliJ.
I have developed a scala application for the first time, but I have to deploy it with a "one-click" type script that can run and build the scala application from source WITHOUT ECLIPSE.
Since I'm completely new to scala I don't know how to tell it where all my source files are etc... to get it to build my app from the command line. I also have 2 3rd party .jar libraries that I need to tell the scala compiler to link to...
Any documentation on this? Or example command lines? My project hierarchy is:
src/packagename: contains all .scala
bin/packagename: contains all.class files
libs/ -> contains 2 .jar files I will need to import somehow
I'm working on debian linux
EDIT: I found this ability to export in eclipse so I created a .java file and called my main scala object from it. Then I exported as a runnable jar. However, when I go to run the new runnable jar "sudo java runnable.jar" it says "class not found exception: runnable.jar"
You should take a look at https://github.com/harrah/xsbt/wiki which is the common way to build a Scala project. Run through the tutorial in the wiki to learn how you should organise your directory structure, so that everything may run fine.
If you want to combine it with eclipse, checkout this plugin: https://github.com/typesafehub/sbteclipse
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)