Dagger 2 compile time error on CI - jenkins

I've been using Dagger 2 recently and just did some work with scopes in my android project, adding scopes for Activities. While everything runs, builds and tests fine on my own machine. I'm getting a compile error on Jenkins CI.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':Adverts:compile***DebugJava'
.java.lang.ClassCastException: java.lang.String cannot be cast to javax.lang.model.type.TypeMirror
This is strange because the build has worked fine up until now with Dagger 2 just with less code being generated. When I navigate to the generated sources some, but not all of the code is generated. It looks like it's crapping it out somewhere along the way. Both CI and my machine are using the same version of JDK.
Has anybody ran into issues with CI & Dagger 2 before?

For people in the future who encounter this error as well, it's most likely because of a class you deleted or a class that doesn't exist that is being referenced in your Module.
I had the exact same error while compiling when I had code like this:
#Module(includes = {
AModuleThatDoesntExist.class
})
public class YourModule {
}
So what I'm saying is: if you encounter this error, check your Dagger modules and bootstrapper code, there's probably some invalid code there.
As to why it works on your machine and not on the CI server: I don't know. I would guess it's because of some cache issue where the .class file of your deleted .java file is still present on your local filesystem, so Dapper can find it, but it doesn't exist on your CI server. If you can still reproduce the issue, maybe you can try running "Rebuild" and see if the errors occurs locally too.

Whatever happens Dagger 2's annotation processor shouldn't throw an exception so assuming that is coming from the Dagger 2 annotation processor it might be worth raising a bug if you can create a reproducible example, preferably a simple one.
As others have suggested do a clean build (remove the classes yourself to make sure that they are all gone) and check for differences between your machine and the CI one.

Related

How do I write a Logary target for my .NET application?

I am trying to get started with Logary. I need to write a new target and I have tried following the following tutorial https://logary.tech/tutorials. I have downloaded Logary.sln from https://github.com/logary/logary, but I am not able to build Logary.sln. When I build it I get 40 errors and all of them say: The command ""paket.exe" restore" exited with code 9009.
When I try to add the nuget Logary (latest 5.0) with NuGet manager I get NU1108: Cycle detected. Logary -> Logary (>= 5.0.0).
When I try following this https://logary.tech/logary-dotnet-quickstart I get 2 errors as well.
So, I am totally lost. What am I missing out? I will provide more information if necessary. I want to write a target in F# for my .NET application that would be sent as an event to Logary's centralised event storage.
I have used FAKE build and it worked OK. The problem was cause by some namespaces, which is fixed in the fake.
I seems that the problem is with the project name. Its name is the same as the referenced NuGet package. So to resolve this problem you should changed the project name and the build will succeeded.

Umbraco unit tests failing

I am trying to follow Jorge Lusar's suggestion on unit testing Umbraco. I could not get GetRoutingContext method to work because the Umbraco.Web.Routing.UrlProvider constructor is getting a null reference exception (I had downloaded an umbraco 7.0.4 installation previously and compiled the Umbraco.Tests.dll).
As I was getting out of options, I decided to download a fresh copy of Umbraco, compile and run a test that would execute the UrlProvider constructor. To my surprise, I got the null reference exception in there too so apparently, this bug has nothing to do with my solution but Umbraco's instead.
The images speak for themselves. Can anyone plase help with this? Is this really a bug or there's something I can do here?
The solution to the problem was to copy the config settings (the ones in the UnitTests project of the Umbraco solution) to my test project.
Umbraco is dependendant on config files. Not ideal for unit tests but it worked.
Here it is explained how to stub Umbraco dependencies.
Checking over a web.config for a current v7 site I've been working on, the umbracoConfiguration/settings section is of type Umbraco.Core.Configuration.UmbracoSettings.UmbracoSettingsSection.
Another thing you're doing wrong is using as IUmbracoSettingsSection. As means if the cast fails you return a null object, rather than an exception telling you the cast failed - it fails silently. It is better to do:
var umbracoSettings = (IUmbracoSettingsSection)ConfigurationManager.GetSection("umbracoConfiguration/settings");
As mentioned, I think your base type is wrong, and you should actually use:
var umbracoSettings = (Umbraco.Core.Configuration.UmbracoSettings.UmbracoSettingsSection)ConfigurationManager.GetSection("umbracoConfiguration/settings");
This should cast the section into the correct type for you.

"Groovy:unable to resolve class ..." (import error in LoginController.groovy)

I am trying to use the ":spring-security-core:2.0-RC2" (using Grails version 2.3.1), but have my own LoginController.groovy. Following Burt's notes (here and here), I copied the LoginController.groovy from the original location at "myapp\target\work\plugins\spring-security-core-2.0-RC2\grails-app\controllers\grails\plugin\springsecurity" to my project location at "myapp\grails-app\controllers\com\company". Now I get a bunch of import error messages like "Groovy:unable to resolve class ..." (I have attached am image below showing all the imports giving errors). How do I take care of these errors?
Sorry if this is a trivial question (still getting used to Grails), and thank you for the help!
It looks like GGTS/STS isn't entirely aware that the plugin is installed, since those classes are from the two jars that the plugin depends on. Try right-clicking the project node in the tree and running Grails Tools > Refresh Dependencies. If that's not enough, run Project | Clean to force a full recompile.

Two project's, one compiles, the other gets error: package javax.servlet.http does not exist

I know this is a common question, however my situation is a little different. I have two projects, the first doesn't use beans, the second does.
So when deploying the first project using: ant deploy-web it works, compiles no problem
When deploying the second project using: ant deploy-ear I get: error: package javax.servlet.http does not exist
Any ideas?

Grails compiler keeps running again and again, possibly because of syntax error

I got this problem several times: Sometimes when I command : grails run-app, the compiler just running again and again, even though I change nothing after that. It looks like:
Running Grails application..
Server running. Browse to http://localhost:8080/LiningTest
[groovyc] Compiling 1 source file to E:\workspace\W1\LiningTest\target\classes
[groovyc] Compiling 2 source files to E:\workspace\W1\LiningTest\target\classe
s
[delete] Deleting directory C:\Documents and Settings\Long\.grails\1.3.6\proj
ects\LiningTest\tomcat
Running Grails application..
Server running. Browse to http://localhost:8080/LiningTest
[groovyc] Compiling 1 source file to E:\workspace\W1\LiningTest\target\classes
[groovyc] Compiling 2 source files to E:\workspace\W1\LiningTest\target\classe
s
[delete] Deleting directory C:\Documents and Settings\Long\.grails\1.3.6\proj
ects\LiningTest\tomcat
Running Grails application..
Server running. Browse to http://localhost:8080/LiningTest
[groovyc] Compiling 1 source file to E:\workspace\W1\LiningTest\target\classes
...
The compiler succeeded when "Server running", but then it automatically re-compile some files (I don't know which file), and run again, and then recompile again...
I have met this problem once when I have a syntax error
constraint {
number(min:0.50) // the right way is "min: 0..50"
}
The question is why this problem happened, and how I can find the cause of the problem. (I guess that I miss some comma/dot somewhere, but now it's hard to find, because of there's no error message!)
UPDATE: Now I see the problem is that I don't follow the folder structure rules when placing non-domain class in src/groovy.
The first thing to do is to run:
grails compile -verboseCompile
That will at least tell you what the problematic file is.
Apparently this can happen when
The package name does not match the directory (under your source root) the file is in.
The class name is different from the file name.
Have a look at this:
http://www.pubbs.net/201007/grails/58100-grails-user-groovyc-causing-grails-to-loop-.html
And Peter Ledbrook mentioned it in his talk at the Groovy & Grails Exchange last week (at 29:20):
http://skillsmatter.com/podcast/java-jee/talk-by-peter-ledbrook
I can confirm the strange behaviour.
I had two groovy classes in src/groovy belonging to some package com.acme.foobar.
Although for a while all went fine and Grails even compiled the classes and started the application (which was useable without exceptions) - at some point it did not stop to compile, start, delete all over again.
After I put the classes in src/groovy/com/acme/foobar the behaviour stopped instantly.
The remark of using grails compile -verboseCompile was useful. At least you can check if everything is allright as follows:
Call grails compile twice:
If there is the same output of classes being compiled the second time you compile there will be a problem.
If grails splutters something like this:
Running script /Users/ug/Software/grails/scripts/Compile.groovy
Environment set to development
returning to prompt directly afterwards - the problem should be gone.
Ok, it's a strange behavior with Grails that a senior programmer just told it to me:
I put one of my non-domain class in src/groovy/warm.groovy. But the warm.groovy belongs to the package "liningtest". It seems that I must put "Warm" class inside "src/groovy/liningtest/warm.groovy" instead.
There's an implicit rule here:
The non-domain class put in src/groovy, must follow the folder structure that is alike to the package structure.
That's really a strange behavior, because it doesn't report any errors, just repeat compiling again and again... And for the most strange part, that works for me in the first time!

Resources