I'm new to grails and came across an issue of grails shell not recompiling my classes even though displaying a message about it. Here is what I'm doing:
I have a grails 2.0.0 app that has class with certain static methods
I would like to test some of the functionality from grails shell, so I go ahead and launch it from the grails project folder as grails
shell
I'm calling a static method of the class to perform some work as follows:
import com.mypackage.*
MyClass.doWork()
If I'm seeing some unexpected behavior or runtime error I'm modifying the source code accordingly and grails shell shows it actually is seeing the change: |Compiling 2 source files.
Then I run the method, but it's seems that the method is the same, because it gives me same error even though I'm sure I've saved the groovy file.
So, I have to exit the shell and launch it again. Then grails picks up the changes.
What I'm doing wrong? It seems to be rather weird expected behavior...
Only run-app enables reloading by default. Run grails -reloading shell to reload changed files. I'd use the console though - it's way more user-friendly: grails -reloading console.
Related
Having trouble getting a android compile of a libgdx project to see classes in a .jar file of mine.
From reading around it seems(?) all I should have to do is put them in the /libs directory and ensure the gradle build file has been set to pick them up.
This doesn't seem to be working for me.
See screenshot of mysetup:
Notes;
SSS.jar is file containing my classes
I have configured everything to use Java 1.7 (this needs to be done each gradle refresh, as gradle insists on setting it to 1.8 for some reason)
Android 4.4 for export, the device testing uses 6.0
I have refreshed/cleaned/built more times then I can count ;)
Desktop compile of the project works fine
The error I get when running as android application is as follows;
04-29 19:58:10.462: E/AndroidRuntime(9306): java.lang.NoClassDefFoundError: com.darkflame.client.semantic.SSSIndex$1
04-29 19:58:10.462: E/AndroidRuntime(9306): at com.darkflame.client.semantic.SSSIndex.<clinit>(SSSIndex.java:504)
....(can post more if needed, but I think thats the relevant bit)
(I also tried exporting a .apk and looking inside with 7zip to try to see if the SSS.jar was exported, but to be honest I don't know what I am looking at. How would I tell ?)
Any pointers on how this setup should work would be appreciated.
I have been writing grails applications on Windows, and when I am editing the .groovy files and save they are automatically compiled while the application is running and the changes are available without restarting the app. On OSX this is not happening, in neither interactive mode or by starting the application with grails run-app.
Looking up online I couldn't find a reason for this, and also I know other people working on OSX where this feature works.
Any suggestions as to what might cause this?
Grails 2.3.7
OSX 10.9.4
Java 1.7.0_55
If you are not running in forked mode, you will need to specify the -reloading explicitly.
Starting at some point, the initial JVM has reloading disabled and forks a new JVM with options specified in the grails.project.fork = [...] in BuildConfig.groovy.
As an alternative to passing -reloading each time, you can also modify the startGrails script included with the distribution and change the following option to false:
DISABLE_RELOADING=false
For me, the startGrails script is found in the GVM directory at ~/.gvm/grails/2.3.11/bin/startGrails.
I just migrated an older OSGi project to the current equinox version (Kepler SR1). When using the gogo console I encountered a problem when starting the gogo bundles with start level 1 (that's what I usually do with all relevant framework bundles). The gogo console won't startup though all four bundles are active and running. Typing help would result in a NullPointerException. The solution is to start all gogo bundles with the default start level. Did I miss anything or is this just a case of bad design of the bundle lifecycle? Bundles should not depend on start levels in order to work.
Mike
It's possible to run Equinox and have all bundles started with a start level of 1. Using the following start configuration works as expected:
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -console -clean"/>
<stringAttribute key="target_bundles" value="org.apache.felix.gogo.command#1:true,org.apache.felix.gogo.runtime#1:true,org.apache.felix.gogo.shell#1:true,org.eclipse.equinox.console#1:true,org.eclipse.osgi#-1:true"/>
Bear in mind that Eclipse caches a lot of stuff with its product launches, and very often errors can creep in by virtue of the fact it doesn't get rid of the workspace between launches. This can sometimes cause errors like the one you've seen above. You can delete the launch configuration which will also clean the associated folders, then add it back in again afterwards.
To verify that this works as expected, create a new runtime configuration as an OSGi Framework and add the four bundles, with the start level 1 and autostart true.
Note that the org.eclipse.osgi bundle is the framework bundle, and should have a start level of -1 to indicate the default; perhaps that is the problem you're seeing.
I found the reason for the exception:
We are using some old style CommandProviders. There seems to be a bug in the equinox.console bundle when printing the help for the legacy commands. The set of legacyCommandProviders in the class org.eclipse.equinox.console.commands.HelpCommand seems to contain null-entries (for whatever reasons) which lead to the exception. This only occurs sometimes. Seems we need to convert our legacy commands... :-(
Ok, so I've got a grails app here.
On a previous project we used cucumber alongside grails with our step definitions working in ruby.
It was ok, but it would be nice if we could write our defs in groovy, same scripting language we're using everywhere else.
If anyone's ever done it before, or knows how I could get it running, let me know. I've seen a few plugins that don't appear to work with 1.3.7
Is there not some way for me to just put jruby, cuke4duke in the BuildConfig dependencies and just write a scripts/Cucumber.groovy to invoke it?
https://github.com/thetrav/grails-cucumber
Looks like someone else had already built a cuke4duke plugin, my modification causes it to fail on errors and allocates a large permgen space for it to use.
We're now using groovy step definitions (just put .groovy files in ${project_root}/features/step_definitions) and geb to drive the browser, all seems to work ok
I've been using Scala 2.8RC1 and Scala Eclipse plugin for 2.8 RC1 happily for a few days. However, last night after adding a couple jar files to my environment (apache http client jars) the debugger just stopped stopping at breakpoints in scala code.
Java code stops fine at breakpoints. I tried creating a new mimimal scala app breakpoints don't stop. I've tried switching to sun-jre-1.6.0.20 from the openjdk-1.6.18 I had been using. I've switched to the scala 2.8 nightly and also eclipse plugin for scala nightly builds. No luck.
I would greatly appreciate ideas for fixes. Rather frustrating as the initial experience with 2.8 was really great.
https://www.assembla.com/spaces/scala-ide/tickets/2731-breakpoints-against-objects-in-default-package-are-not-honoured
Says that scala eclipse plugin doesn't stop at breakpoints if you're class is in the default package (no package)
Adding a package and moving my class to it - make the debugger start working again.
It's possible that you've discovered a bug in the Scala tooling for Eclipse. The best place to take the issue is the scala-ide-user list here,
http://groups.google.com/group/scala-ide-user
If you're already sure that you've found a bug you can find instructions for opening a ticket here,
http://scala-ide.assembla.com/wiki/show/scala-ide/Bug_Reporting
I've just encountered this problem. Code is not in default package. I'm getting a warning about missing line numbers, but apparently that bug has been fixed and I can ignore the warning, per https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000155-its-impossible-to-add-line-numbers-debug-info-to-compiled-project#/activity/ticket:
It did seem to stop at breakpoints in the main file, though.