In eclipse, my sbt files show the 'J' symbol in the icon, rather than the superman 'S' symbol I expect to see for scala files. Not a kryptonite-serious problem, but how do I fix it?
generated via sbt-eclipse plugin 2.4.0, sbt 0.13.1-RC2, eclipse 4.3.1, scala-ide 4.0.0-m2.
I'll guess that the problem is related to the convention of including sbt .scala files in the root of the /project directory.
Edit:
It is bad to not have the super 'S' symbol, otherwise the .scala files won't be compiled in eclipse.
I manually added the following to the project/.classpath:
<classpathentry including="*.scala" kind="src" output="target/scala-2.10/sbt-0.13/classes" path=""/>
That fixes things. Is this an sbteclipse issue? Is there a workaround?
The wrong icon is the result of a bug in SDT - I created a ticket.
Beside from that, Scala files (as well as Java files) which are not assigned to the classpath (as it is currently the case for sbt project files) are not compiled by Eclipse (because they are not associated with a builder).
Nevertheless, you get most other IDE features for these files like semantic highlighting or auto completion (in fact all features which don't require or rely on bytecode generation should work).
Related
I've got a rather large project set up in intellij. The project uses scala scripts to specify various instances of the program.
It used to be the case that the scala scripts were in a resources directory of the project, but, this is not ideal. I've moved them, so my project looks like this (the idea is, ultimately, to move them away completely)
+Project root
+subproject
+src.main.resources
[Scripts were here]
pom
iml
pom
iml
+scripts
[scripts are now here]
but now intellij syntax highlighting does not recognise the scripted imports relating to the project. Is there some way of getting intellij to recognise the dependency of these scripts without going back to a module structure and the src/main/resources folder?
Define scripts as a source folder:
File > Project Structure > Modules > Sources
and mark scripts as Sources (blue icon).
You can find more info on IntelliJ WebHelp.
I have an eclipse plug-in working fine within eclipse environment.
I wanted to export it into a jar file, so I chose Export > Deployable plug-ins and fragments.
I could get a jar file, but an error was reported.
Opening the log file, it reports that I have 1242 problems (191 errors, 1051 warnings). This is some copy from the error log.
2. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 61)
import edu.washington.cs.induction.OnePipeLineScript;
^^^
The import edu cannot be resolved
----------
3. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 261)
OnePipeLineScript.getMatchingForRefFinder(projName, proj1, proj1Loc
^^^^^^^^^^^^^^^^^
OnePipeLineScript cannot be resolved
Why I got errors? I had 2049 warnings, but no error when I compile the plugin in eclipse IDE.
ADDED
The main project references two other projects, and references many external libraries. I attach the package view and Java build path.
There were multiple issues involved for this problem. However, the core issue was that the project apimatching and originanalysis were not eclipse plugins but just java projects. As a result, those two projects were not included in the final jar file to break the build.
Symbolic linking the two projects into the main project
I solved this issue by symbolic link the src directory into the main eclipse plugin project.
ln -s /workspace/seal/edu.ucsc.originanalysis/src /LSclipse/originanalysis
ln -s /workspace/seal/edu.ucsc.apimatching/src /LSclipse/apimatching
From the Java Build Path/Source tab, I added those two included projects as source. Eclipse Java Missing required source folder: 'src'
Now I have eclipse plugin jar file without error.
Then click F-5 to refresh the project explorer and check they are java src directory.
Select the included projects in Build tab.
Updating bin.include and source.. in build.properties tab is important. One should understand that in bin.include the ordering is also critical. lib/cdtparser.jar and lib/cdtcore.jar should be placed prior to the user of them - origin analysis/.
Copying jar files for included project into main project
I also had to copy some jar files in those projects file into the main project, and select them in Binary Build tab.
And add tim in Runtime/Classpath tab.
Select the JavaSE-1.6 in Execution Environments.
I have lots of "Must Override a Superclass Method" errors. With the hint from this post - 'Must Override a Superclass Method' Errors after importing a project into Eclipse , I removed the J2SE-1.5 to resolve this issue.
You can not add third party libraries into class path of Java when developing a plug-in. It is the way to build standard Java application, but plug-in is a kind of OSGi bundle that has itself rule for class loading.
The correct way is adding third party libraries into the class path of your plug-in.
Add below declaration into MANIFEST.MF of your plug-in,
Bundle-ClassPath: lib/log4j-1.2.7.jar,
xml-apis.jar,
...
Check those links [1], [2] for understanding it.
This is what have a question on and see as potential solutions to potential problems.
Is this class comfing from a referenced jar or is it in the actual plugin edu.washington.cs.induction.OnePipeLineScript;
You seem to have a lot of soure folders and wondering if your build.properties file is showing any warnings and that you also have this defined for each of the source folders in your build.properties source.. = src/
Your external jar libraries appear to be in a folder that is of type source which is not correct. It should be a non-source folder (which you can tell a source folder by the package icon decorator) and you should make sure in your manifest editor that for runtime you have the lib checked so that it includes the jars in the build. To unmark it as a source folder select the drop down menu in your navigator view go to filters and uncheck .resources which will then show the .classpath file in that file you will see the folder to be kind="src" (i believe) remove that.
Somehow it also looks like you have linked source folders which is a practice I would not suggest and am not sure if that will cause problems when exporting the plugin. If you can avoid linked source folders that would be better.
Also it seems like you are confusing java build path configuration for plain java applications with plugins running in OSGI which is not configured through java build path but your manifest.editor So as a rule of thumb if its a plugin don't even bother trying to configure the java build path because OSGI is different, that could be causing issues as well
Select "Use class files complied in the workspace" in Options works for me.
I have created a project using maven in Spring STS. I opened a source file(class file which is downloaded by maven automatically) and placed cursor on methods/variables those occurrences not highlighted in class. How can I fix that?
This is complicated and it is not a maven or an STS bug. Rather, it is a Eclipse JDT bug. Mark occurrences cannot work unless the class file and all of its dependencies can be classloaded using the current project's classpath. So, there must be some dependency that is missing for the class in question. It is probably available at runtime through maven, but just not at edit time.
It is very tricky to fix this problem, but you can start by explicitly adding all transitive dependencies to your pom.xml.
I want to modify automatically the order on which classpathentry are written by the Maven Eclipse plugin. Is there a way to do that?
I want to do that for two reasons.
First reason: in my application, the interface org.w3c.dom.Node is provided by several third-party libraries (for XML processing), as well as the JDK (1.6). However, the version of org.w3c.dom.* classes provided by these libraries are quite old compared to the JDK. For example, the method Node.getTextContent() does not exist there.
Running mvn eclipse:eclipse on my project will place these library before the JDK container in the .classpath, using this method in Eclipse will result in a compilation error. So the idea is to put this line:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
at the beginning of the .classpath file.
The second reason (less important) is when I run mvn eclipse:eclipse, it always set my src/test/* packages before src/java/* ones, which bothers me a little (yes, I know that in TDD we develop tests first, but still...)
Technical information: Java 1.6, Maven 2.2.1, Eclipse plugin 2.8
Edit: There is a question here that could look similar to mine, but it did not help me as it only deals with the order for third-party dependencies...
See this post: Maven classpath order issues. I can confirm that the 2.9 plugin has fixed this issue (or allows you to futz with the config).
Can anyone explain where the Eclipse GWT plugin defines it's entry points?
In an attempt to get my old GWT project working again with GWT 2.0, I created a default GWT 2.0 project in Eclipse and was able to run it successfully. It's the one that asks for a name and calls the 'greet' servlet on the server, which responds etc... so far so good.
I then ported all the classes from my older maven GWT project over to this new GWT project in the hopes of getting the RPC calls to work. It had many dependencies, so I also copied over the maven pom.xml, commented out all of the gwt related plugins in the pom, and managed to get the Eclipse M2Eclipse maven pluging to recognize the pom and adopt all of the maven dependencies. All of the issues in Eclipse are now resolved and it looks good to go.
However, when I click on the GWT compile icon for the project, it pops up a "GWT Compile" dialog now asking me to "Add an entry point module". There are no entry points listed to choose from in this dialog. This is frustrating because I kept the exact same GWTApp.gwt.xml and moved my code into the previously-working auto-generated GWTApp.java class.
I can't imagine why the Eclipse plugin doesn't look in the GWTApp.gwt.xml file to figure out what the entry points are.
Can anyone explain how these entry points are defined or suggest why the project stopped working?
Thanks!
I'm certain the following is the problem and solution. I've been doing GWT for about 6 years.
Whenever you import an existing maven (namely from a Mojo-generated archtype, but probably others) project into eclipse, you will get a broken configuration which will not allow you to debug until you fix it. But the fix is simple. What happens is the build path will be set to exclude all files from '[proj]/src/main/resources', and this has the effect of hiding the [proj].gwt.xml module file from eclipse. So all the GWT dialogs that look for those modules can't see them! So you can't even create a debug configuration that works.
Here's the fix:
Right-click the project, and open Properties -> Build Path dialog -> Source Tab, and look for the one ending in '.../src/main/resources', and you will see it has excluded: . So highlight just that entry and remove the '', so that it reads "Excluded: (None)". Now the dialogs (namely the debug configuration dialog), for GWT will all see your module file, and everything will work.
Just to be sure, that wouldn't be similar to this case, where the exclusion filter was a bit too large?
<classpathentry kind="src" output="target/classes" path="src/main/java"/>
<classpathentry excluding="**" kind="src" output="target/classes"
path="target/base-resources"/>
I think that you may have an exclusion filter which is too aggressive on your "target/base-resources" directory.
It seems that you have an exclusion filter of "**". Won't that match everything?
You are right! This was the problem! :)))
I didn't know what the exclusion filter was and somehow it was added automatically during the development.
Thanks for the suggestions to my question - you prompted me to find the answer. I looked and did not have any exclusion filters but checked the Java Build Path in the project properties.
When I'd added the maven dependencies, it must have implicitly changed the defined source directory of the GWT eclipse project. (Probably to src/main/java or whatever that dumb long-winded maven default path is). Eclipse offered no hints that the Java classes were not on the project build path. Once I defined the src directory explicitly for the project, the gwt.xml module appeared in the GWT Compile dialog box!
On to the next hurdle... coz it still ain't working yet! :(
Thanks for your help!
Sonatype's eclipse maven plugin is infamous for many things. One of them is excluding all the files in your resources maven folder for a given module whenever you allow it to rebuild the eclipse classpath.
m2eclipse will probably be the single reason that I re-evaluate using Intellij...
I had the same problem.
Right click the project and select properties.....
There was empty dialog (no entry points suggested).
After some digging I found that mymodule.gwt.xml file was accidentally marked as "lib" in .classpath (eclipse project file in the root of the project folder). I seems it was marked as "lib" on .classpath automatic generation (I was importing clean maven GWT project, not eclipse project).
Simply delete line with mymodule.gwt.xml from .classpath file, cause it is in src/main/resources, that is normal "src" classpath.
Right click the project and select properties. Expand and select Google -> Web Toolkit. The right pane will have a section called Entry Point Modules. Click the add button and select your .gwt.xml file.