we are using Grails together with Maven and Intellij. For the beginning of the project it worked everything nicely. Now we are getting more and more strange effects like when somebody is checking in wrong code, some are getting error some are not.
Are there any best practices to config IntelliJ so thats it working on each machine good and predictable?
We found out that some having the "make" before starting the project disabled but this didnt solved the issue.
Thanks for your help!
Got very little problems in 2 years. Idea had couple of cache issues a year ago, I wiped caches by hand. Ever since then, had no problems with caches/indexes.
Couple of things I could think of:
grails clean usually fixes most weirdness;
Yes, removing "Before launch - make" flag stops Idea from doing wrong guesses and unnecessary compilation (which id does differently from Groovy compiler);
For every new run configuration, we add ValueFormatter to VM parameters, or add it to Grails defaults;
Create a run configuration for test-app and run it on regular basis;
Give it as much memory as you can in idea.vmoptions.
Related
I've spent too long on this not to share.
I made a Windows Service with .Net 6.0 and the Host.CreateDefaultBuilder method. It worked fine, was deployed correctly. Then I modified something that worked in dev, but failed at startup in prod.
Looking at the logs, there was a problem with Dependency Injection that pointed back to the first line of my Program.cs. I tried everything around every DI thing I injected in the code, all the way to doing an "empty service" that was running a Task.Delay loop with nothing injected at all. It still failed.
I went back with working versions stored in Git. Still failed.
Nothing changed on the server, afaik.
So ultimately, I figured out that the problem was in the bundling of the Publish process: when using publish as single file, it failed. Turning that feature off solved it.
So in your .csproj, add (or modify) this line:
<PublishSingleFile>false</PublishSingleFile>
I don't know why it worked at some point and stopped working, but there's definitely something not right with that process.
I'm new to Xamarin/Android, and so far it's been a pretty frustrating experience, compounded by code/AXML changes seemingly not being built or deployed to the emulator. I often find that a change I've just made seems to get ignored when I build and run the app.
My suspicions were confirmed when it started throwing an exception on a line in MainActivity.cs that I had commented out. Cleaning and rebuilding didn't help, and in the end deleted the bin and obj folders and uninstalled the app off the emulator for good measure (not sure which of these fixed it though).
Is it just me or is this a common issue? Is there anything I can do to prevent it from happening? I'm using VS2015 Community by the way.
Go to 'Tools/Configuration Manager' and make sure that both 'Build' and 'Deploy' options are checked for 'YourApp.Android' for active solution configuration and active solution platform. Then do 'Clean solution' and 'Rebuild solution', it should always work.
It looks like this is a common issue, as yet unresolved.
One of the comments in the above thread suggested that the problem can occur if you've only changed C# code, and unless you also "touch" one of the xml or axml files then the latest version won't be deployed. This seemed to do the trick in my case but it could have been a coincidence - Xamarin seems to be a temperamental beast, and will randomly fail to build or deploy on occasion, perhaps depending on the wind direction, or colour of my underwear that day.
I'm still in the early stages of learning Xamarin/Android, but if I don't enjoy the experience then I'll be jumping ship to Android Studio (although I'd prefer to stick with C# if I can).
I am working on grails 2.0.4 project and at some point I've found that recompilation process does not work. Further tries showed that first run-app after removing ~/.grails/2.0.4 has recompiling process working well, but running run-app next time ignores changes in files during run (no changes on pages and no Compiling… message in log after appears). So my question is how to debug recompilation process?
There's some JIRA issues related to the recompilation:
http://jira.grails.org/browse/GRAILS-8951
http://jira.grails.org/browse/GRAILS-8573
http://jira.grails.org/browse/GRAILS-8914
Only the third one is fixed. Looking in the first, some folks said that this not work:
grails run-app
But entering in the interactive mode works:
grails
run-app
Looking a bit in the code, I can see that GrailsProjectWatcher.java is responsible for file changes. Try to add debug to the related package and see if you get messages.
If it's one particular class that's not reloading, one thing you can check is that the package definition is correct. Grails will happily compile a class that is in the wrong package, but this breaks the reloading mechanism.
This bug or my lack-of-knowledge or smth else is really starting to bother me. I am working on a Grails app and randomly in the middle of my work, grails with complain about some import, saying that cannot resolve the class name. It was working one save ago! I havent changed anything to the infrastructure of the project. I've just written more code. the bothering part is that the app still runs fine, it's just that it has two tagging Xses and every time I start it, I need to press "proceed with errors". I have to refactor the class names to smth else and then back again to the original name. that fixes it and takes a lot of time. Am I missing smth here?
From your comments under the question seems like you are using Eclipse or STS. If that is the case then I was experiencing the same problem with older versions of STS or to be more precise with older versions of Groovy-Eclipse plugin.
I think I haven't seen that happening since STS 2.7 (I'm now using STS 2.8 with Groovy-Eclipse 2.6), so try upgrading. It's IDE bug not the Grails problem itself (at least it was in my case).
Help! I'm porting a large ruby app to Grails - but the Grails startup of my application takes more than 2 minutes.
I've already set dbCreate to "read" I've ensured my high end dual processor desktop windows box gives Grails needed RAM (1 Gig). I have no plugins installed. I have 170 domain classes that used to be ruby classes.
When it starts up it prints out the line "Running Grails App.." and then hangs for a long time before it then prints out the "Server running" line.
I just did something where I migrated all my ids to bigints. That seems to have worsened the problem. Now it takes about 10 minutes to startup.
I am new to grails would you please give me a few more details on what and where to log the events at startup? As to profiling the vm, its been a few years since I did a lot of Java. What do you recommend as the best profiling tool to use now?
What else can I do to speed up Grails startup?
Unfortunately, I am not sure too much can be done beyond what you already did. As you know, there is a lot going on when it starts up, with all the plugin resolution / loading, adding dynamic methods to your domain objects, and overall dynamic nature of Groovy.
I am not sure which version you are using, but I've asked for ability to turn off dependency checking when you start up in 1.2, since that adds a bunch of time to startup time as well.
I realize above isn't too helpful, so perhaps this will be: I split up my application into several plugins. One for domain objects, one for graphing capability, one for excel import, another for some UI constructs I needed. I didn't do it just because of slow startup times, but the advantage is that I can test parts of the system separately from each other before integrating everything together.
I am about to add a piece of new functionality that involves at least 10 new domain objects, and I am first developing them in a separate plugin by having stubs for the few objects they have to interact with from the core app. That allows me to both reduce startup times, and also have my code better isolated.
So if it's an option for you, try to separate out things so you can work on them separately, which will alleviate your issue somewhat. There may also be other benefits in terms of having your team work on smaller components separately, better modularization, etc.
Hope this is helpful.
170 domain classes is fairly large, but 2 minutes still seems really long to me. Do you have a ton of plugins installed? Potentially too verbose debug settings?
I'd be curious how long it took if you created a fresh grails app, copied in all of your domain objects (and the subset of plugins that the domain objects might need to actually operate) and see how long that takes to start.
Jean's suggestion about separating things out if possible is a good one. I've done something similar on previous projects where we have a domain plugin, and our other apps all rely on that domain plugin.
You could also use the grails events to log some timing information on start up to see where your bottlenecks are. Timing the "PluginInstalled" event should be good as I think that the hibernate plugin would be caught by this in addition to the other plugins.
You may have a dependency problem. If a plugin you use relies on a library in maven that has 'open ended' dependencies, grails will go and look each time if there are newer versions to download in the range. I have no idea why anyone would specify it like this. It seems it would lead to unreliable behaviour. For me, the culprit is Amazon's java aws library, naturally used by a plugin that talks to Amazon's cloud.
http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10
note how some of its dependencies are like this
org.apache.httpcomponents httpclient [4.1, 5.0)
it appears that every time, grails is looking for a newer version (and downloading if it exists, I just noticed 4.2-alpha1 of httpclient come down when I ran this time).
By removing that dependency from the plugin and manually adding the required libraries to my .lib folder, I reduced my startup time from >30sec to <1sec
You might want to see if there are other knobs you can turn other than Grails in order to fix this.
Have you tried approaching this as a performance issue? You can a look at the box performance and try to find out what the bottleneck is. Is it CPU? Is it a disk read issue? Can you attach a profiler to the VM and find out what's using up most of your startup time?
Have you tried basics like these for further deployment to a servlet container of your choice or in-place .war bootstrapping?
grails -Ddisable.auto.recompile=true run-app
grails run-war
grails war