[Leda 120.11] New compile config not working
I am currently trying to new compile configuration option and when I make changes to a file e.g. adding a println, I don't see the class get compiled at all.
I have turned on both the "use external build for compilation and make project automatically" options, but still no luck.
I am trying with a project that pulls dependencies via maven (not sure if that should cause any problems)
Please advice.
OS: Mac OS X (Lion, v. 10.7.4)
IDEA: Leda 120.11
请先登录再写评论。
Hi Bayo,
> I don't see the class get compiled at all.
The best way to check whether the file is compiled, is to check the output directory for an updated class.
When you press ctrl-F9, is the file compiled?
Eugene.
Yes, if I press Ctrl + F9, the file is compiled, but not automatically after save.
I thought that was the whole point of the new compile config? (to do Ctrl + F9 automatically for me behind the scene, when a change is made)
Please advice.
It will be compiled automatically after some delay. Generally, you shouldn't expect it to compile immediately. Just continue editing code or start your test. Before running the application or tests there will be one more check if sources are up-to-date (as usual). Then, if sources have not been compiled by auto make yet, they will be compiled. The whole point of the automake is to reduce work for "usual" make when you call it directly or indirectly.
best regards,
Eugene.
Thanks for your prompt response.
Apparently, this is not working for me still. I have waited and waited and don't see my files getting compiled or reloaded. I am using with along with jrebel plugin and it should reload the class once the change the compilation has taken effect. That doesn't happen.
If i manually trigger compilation with Ctrl + F9, i see the class reload immediately.
So something is definitely not right somewhere.
One more concern - do you have any active run configurations (running processes)? If yes, then the automake should not work. The automatic changing of clasess while running the application is not desirable because it is out of your control.
regards,
Eugene.
By running process, do you mean have my server running? If so, yes. It's a web app deployed on a running server (tomcat) within IDEA, and I make changes to classes and have them reload with rebel for agility.
If the new compile config is not designed to work with that, then I see "no value added" at this point. I am sure most will agree.
That sounds ridiculously limiting (if i understand you correctly).
So in what scenario is it useful? "make/build" happens even now (without the new compile config), before I run test cases, etc.
> By running process, do you mean have my server running?
I mean active run configurations started from IDEA.
>If the new compile config is not designed to work with that, then I see "no value added" at this point. I am sure most will agree.
>That sounds ridiculously limiting (if i understand you correctly).
Not at all. There will be a lot of people who requested the feature and who will not agree with your statement.
The whole point of the feature, as I mentioned above, is to compile in background as sources change on disk. This may reduce work to the "non-auto" make invoked by you on demand and thus reduce the time needed to compile when you start the application or test. Another side-effect of this feature that might be usefull will be showing errors from the automake in project view (this works now parttially, we need to make some changes to our error highlighter).
Why the automake is disabled when you have active run configurations? Because that way you cannot be sure at any moment what classes are actually running. After the IDE has compiled silently a bunch of classes of the already running application, you cannot predict the effect, there could be ClassDefNotFound errors or the application may exhibit some weird behaviour. I don't think anyone would like to spend time debugging such stuff.
Please also note that this is not a replacement for the usual make, but rather the feature that augments it.This is also not the exact copy of Eclipse's background compilation just because the goals of running compiler in IDEA and Eclipse differ. Eclipse needs background compilation just because it uses compiled classes to build the AST. So not up-to-date classes mean incorret work of IDE features. This is also the reason why Eclipse needs its own compiler for the work: because standard javac cannot generate class file for the sources with syntax errors.
IDEA does not need compiled classes to build the AST. Compiler is used just to produce executable classes. IDEA can use either standard javac or Eclipse compiler for this job. Using eclipse compiler is an advantage to those who always want to see full list of compilation errors in the project. In combination with automake this feature will also be supported.
I hope I answered your question.
Best regards,
Eugene.
Eugene - Thanks for a detailed explaination. I clearly misunderstood the intent of the new compile config. I was under the impression it will mimic eclipse's background compilation.
You have made good and valid points and I do see some value, but really not a whole lot for my current workflow. Time will tell.
Thanks again.
You are welcome Bayo,
Could you describe your workflow and your expectations from the IDE? What features in your opinion would have made your life easier?
Eugene.
Eugene - I described my workflow earlier.
I mostly work on web applications which are deployed in exploded format (during development), to a server that is kicked off within IDEA. Once the application is running, I changed stuff and with the help of jrebel, my classes are reloaded and I see results immediately (without needing a redeploy or server restart).
At the moment, once a change is made in a file or several files, I normally have to recompile the class(es) manually (Ctrl + F9), to have it reloaded.
I was excited about the new compile config, hoping it will take away the manual recompilation and basically work in the background compiling each change; allowing me see my changes as before without manual intervention. That will have saved several hundred keystrokes per day, in addition to the benefits you listed earlier.
> At the moment, once a change is made in a file or several files, I normally have to recompile the class(es) manually (Ctrl + F9), to have it reloaded
But is manual recompilation that bad? You always exactly know what changes are reloaded and you are sure that no changes are reloaded silently.
This is the most important thing here. Pressing ctrl-F9 is like telling "compile, collect and redeploy all changes up to this moment". What is the point of saving these keystrokes at the price of not knowing exactly what is running on the server at the moment?
Eugene.
No, manual compilation is "not that bad". I have done it for years and I am still standing :), but if I could save hundreds of keystrokes a day, I'll take it anytime.
> What is the point of saving these keystrokes at the price of not knowing exactly what is running on the server at the moment?
But I'll always know what is running on the server. "new config" will only change files that are outdated (at some certain interval) correct? In that case, I'll always know of what is expected to change with that regards.
BTW, I see how it does that is deleting the byte file and then re-generate a new one (hence your classnotfound exception you we refering to earlier) as oppose to just updating. I am sure there were reasons for that.
> BTW, I see how it does that is deleting the byte file and then re-generate a new one (hence your classnotfound exception you we refering to earlier) as oppose to just updating. I am sure there were reasons for that.
The reason is the correctness of compilation. Sometimes if you don't delete classes corresponding to changed sources, this may lead to compilation problems.
Eugene.
True. I should know better.
Eugene, I think you are missing a very important point:
If you run a web application, then there is a difference between the build folder and the exploded or archived version.
It does no harm to auto-make whenever possible (updating only the classes in the "Project (or module) compiler output".
IDEA should just not do auto-package or auto-deploy.
Well, we could think about special support of such cases,
Thanks for pointing on this.
Eugene.
"special"?
I think nowadays it is special not to build a web app, but to have a desktop app that is run directly from the build output :-)
I'd have to agree that web apps aren't exactly a 'special' case anymore :)
I have another suggestion that might be hard to do.
With the new compiler stuff, the Problems view is really really useful. So useful that I think it should be a tool window in its own right, rather than a window attached to the project view.
This would mean folk could look a the project hieararchy and the problems in the project at the same time.
So far so good though. The new Leda stuff is fantastic.
Folk sometimes ask me why I pay for an IDE. I just show 'em the SVN merge view; that usually does the trick ... :)
The lack of automatic compilation of a Java file on save is also my main issue with IntelliJ at the moment.
I'm also using JRebel and running my container using maven from the command line.
When I save a file in IntelliJ editor I want it automatically compile to the output directory. In this case JRebel would pick up the change.
I think the arguments are well explained already in this thread so I just wanted to vote for this as well.