In my groovy file, I have a groovydoc link that looks like:
/**
* This links to {#link MyClassInSamePackage}
*/
def myMethod() {
}
Because the class of myMethod is the same package as MyClassInSamePackage, this should work, but it doesn't generate a link in the docs, rather it surrounds it in <code> tags. I have recently opened https://issues.apache.org/jira/browse/GROOVY-5957, but according to https://issues.apache.org/jira/browse/GROOVY-3745, it looks like this issue should be fixed (I'm using groovy 2.0.5).
Can anyone confirm (or refute) whether or not links in the same package work properly in groovydoc if the full package name is not used?
I'm using Grails 2.2 with Groovy 2.0.5 and I see the same behaviour, except that it seems that GroovyDoc's function of creating #link tags, as well as #see tags is unpredictable and sometimes its working - sometimes it's not.
It could also be a bug within my IDE (IntelliJ IDEA 12.0 Ultimate - 30 Days Trial Version), but if you see this behaviour too, maybe it's some bug within Groovydoc?
Which IDE do you use?
Related
I am currently upgrading a module that uses setContent(), that used to be available for JournalArticle (package com.liferay.journal.model) in 7.3.
I checked the guidelines at:
https://learn.liferay.com/dxp/latest/en/liferay-internals/reference/7-4-breaking-changes.html
But I could not find a direct replacement, or anything about its removal.
Did I miss something in the breaking changes documentation?
I also checked the github repository, and the method that was on 7.3.x does not seem to be present in 7.4.x.
This is one of the classes I checked when I first noticed the method was gone:
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-service/src/main/java/com/liferay/journal/model/impl/JournalArticleModelImpl.java
I also checked the public api at for JournalArticles, as in:
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-api/src/main/java/com/liferay/journal/model/JournalArticleModel.java
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-api/src/main/java/com/liferay/journal/model/JournalArticle.java
To give a class multiple build macros, I previously stacked #:build() tags. I updated to dev haxe, and now it's only recognizing the last tag. Was the syntax for this changed recently, or is this a bug?
#:build(Macros.thisMacroDoesntRunAtAll())
#:build(Macros.thisMacroWorksNormally())
class Test {
I don't remember what dev version of haxe I used to be on, but it was after the 3.2.0 master release.
It's a haxe bug, and it seems like Simon is aware.
Oh well.
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}
I'm trying to adapt Ravi Tamada's blog entry to Mono for Android.
But at the 6. step i stopped. How can i specify
<!-- Your package folder -->
<com.androidhive.dashboard.DashboardLayout ...
attribute, at fragment_layout.xml file?
I try to give a package name specified at Xamarin solution or specify my VS2010 namespace at java form (MySolution.MyProject.MyFolder.DashboardLayout -> mysolution.myproject.myfolder.DashboardLayout) but result is same error:
Design mode gives following: "the layout could not be loaded: com.android.layoutlib.bridge.mockview cannot be cast to android.view.viewgroup"
The question is, how can i use my DashboardLayout.cs (ViewGroup) class as attribute like Ravi Tamada's java example. (6. step)
Thaanks.
Unfortunately, this is a bug in Mono for Android/the Designer and is already filed on Bugzilla here: https://bugzilla.xamarin.com/show_bug.cgi?id=7680
Hopefully this will be fixed soon, you can CC yourself on the bug so you can updates when anything changes.
I know that since Groovy 2.0 there are annotations for static compilation.
However it's ease to omit such annotation by accident and still run into troubles.
Is there any way to achieve the opposite compiler behaviour, like compile static all project files by default and compile dynamic only files chosen by purpose with some kind #CompileDynamic annotation for example?
I have found some (I believe recently introduced) feature which allows doing so with Gradle.
In build.gradle file for the project containing groovy sources we need to add following lines:
compileGroovy {
configure(groovyOptions) {
configurationScript = file("$rootDir/config/groovy/compiler-config.groovy")
}
}
or compileTestGroovy { ... for applying the same to test sources. Keep in mind that neither static compilation nor type checking works well with Spock Framework though. Spock by its nature utilizes dynamic 'groovyness' a lot.
Then on a root of the project create folder config/groovy/ and a file named compiler-config.groovy within. The content of the file is as follows:
import groovy.transform.CompileStatic
withConfig(configuration) {
ast(CompileStatic)
}
Obviously path and name of the configurationScript may vary and it's up to you. It shouldn't rather go to the same src/main/groovy though as it would be mixing totally separate concerns.
The same may be done with groovy.transform.TypeChecked or any other annotation, of course.
To reverse applied behaviour on certain classes or methods then #CompileDynamic annotation or #TypeChecked(TypeCheckingMode.SKIP) respectively may be used.
I'm not sure how to achieve the same when no Gradle is in use as build tool. I may update this answer in the future with such info though.
Not at this time, but there is an open Jira issue here you can follow to watch progress for this feature
There was also a discussion about methods for doing this on the Groovy developers list