Problems reading Java source files from IncrementalGenerator using SDM - gwt

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.

Related

Scala in IntelliJ error

I just downloaded the plug in for Scala in IntelliJ and have created a project but now have various errors I read that the problem can be that I am missing a library. But when I try and go to project structure -> dependencies to add a library I have no clue where in the files to look for a library.
The errors are really simple but I can't seem to figure it out.
Any suggestions would be helpful :)
Here's everything you need to properly set up Scala plugin in Intellij. Furthermore your code has several errors:
Are you sure you created a Scala project (when you did File->New->Project)? This looks to me like a Java project? That class file looks to me like a Java class not a Scala class (that's why you're getting compilation errors on def but not public class).
1) value is not defined anywhere, of course it will throw a compilation error
2) classes in Scala are by default public, you do not (cannot) mark them as such
You can save yourself a lot of trouble by creating a simple SBT project that specifies all of your dependencies, etc. and then just pointing the IDE at that. Then when you change build.sbt, IntelliJ IDEA will notice that and update itself automatically. Plus, your build.sbt gets checked into your code base so that anyone you are collaborating with sees your changes to the dependencies. And the project can be built in batch mode using sbt compile and friends.
The following page talks about IntelliJ IDEA's "SBT Import" feature:
https://confluence.jetbrains.com/display/IntelliJIDEA/Getting+Started+with+SBT
Scala source files end in .scala, not .java. Try renaming Counter.java to Counter.scala. This should improve things a lot.

Attempting to modify typesafe activator UI. How do I import/modify the activator jar files in eclipse scala IDE?

I am new to the scala eclipse environment and also new to typesafe/activator.
I need to modify some of the activator initialization code because of some very specific host-side dependencies.
I cannot see how to "import" the actual jar files into eclipse. I know exactly what I need to change and how (via manually opening the jar and looking at the code). But I want to maintain complete integrity with the change management (ivy and sbt) but I do understand how to do this.
Is there some basic way to pull in/open a source jar, modify it, and build/deploy it? I see lots of help on the export/build, but I need help with the open/import/modify portion of this task.
Thanks for your kind help.
Typically if you wanted to change how a project works you'd go back to the source repository (in Activator's case https://github.com/typesafehub/activator ) and modify from there and then rebuild. Source jars don't have the build configuration so they are not useful for creating new binaries. Usually source jars are used to show source in a debugger or to click on a type in the IDE and see the source code for that type.

Eclipse Scala IDE: can't open hierarchy for standard library classes

I have exactly the same problem as in this question: Eclipse: Using "Open Declaration" ... in a Scala project
However, I'm using the latest Scala IDE in version 3.0.2 (I have downloaded the Eclipse bundle from the site), and I would assume such basic functionality works by now, and apparently it's me who have something misconfigured.
I have created a new Scala project. Then I open some standard library class/trait/whatever, let's say scala.util.parsing.combinator.JavaTokenParsers. The source is neatly displayed, but when I try to show class hierarchy, I get the message: The resource is not on the build path of a Java project.
Also, searching for references etc. won't work.
I guess it is a matter of properly configuring the build path? Or maybe I should somehow attach Scala library sources to my project? But I can see the source, so aren't they attached already?
Here is the snapshot of my project configuration:
UPDATE:
By playing a bit with setting/resetting build path stuff, I managed to get rid of pop-up warning but the class hierarchy comes up empty and when searching for references I get only hits from my own sources, nothing from standard library.
In another workspace I also tried randomly adding and removing scala-library jars and got it work almost, but the type hierarchy comes up only with super-classes, without any sub-classes (which renders it quite useless). Searching for references works ok though.
Funny thing, I cannot make it work in my original workspace...
Gotta love Eclipse.
Your build path is not configured properly.
If you take a look under Scala Library[...] you have scala-library.jar we can only see one top-level package scala. There should be numerous other packages besides that. (Ruled Out)
I would recommend you follow these steps
Right-click project, build-path, Java-build-path, Libraries and make sure that the correct library is referenced there.
If it is the one you need, Try to remove this library and add it again, then clean and re-fresh the project. Also try this step in a fresh workspace.(something must have messed up this workspace )
Lastly. Goto the path D:\Eclipse For Scala\configuration\org.eclipse.osgi\bundles\286\1\.cp\lib and verify the sizes of the jars there. There should be 6 jars there and the size of scala-library jar should be around 6.8M. If size is smaller, consider re-downloading

Intellij compile failures: "is already defined as"

I've got a scala project that compiles, runs and tests fine when using SBT from the command line. However, when building the project in intellij, it seems every class in the project has this error in the event log, causing the build to fail:
SendCommandToService is already defined as case class SendCommandToService
case class SendCommandToService(service: String, commandName: String, keys: Array[String], values: Array[String])
^
For me, the reason is that both myproject/src and myproject/src/main/scala are marked as Source. So IntelliJ failed to build myproject/src/main/scala due to above errors. Unmark Source from myproject/src (in IntelliJ, File->Project structure, select myproject Module, select src folder in Sources Tab, remove it from Source in the "Add Content Root" pane) solved the problem.
It means there are two compiled classes with identical package and class name found in your classpath. One compiled by sbt, one compiled by IntelliJ.
One of the following should be able to solve the issue:
try to generate IntelliJ .iml file with sbt-idea rather than import directly.
sbt clean before click Build -> Rebuild in IntelliJ
when rebuilding with IntelliJ, make sure sbt is not running
I ran into this issue today on IntelliJ 2021.2.1 and according to this page it's some issue with IntelliJ's incremental compiler for Scala, so the solution is to change the "Incrementality Type" from "IDEA" to "Zinc" in Preferences -> Build, Execution, Deployment -> Compiler -> Scala Compiler
For me, the solution was to double check the source folders in each of my modules in IntelliJ.
File > Project Structure > Modules and for each module, double check that the Source Folders only contain your intended folders, e.g. src/main/scala, and do not contain any generated sources (e.g. target/scala-2.12/src_managed/main.
I had the same problem and #Max is right, there is a conflict with the compiled classes, but the solution provided didn't work for me. It turns out that I was using sbt-idea to generate the IDEA project structure as a workaround of an Intellij IDEA 14 + scala plugin bug on the SBT import, that is not fixed yet at the time I write this.
In order to fix it, I had to remove src_managed/main/controller that was in conflict with src_managed/main in the Module settings because of an sbt-idea bug. So double-check your module source folders and make sure you don't have subfolders in conflict with a parent folder already declared as source.
You need to change "Settings -> Build,Execution,Deployment -> Scala Compiler -> Compile order" from "Mixed" to "Java then Scala".
If you have compile the project previous, you should first run "sbt clean".
I had a similar issue repeatedly both within Idea and without: plain SBT.
It turned out that CVS stores copies of some *.scala files in subdirectory CVS/Base, which SBT apparently tries to compile. The problem went away when I deleted the CVS subdirectories.
Problem is caused by duplicated line in .idea/modules/<your_project_name>.iml file. Check if you do not have duplicated <source_folder> tag.
In my case I had the same problem with all classes in src/test/scala path, and after removal duplicated tag for this path, project build fine.
Do you have any other files in your project with an SendCommandToService in them?
You could try renaming it to something else, see if that works
If you want to keep the same names, you can put them into separate packages.
Or have them in different encapsulating objects
object traitdemo{
object Ex1{
...
}
}
object otherdemo{
object Ex1 {
...
}
}
that will work even in the same file
In my case problem solved by change ScalaTest template configuration in Idea. I select use sbt, disable print info, remove build before launch.
I like to use SBT for clean/package/test on specific module. I also use mixed Java/Scala classes in test (but I replace compile order to Java than Scala).
At least now I can test from IDE withot this error.
PS: Now I disable use sbt. My tests work fine (but I'm not sure, that they will work).
PPS: New tests not runs before compilation. It is disadvantage of removing build (and, maybe, of disabling use sbt). But this extra build cause problem with dublication, as I think
File -> Invalid Caches/Restart worked for me. All other answers here did not.
After the sbt compile I had to mark the folder as Generated Sources Root because I needed those files for compilation.
I'll just add mine to the list in case anyone else made this beginner mistake: I temporarily "saved my progress" by doing cp Foo.scala Foo-save.scala, forgetting that sbt would try to compile all the .scala files in the directory.
(I don't know, I guess I was thinking of programming languages where any file not explicitly included was ignored ...)
Of course, since both the main file and the "temporary backup" file defined the same classes ... yeah.
I had the same error message and it turned out that IntelliJ for some reason created duplicate copies of some existing source files. For example I had a file Attribute.scala that was tracked with git and then there was an untracked file Atrribute 2.scala with the same contents in the same directory (which I never created). This was of course a problem, because the compiler considers them part of the project, hence the duplicate object definition error.
I am not 100% sure when this happened (I suspect it was during git rebase). So, if you run into this problem again, it's also worth checking with git status if you have some untracked files which duplicate contents of tracked files.
Remove the untracked files and the problem is solved.
Kudos to this question thread, it helped me to solve this issue.
My case is a project with the mix of Scala, Java and Avro schemas.
IDE: IntelliJ IDEA 2022.1.3
How I solved it step by step (in IntelliJ):
File -> Project Structure
Project Settings -> Modules
Now we need to fix the "source" files. I searched for target/scala-2.12/src_managed in each module and marked it like “Source directory” (blue colour).
Unmarked all other paths like target/scala-2.12/* in all modules (in my case it was target/scala-2.12/src_managed/main/compiled_avro). As an example from my project, I left only these sources in one of the modules: target/scala-2.12/src_managed , src/main/scala.
Save the changes and rebuild the project.
ADDITION: Oh, and looks like sometimes this error occurs when you compile your scala project (with avro files) outside of the IntelliJ. For example when you build a project using sbt externally and then run some tests using the IntelliJ -> class already defined error occurs (or is not a member of package error). In such case: you need to run sbt clean compile externally first and go to step #1.
this happen when you incorrectly src/main/any other folder as Sources Root. Please check if you have any such cases. If yes, then Unmark those by righclick on it. then clic one level above of your groupId starting. Lets say your package is com.company.test and com may comes under java or scala, then right click on that(java/scala) then Mark as Sources Root.
In my case, the problem was the protobuf Idea plugin:
Remove the idea protbuf plugin.
Close Idea
Remove all folders related with idea (.idea and .idea_modules)
Open Idea and Import the project again.

Creating javadoc with gwt-user.jar through Gradle

I'm trying to compile the javadocs for my application, and for some reason it throws errors while compiling like this:
/Users/Sander/.gradle/caches/artifacts-23/filestore/com.google.gwt/gwt-user/2.4.0/jar/949dcb5d14cb0e2c8dec98efc0760be68753c124/gwt-user-2.4.0.jar(com/google/gwt/dom/client/CanvasElement.java):18: error: cannot access Context
import com.google.gwt.canvas.dom.client.Context;
All the errors thrown are found in gwt-user-2.4.0.jar. Basically, what (I think) it's trying to do is compile the .java source files the jar file contains, which it shouldn't do. Is there a way to make the javadoc command ignore java source files?
I've tried removing the source files from the jar manually, this way the build succeeds. However, since the jar is a gradle dependency, manually altering the file is not an option.
I finally got it to work. As it turned out, the javadoc command needed a sourcepath flag set, because otherwise it would start looking for the source files in the classpath, which contained some source files from the GWT jar file. Since the MinimalJavaDocOptions GWT class doesn't support this, I had to set it manually by adding the following line:
options.addStringOption("sourcepath", <path_to_source>)
This fixed the problem. Obviously it is not ideal, a topic in the Gradle Support Forums has already been created, see http://forums.gradle.org/gradle/topics/allow_javadoc_sourcepath_to_be_set_directly