Is it possible to configure Eclipse such that it will detect use of classes and methods not available to GWT and fail compilation early or maybe hide them from autocomplete ?
NO, there is no option in the google-eclipse-plugin yet.
In theory it could be feasible to call the gwt-compiler in draft mode after any single saving action, but this could be extremely slow.
With new features in last gwt version for super-devmode, this could be much faster because the compiler is able to perform incremental compilation. But I think it would not be faster enough.
Anyway you can try to add a task to compile your project any time you save a file:
Right click on the project -> Properties -> Builders -> New (call a script or an ant/maven task ...)
If you take a look to CodeServer and Recompiler classes you could figure out a way for coding a class with a very simple main() for recompiling your project from command line.
Related
I'm developing a struts2 webapp for months now using maven to manage my dependencies and I've just discovered LESS. I have installed and configured the LESS plug-in for Eclipse but it's really annoying to right click > run as > LESS compiler every time I save the .less file due to a modification of its content or something...
The thing is that I've been researching on how to plug in grunt.js (recently discovered task runners too) into maven (as explained here) but I think it's quite hard and I wondered if somebody knew an alternative to this.
In my struts2 project I have both the front and back-end of my webapp.I know it's not the right approach and if I could start all over again I would separate them into two different projects, but now it's too late (disadvantages of the learning proccess, we're not born knowing it all).
Having said all this, how can I set up a kind of task for watching my .less files and automatically compile them into .css when saved/changed?
I also found this ant task here, but I dont really know if it's what I'm looking for.
There are a lot of Java Less compiler (see Java Compiler for Less CSS?), so you can execute one of them by your build tool (e.g. Ant - maybe you need to write a simple Java application, which use the chosen compiler).
If you use Maven (or can switch to it) to project management, then you can use one of lesscss-maven-plugin:
biz.gabrys.maven.plugins:lesscss-maven-plugin
org.lesscss:lesscss-maven-plugin
see more...
It is possible to create an ant task to compile certain .less files into CSS whenever they are modified, and more or less is what I was looking for, but grunt seems to be more flexible as you can tell it to watch all your files with .less extension and in this solution I've found you have to declare in an .xml file the .less files you want ant to watch.
This is not explicitly what I was looking for so I'll leave this question open for now as I'll keep researching on how to make this solution more dynamic and see if it is possible to avoid the fact of defining every .less source and .css target you want.
Link to solution here
We use gradle as our build tool and use the idea plugin to be able to generate the project/module files. The process for a new developer on the project would look like this:
pull from source control.
run 'gradle idea'.
open idea and be able to develop without any further setup.
This all works nicely, but generally only gets exercised when a new developer joins or someone gets a new machine. I would really like to automate the testing of this more frequently in the same way we automate our unit/integration tests as part of our continuous integration process.
Does anyone know if this is possible and if there is any libraries for doing this kind of thing?
You can also substitue idea for eclipse as we have a similar process for those that prefer using eclipse.
The second step (with or without step one) is easy to smoke test (just execute the task as part of a CI build), the third one less so. However, if you are following best practices and regenerate IDEA files rather than committing them to source control, developers will likely perform both steps more or less regularly (e.g. every time a dependency changes).
As Peter noted, the real challenge is step #3. The first 2 ones are solved by your SCM plugin and gradle task. You could try automating the last task by doing something like this
identify the proper command line option, on your platform, that opens a specified intellij project from the command line
find a simple good enough scenario that could validate that the generated project is working as it should. E.g. make a clean then build. Make sure you can reproduce these steps using keyboard shortcuts only. Validation could be made by validating either produced artifacts or test result reports, etc
use an external library, like Robot, to program the starting of intellij and the running of your keyboards. Here's a simple example with Robot. Use a dynamic language with inbuilt console instead of pure Java for that, it will speed your scripting a lot...
Another idea would be to include a daemon plugin in intellij to pass back the commands from external CLI. Otherwise take contact with the intellij team, they may have something to ease your work here.
Notes:
beware of false negatives: any failure could be caused by external issues, like project instability. Try to make sure you only build from a validated working project...
beware of false positives: any assumption / unchecked result code could hide issues. Make sure you clean properly the workspace, installation, to have a repeatable state and standard scenario matching first use.
Final thoughts: while interesting from a theoretical angle, this automation exercise may not bring all the required results, i.e. the validation of the platform. Still it's an interesting learning experience and could serve as a material for a nice short talk, especially if you find out interesting stuff. Make it a beer challenger with your team when you have a few idle hours to try to see who can implement the fastest a working solution ;) Good luck!
I have an exported Eclipse Java Project in my server and I want to be able to compile the project and use ASTParser with JDT.
I'm able to compile the project using BatchCompiler, however it runs on console and gives me PrintWriters instead of an array of problems and errors. Also I want to be able to use proposals in Eclipse and BatchCompiler didn't built for this purpose.
Therefore I tried to use ASTParser, it can be used with either char[] or ICompilationUnit. CompletionProposalCollector and org.eclipse.jdt.internal.compiler.Compiler.Compiler needs ICompilationUnit so I have to create an ICompilationUnit which only can be created by an IJavaProject (https://dl.dropboxusercontent.com/u/10773282/2012/eclipse_workspace.pdf) in order to be able to use these features.
It seems the only way to create IJavaProject is to use ResourcesPlugin.getWorkspace(), however it returns java.lang.IllegalStateException: Workspace is closed. on my computer and it seems the reason is that the program that I coded is not an Eclipse plug-in.
Is there any way to create IJavaProject without Eclipse environment?
From the comments, it looks like you are trying to do more than just parsing, you actually want to get some form of content assist.
I'm afraid that you're asking for too much. There is no simple way to get the power and flexibility of JDT outside of a running Eclipse instance (believe me, I've tried). There's no simple way, but if you are brave and strong willed, you can one of try following:
Run a headless Eclipse on your server that works on top of an actual workspace. This would be the easiest to implement, but would be the most resource intensive and least flexible way of doing things.
Use the jdt core jar, and create alternate implementations of the IResource hierarchy, and the parts of JFace that are used by the the parser and the CompletionEngine. This would likely be the most feature-rich way to go, but also the most brittle. I can't guarantee that this would work as you may need to create some very complex stubs for internal Eclipse non-API classes.
Avoid the CompletionEngine and the ASTParser entirely and just use the batch compiler. You would then need to provide an alternate implementation of org.eclipse.jdt.internal.compiler.env.INameEnvironment. This implementation would be able to find types, files, and compilation units in your actual project structure. You'd need to reimplement support for content assist, but this would most likely work reasonably well.
I am actually fairly interested in doing something like this (but I lack the time to do it). If you are seriously considering creating a headless JDT that can run on a server, feel free to ask for more information. I am quite familiar with JDT internals.
I've had a similar problem. Here is how to use ASTParser without Eclipse (it just needs the core JDT JAR on the classpath): http://blog.pdark.de/2010/11/05/using-eclipse-to-parse-java-code/
Let's say my project has two builders: The first one is an Ant builder (or possibly just a simple command line builder) that compiles Protocol Buffer files with protoc to generate intermediate java files. The second builder compiles java files including the generated protobuf files.
The problem is that the build process should halt when there is a build error in the first builder phase, but it doesn't. When a builder fails, it just proceeds to the next phase. Is there a way to make it stop when it fails?
Thanks in advance for your help!
There isn't an easy way to do this. Even though Eclipse builders are ordered they aren't treated as step-by-step instructions for building the project. Each builder is invoked regardless of the output of the previous one. It is up to implementation of each builder to detect problems that are so disruptive that there is no point to running the rest of the builder's logic. For instance, Java Builder aborts if it detects certain types of build path problems.
You can force the behavior that you are after by disabling all of the builders and implementing the entire build as an Ant script, but you'd be giving up a lot to achieve this behavior.
I'm coming from a PHP/Python/Javascript background, and recently became very interested in Scala - specifically Akka coming from the web standpoint.
I'm having an extremely hard time though with general workflow, issues compared to interpreted languages such as the ones I described.
In general I tend to code, test results, code and repeat. This comes to a standstill when even changing a single line in a 20 line class takes up to 30secs to compile and run. Is this really normal? Do I need to just build, build, build then go back 30 minutes or an hour later and compile/test?
(I'm using IDEA with SBT) Do I need to specifically learn how to use Maven other than linking to the repos?
Thoughts? Advice?
I think you're on the right track with Idea and SBT. Have you tried
~compile
That will detect changes to your source automatically. For web applications, you can do a
jetty-run
followed by
~prepare-webapp
To continuously compile and redeploy your app to jetty. Makes Scala dev feel a lot like Python web development.
Usually I've found SBT to be very fast when compiling, especially the size file you're talking about. By the time I save my change and go to my SBT prompt, it's done.
Another handy SBT aspect is the REPL which will load your project and its dependencies:
console
You can reload any compiled changes with
:replay
in the scala REPL.
EDIT:
Guess I should mention that you can play around with a simple class with a main method. If you create a file called src/main/scala/Foo.scala that looks like this:
object Foo {
def main(args: Array[String]) {
println("Hello World")
}
}
And a file project/build/Build.scala like this:
import sbt._
class Build(info: ProjectInfo) extends DefaultProject(info) {
override def mainClass = Some("Foo")
}
Then at the sbt prompt, you can do
~run
To continuously compile and run the Foo.main method. You may need to do a 'reload' in sbt first. It seemed to take 2-3 seconds from saving change to seeing output. Then you just edit away, save and see changes. It's a pretty good workflow.
Also, don't forget the REPL - definitely a critical tool for learning Scala. You can learn a ton just playing with it interactively.
IDE Assistance:
With static typing language I find myself doing less of that workflow than I do with dynamic typing, but that was only possible because of excellent IDE assistance (the typing information allows it to detect errors early, and give accurate suggestions while you are editing), so it does save some time in that code-test loop you described.
However Scala IDE support in IDEA isn't yet at the level of Java for example,
both in catching errors while editing (IMHO) and speed of compilation.
REPL/Script support:
Do not forget that you can still use the Scala REPL, the workflow is pretty much like what you would be used to in Python for example.
IDEA + Scala speed :
You can refer to this question for more discussion on IDEA+Scala speed.
I use JRebel plugin with maven. I turn off the NetBeans compile on save feature,(don't know if intellij has similar) and run scala:cc - continuous compilation goal from console. It waits for any changes in source code, so after you make some, the file gets compiled, copied to /target directory and then hotswapped into running virtual machine. The procedure takes units of seconds depending on the size of the file.(I assume you do web development since you mentioned PHP and JavaScript) There is fsc server running in the background, that is also one of the reasons, why the compiling is speeded up.There are some minor disadvantages, you can't change the superclass, which means you can't go from AbstractFunction1 to AbstractFunction2 (which represent anonymous functions) - changing (x) => x to (x,y) => x + y means that you need to restart the server.
Useful links:
scala:cc
jrebel
One of the advantages to statically typed languages is that the type system can catch several types of mistakes/bugs. So, in theory, you shouldn't need to go through the rigmarole quite so often.
Of course there are many changes, especially in the UI, that only eyeballs on screen can check. All I can suggest there is good modularization to keep the compile/build time down. And unit tests. I don't know about the community that you're coming from, but in java/scala, unit tests are highly, highly recommended. You find out if the code worked right much faster that way.
The answer boils down to this: try and avoid having to build and restart to check your work as much as possible.
My Python-like workflow--which leaves me with very little time waiting--usually goes as follows:
Turn what I'm trying to do into a library (stick it in a .jar and add it to the classpath).
Work on the new code in an editor, but paste it into the REPL instead of compiling separately. Once it's working well, add a unit test.
Place the new code into the library. Repeat.
I can do this on a netbook and not wait longer than ~3 seconds for any one step.