We Keep Coding

SBT: Java Annotation Processors and compileIncremental error

I’m using the immutables.org and mapstruct annotation processors in my sbt project (I've moved them to subprojects, so they don't interfere with each other).
Sometimes, compiling my project fails in compileIncremental because the annotation processor would create a new file, but the compiler already read the previously generated file or I changed my interface in src/main/java but the (previously) generated sources still "implement" the old interface (they would be overwritten, but that happens only after processing the sources in src/main/java).
My workaround was to create a task that deletes the generated sources beforehand for which "(compile in Compile)" would depend on.
Is there another way to do this? like disabling compileIncremental for one single project? or specifying the order of compilation? (like first normal sources, then unmanagedSources)
Alternatively finding out if the sourceFiles really changed and only then deleting the generated sources would also work for me, but I’m not sure how to approach that.
Any help would be greatly appreciated!
Thanks,
Dominik

Writing a maven plugin that reads annotations from source files

My idea is to write a maven plugin that generates code (just simple json) based on some annotations in my Java code. The annotated classes may be part of a used library or in my own code.
What I want is a plugin that gets a fixed set of class names (by configuration in pom). It walks through these classes, searches it for annotations on properties and generates code based on the gathered information.
Is that possible?
How can I achieve this?
Is there an existing plugin that does something like that?

Java autogenerated getters-setters in project - best practice

Our project has started newly and wanted to know some of the best practices followed in industry. We have generated lot of DTOs(getters and setters) code for webservices using JaxB. we keep all the DTO classes along with regular pojos(logic written), its looks like large project due to this auto-generated code, also for code coverage it considers these classes also.
I am keen to know that these classes should be as a jar file in classpath or it should be as classes in project.
Thanks in Advance,
Madhavi

If your project uses Maven (or something similar) I would advise having the code generation and the generated code in a separate module of a multi module project.
This way the generated stuff is out of the way of the hand crafted code. You can also set up your Maven build process to then build this module first and the rest of the code can rely on the resulting artefact, be it a jar or something else.
You could also regenerate the generated code on each new build this way. Although this can be a lengthy process, depending on the service.

Generated files should not be mixed with your written files.
A common approach is to generate them to the target folder, e.g. target/generated-sources or something similiar. Of course, if they are rarely changed, you could also put them in a jar file that you import into your project.

I think its better to keep them in jar. As its auto generated code and no one is supposed to change. Whenever regenerated include new jar.

Proguard issues with jar files, how to find the missing jar?

When I try to export my apk with Proguard I get a lot of errors (over 400) similar to:
Warning: org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper: can't find superclass or interface javax.ws.rs.ext.ExceptionMapper
and
org.codehaus.jackson.xc.DataHandlerJsonDeserializer$1: can't find superclass or interface javax.activation.DataSource
I am using the Jackson Json library, and the errors seem related to that.
Researching this error I found the following from Proguards FAQ:
If there are unresolved references to classes or interfaces, you most likely forgot to specify an essential library. For proper processing, all libraries that are referenced by your code must be specified, including the Java run-time library. For specifying libraries, use the -libraryjars option.
Searching around on SO I found a lot of unanswered questions related to this, but the general sense was that the jar file I am using (in this case Jackon JSON) is relying on more libraries and they need to be added to Proguard's config file some how.
However, I can't figure out how to determine what jars are needed and where they are. The warnings mention a lot of different packages such as javax.ws.rs.ext, org.joda.time, org.codehaus.stax2, javax.xml.stream, etc.
How do I determine what jars contain those packages? For example, what jar is required for the javax.ws.rs.ext.** classes?
How do I figure out where those jars are and what path would be used with -libraryjars in Proguard?
Thanks much
Edit: I should also mention that I am using an Android Library Project setup. The jars are in the main Library project, and the actual working project has their build paths including the jars in the Library project. Don't know if that makes a difference but thought I should mention it.
Update Just to test, I completely removed the jackson far from the build path and from my code and now Proguard completes successfully. The questions still remain... What is the correct approach for handling these errors?
Does the Android export wizard in Eclipse automatically add the /lib/ jars to proguard or do they all have to be added manually in the proguard config file like this:
-libraryjars C:/Project/lib/somjar.jar
I did try that for the jackson one but it didn't make any difference. Does this mean I also have to find all of the jars that are needed for the classes mentioned in the warnings and add those? Would they be in the sdk or in the java installation?
Sorry if these are stupid questions, but I have been trying to figure this out for the last couple hours and have no idea what to do.
Thanks again
Update Again
So more searching, combined with Benjamin's suggestion, I found some of the missing classes were in rt.jar, which is in the jdk's lib folder. So I ended up adding
-libraryjars <java.home>/lib/rt.jar
To the proguard.cfg file and brought the warnings from 485 down to 204. Hey I guess that's something... The remaining warnings describe classes that I cannot find at all. The app works just fine without running proguard, so these classes must be somewhere right? Or are these warnings that I should use -dontwarn with?
The remaining classes are in these packages:
org.joda.time.
org.codehaus.stax2.
javax.ws.rs.
So now I just need a way to figure out:
What jars have these classes
Where are these jars so I can include them in the proguard config file

I've had similar problems with Proguard and similar errors I was using an osmdroid.jar which built OK unobfuscated. This jar must have had external dependencies which my application didn't need. Fortunately the authors listed the jars needed and once I downloaded them and told Proguard via the -libraryjars option, the Proguard build was OK.
Re your missing jars (which you probably don't really need, but Proguard thinks you might!), you should find them at:
org.joda.time
(The jar's inside the zip)
org.codehaus.stax2.
javax.ws.rs.

I only can provide an answer for the first part:
Give
http://www.findjar.com
a try, there you might find the names of the needed jar files
like so

You don't need to include the libraries for Proguard; you need to instead instruct Proguard to keep the class names and some other stuff. I toyed around with it a bit myself, and I ended up with something similar to this discussion:
-keepnames class org.codehaus.** { *; }
-keepattributes *Annotation*,EnclosingMethod
-dontwarn org.codehaus.jackson.**
If you're still experiencing crashes—and I would suggest testing vigorously!—you might want to keep Jackson completely intact with:
-keep class org.codehaus.** { *; }
-keepattributes *Annotation*,EnclosingMethod
-dontwarn org.codehaus.jackson.**
(Note that the latter produces a larger file.)

What Maven XMLBeans configuration must be set to use generics?

There are a few XMLBeans sites that make reference to generated code taking advantage of generics (and enums) however, I can't seem to find the configuration option to set.
Sites mentioning generics in XML Beans:
http://xmlbeans.apache.org/news.html
http://wiki.apache.org/xmlbeans/V2Features
I have set the javaSource configuration to 1.5 but that still isn't causing the generated source to use generics.
(see http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html#javaSource)
Some related Stack Overflow questions:
How to get rid of generics warnings in code generated from xmlbeans-maven-plugin?
How to suppress Java warnings for specific directories or files such as generated code

#artbristol was correct, simply use the 'javaSource' tag.
Looks like we were using 'javasource' (notice case) and that was the problem. When the case issue was resolved, the target directory wasn't being cleaned properly, leaving some legacy Java 1.4 files which was the cause of the compiler warnings.
Thanks!