We are using IntelliJ IDEA version 19 towards development of a web application in Grails 4 framework. The issue we are facing is, while undertaking code changes in controller, services and domain the IntelliJ IDEA version 19 is compiling the entire project, i.e. the project gets restarted and the entire project gets complied from the beginning as a result of which the whole process of compilation is taking longer time. Where else compilation of GSP and JavaScript files are happening dynamically without restarting the entire project.
It is requested the way ahead for the said issue to be provided.
Related
I have been having trouble utilizing Javafx within Intellij. I run into the error "JavaFX runtime components are missing, and are required to run this application" that I see a lot of other people have.
My main question is do I need to download Javafx12 sdk. I am able to use Dr.Java to run some of my old javafx projects just fine after adding an extra class path and I haven't needed to downloaded anything. It doesn't seem like I need to download anything as another much more basic IDE is able to run javafx. So why does it seem like intellij requires an extra download?
If you moved to Java 12, then yes, you need to download the JavaFX 12 from their new website https://openjfx.io. Luckily installing it is pretty straightforward and well-explained.
It worked before because JavaFX was shipped inside the JDK distribution, which is no longer the case. Swing however is still there and will work as before. (I am not saying you go back to Swing, just that it is still shipped along the JDK)
It looks like IntelliJ's (Ultimate EAP 15) support for Grails 3 is in the early stages yet. If I do Run -> Debug 'Grails:My App', I'm able to launch an app from inside IntelliJ, I can set breakpoints and it works as expected.
If I make changes however, I see in the console that the file is recompiled, but when I hit reload in the browser, I don't see the changes reflected there. I have to stop and restart the app in IntelliJ before I see them. Anyone know how I can get the auto-reloading working?
After chasing this for a week, this post finally provided an explanation.
It's actually a Grails issue, not a problem with IntelliJ's Grails integration: spaces in a file's path will break automatic reloading. Renaming my project from Grails Demo to GrailsDemo got everything straighted out. (Storing a project in a folder like My Documents will also cause trouble.) The post's author indicates that this started with version 2.4.4 and it's still happening for me in 3.0.4.
This is an extension of an earlier issue I had, which I posted about here: VB.Net Method appears to be called multiple times when it actually isn't, and returns inconsistent results
At that time I had thought the issue was fully resolved, but I've since learned that there were multiple issues. I have worked out all the kinks with the code and logic, and now I've narrowed down the last remaining issue.
Builds will run perfectly fine until one legitimately fails. After that point, all the builds on that specific agent will fail, even if there were no actual errors with the subsequent builds. When they fail, I see the exact same symptoms as I did in the other thread, which I will summarize here:
A method that is only called once appears to be called multiple times as evidenced by the build messages
The build messages will show there is 1 error, but there are no errors in the logs generated by that method (The line to write the error to the log comes immediately after the line where the error is added to the result log, in the same if statement)
Restarting the build service on the build server "fixes" the problem until the next time a build legitimately fails, at which point the cycle starts again
Build server setup:
Windows Server 2008 R2
VS 2010 Premium
Build uses a custom library
There are 4 build agents, one for each environment (Dev, QA, UAT, Prod)
The build and deploy custom library is written in VB using .Net Framework 4.5, and it calls on another library that is written using .Net Framework 4.5 as well.
The build template doesn't use msbuild. It's strictly WF that's been stripped down to the bare minimum and only calls commandline programs (Like robocopy) or custom .net classes.
I have verified that if a build fails for one agent (such as Dev), then all builds using that agent will fail. When it happens, ONLY builds that run on that particular agent will fail, other agents run just fine. I have not had a chance to test yet if just restarting the agent will "fix" it, or if I have to restart the entire service.
I have tried clearing the Visual Studio cache for the user account running the builds, but that didn't help at all. I also have a GUI interface that I designed that does all the same things as the build, and uses all the same code, and I am not able to get it to repeat the behavior.
I've enabled logs on the build controller per these steps: How to enable build agent or build controller’s logs? however they were no help when this problem occurred (There were no errors logged, nothing was different in the logs for builds that were fine vs. ones that bugged out)
I'm not sure what my next troubleshooting steps should be, I know the problem isn't with my code, and I'm having no luck searching the internet via Google, MSDN, StackOverflow, or picking the brains of my peers at other organizations.
I'm wondering if this could be a bug due to running code that requires .Net Framework 4.5 in TFS 2010 build, since it only officially supports up to 4.0.
My advice would be to change the build logger to diagnostic and look at the output, there must be some rubbish being added to the environment.
You can do this with a switch like
/l:FileLogger,Microsoft.Build.Engine;logfile=c:\build.log;Verbosity=Diagnostic
you might want to take a look here
We have CI set up on a solution within the company.
The build was taking roughly 13 minutes in total, which seemed a bit a too long. After some digging around, I found out that the we were not passing the /maxcpucount switch to the msbuild command, and so each project was being built in sequence as opposed to parallel. Adding this switch dropped our build time down to 3 minutes.
However, we started seeing builds intermittently failing with the message that a cached nuget package was already being used by another process. The project that would fail to build, and the locked nuget package would change every time.
This turned out to be because we were building multiple projects within the same solution at the same time, and we could get the circumstance whereby two projects building in parallel tried to access the same locally cached nuget package at the same time.
We surely can't be the only people with this problem, as it seems like it would be quite common. Does anyone have experience with this problem? Are we doing something wrong? How can we prevent these builds from failing?
So I finally figured what was causing this, although I can't figure out why.
In our Teamcity MSBuild step, we had our Working Directory set to %build.root%. Removing this value, so that the default of the checking directory was used, appears to have stopped that error from occurring.
I'm using the Sonar Eclipse plugin v3.3.
After I've fixed a rule violation, not a new issue, but one that exists on the sonar server, I re-run the analysis on my project in Eclipse. I expected that the fixed issues would no longer be flagged by the analysis, but they appear to be still flagged even though they have been fixed.
In my Eclipse SonarQube preferences I have the severity marked as warning and Force full preview... unchecked.
In the view options I have Show->All Issues on Selection checked.
How do I set up the plugin so that once I've fixed the issue locally, the issue is no longer flagged when I re-run the analysis on my project?
Edit:
Full analysis is run nightly by a conditional build step in Jenkins using SonarQube Runner.
When I run the analysis via Eclipse, the first thing it does is wipe out the existing issue annotations, but then as soon as it contacts the server it immediately adds them back in. The issues stay flagged regardless of whether they were fixed locally or not.
If I intentionally put in the wrong projectKey in the org.sonar.ide.eclipse.core.prefs file, then the local analysis runs similar to what I would expect. It flags all existing issues as new, which is expected, since it can't reach the server to ask if they were preexisting. It doesn't flag any fixed issues.
The problem was that I was using 3.7.3 on the server and not 4.0 or above. I upgraded the server install to 4.1 and all is well now.
BTW - The Sonar console output clearly stated :
SonarQube version 4.0 is required to perform local analysis.