0

I am creating an Annotation Processor in Java and I want to be able to check if the user triggers a full rebuild. I want to be able distingush between a full rebuild and just building a few files.

Is this possible? Or are there any workarounds for this?

Edit1:

I am going to explain what I want to achieve. I have an annotation processor and 10 annotations. 8 of these Annotations generate a config file called plugin.yml. 3 of these annotations (one annotation is used in both processes) are used to generate a sourcefile called AutoRegister.java. This works like a charm when I trigger a full rebuild and all my annotations get processed. Now the problem arises when I only compile, lets say 3 of the 15 classes using my annotations. Then the plugin.yml and the AutoRegister.java get generated based on the Annotations of the 3 files, thus beeing incomplete.

My workaround is to create a cache file, which contains information about all the other classes, which need to be insertet to the two files plugin.yml and AutoRegister.java. This somewhat works but makes it impossible to remove data from the cache, for example when I remove an annotation from a class. So the only way to remove data from the cache is to remove the cache file and to trigger a full rebuild.

derteufelqwe
  • 113
  • 2
  • 9
  • 1
    The API doesn't provide that. Why would you care? Annotation processors are meant to produce additional sources and not do anything else. If you stay within those restrictions, you shouldn't care about what kind of build it is. – Joachim Sauer Dec 16 '19 at 13:29

1 Answers1

1

I don't think the term 'workaround' means what you think it means. If there was a way to distinguish, that would just be 'the answer', not 'the workaround'. If you elaborate on WHY you need this, perhaps a different solution is available, that is NOT directly detecting 'full rebuild' versus 'incremental build', which nevertheless is sufficient for your needs. That'd be a workaround, but you'd have to explain why you need it in order for us to try to help you out.

Here's the most common reason I can think of for why you need this:

Let's say your AP will scan all source files, and distill some sort of list from it. For example, all classes that implement com.derteufelqwe.MyAwesomeInterface. Then, it writes this list someplace. Say, META-INF/services/com.derteufelqwe.MyAwesomeInterface. The problem is: During incremental builds, you only see a subset of all sources, therefore the list is incomplete, then you write it where ever it needs to be written and now you have a broken list (as it is incomplete).

The fix for this is that you can ask the Filer for a source file or class file; even if it is not part of the compilation run it is still on the source path or class path and you get a result. Thus, IF you can read the existing list, and you can extract, per entry, the source or class file that is responsible for it (which in our hypothetical case where you are creating a services file, is trivial: The very entry is itself a fully qualified class name you can ask the Filer to find) you can then query the filer if that resource is still around. If yes, keep it, if not, delete it. Now you can update (instead of regenenerate and replace) your list.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72