I have found something interesting, and I think maven is at fault here :-).
I first do:
mvn clean install
this works fine. Then I do:
mvn install
which results in the following output:
…
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
repoman-service ---
[INFO] Changes detected - recompiling the module!
…
Notice the "Changes detected - recompiling the module!". There should be no
changes detected at all there! Here are my source and class files with
timestamps:
Sources:
Tommys-MacBook-Pro:service tommy$ find src -type f -exec ls -l {} \;
-rw-r--r-- 1 tommy staff 399 14 Jul 16:43
src/main/java/se/natusoft/fambda/Fambda.java
-rw-r--r-- 1 tommy staff 2117 14 Jul 17:43
src/main/java/se/natusoft/repoman/Activator.java
-rw-r--r--@ 1 tommy staff 851 10 Jul 17:10
src/main/java/se/natusoft/repoman/config/RepoManConfig.java
-rw-r--r--@ 1 tommy staff 187 11 Jul 18:24
src/main/java/se/natusoft/repoman/repository/RepositoryProvider.java
-rw-r--r-- 1 tommy staff 554 20 Jul 14:30
src/main/java/se/natusoft/repoman/service/model/ChangeSet.java
-rw-r--r-- 1 tommy staff 496 20 Jul 14:30
src/main/java/se/natusoft/repoman/service/model/CMRepository.java
-rw-r--r-- 1 tommy staff 379 20 Jul 14:30
src/main/java/se/natusoft/repoman/service/model/Person.java
-rw-r--r-- 1 tommy staff 240 19 Jul 12:47
src/main/java/se/natusoft/repoman/service/provider/RepositoryService.java
-rw-r--r-- 1 tommy staff 1022 19 Jul 20:31
src/main/java/se/natusoft/repoman/service/provider/RepositoryServiceProvider.java
Tommys-MacBook-Pro:service tommy$ find target/generated-sources/ -type
f -exec ls -l {} \;
-rw-r--r-- 1 tommy staff 564 20 Jul 14:55
target/generated-sources//annotations/se/natusoft/osgi/aps/tools/aps-activator-data
-rw-r--r-- 1 tommy staff 1939 20 Jul 14:55
target/generated-sources//annotations/se/natusoft/repoman/service/model/ChangeSetBean.java
-rw-r--r-- 1 tommy staff 953 20 Jul 14:55
target/generated-sources//annotations/se/natusoft/repoman/service/model/CMRepositoryBean.java
-rw-r--r-- 1 tommy staff 734 20 Jul 14:55
target/generated-sources//annotations/se/natusoft/repoman/service/model/PersonBean.java
Classes:
Tommys-MacBook-Pro:service tommy$ find target/classes -type f -exec ls
-l {} \;
-rw-r--r-- 1 tommy staff 1494 20 Jul 14:55
target/classes/META-INF/MANIFEST.MF
-rw-r--r-- 1 tommy staff 304 20 Jul 14:55
target/classes/se/natusoft/fambda/Fambda$func.class
-rw-r--r-- 1 tommy staff 349 20 Jul 14:55
target/classes/se/natusoft/fambda/Fambda$func1.class
-rw-r--r-- 1 tommy staff 392 20 Jul 14:55
target/classes/se/natusoft/fambda/Fambda$func2.class
-rw-r--r-- 1 tommy staff 435 20 Jul 14:55
target/classes/se/natusoft/fambda/Fambda$func3.class
-rw-r--r-- 1 tommy staff 345 20 Jul 14:55
target/classes/se/natusoft/fambda/Fambda.class
-rw-r--r-- 1 tommy staff 1252 20 Jul 14:55
target/classes/se/natusoft/repoman/Activator.class
-rw-r--r-- 1 tommy staff 1130 20 Jul 14:55
target/classes/se/natusoft/repoman/config/RepoManConfig.class
-rw-r--r-- 1 tommy staff 199 20 Jul 14:55
target/classes/se/natusoft/repoman/repository/RepositoryProvider.class
-rw-r--r-- 1 tommy staff 351 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/ChangeSet.class
-rw-r--r-- 1 tommy staff 1877 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/ChangeSetBean.class
-rw-r--r-- 1 tommy staff 363 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/CMRepository.class
-rw-r--r-- 1 tommy staff 1394 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/CMRepositoryBean.class
-rw-r--r-- 1 tommy staff 339 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/Person.class
-rw-r--r-- 1 tommy staff 865 20 Jul 14:55
target/classes/se/natusoft/repoman/service/model/PersonBean.class
-rw-r--r-- 1 tommy staff 152 20 Jul 14:55
target/classes/se/natusoft/repoman/service/provider/RepositoryService.class
-rw-r--r-- 1 tommy staff 1204 20 Jul 14:55
target/classes/se/natusoft/repoman/service/provider/RepositoryServiceProvider.class
All classes have 14:55 as timestamp. All sources under src/main/java is younger
than that! The generated sources under target/generated-sources/... have the
same timestamp as the classes, which is not that surprising. Recompile should
only be done if any sources are newer, not the same time. So what is making
maven-compiler-plugin think that it needs to recompile this ?
My previous question of what triggers an annotation processor was stupid :-) An
annotation processor is of course always triggered when a source having its
annotation is compiled.
Regards, Tommy
20 jul 2013 kl. 12:31 skrev Tommy Svensson <[email protected]>:
> Hello Russ,
>
> No, the sources are only generated once. I've double checked that. That was
> my first thought.
>
> It just occurred to me that I have a unit test with an annotated model in my
> annotation processor project and it behaves correctly (I just did some
> tests). There the annotation processor is not run if the processed
> annotations have not been modified, which is entirely correct. If I change
> something in the annotation and build again (without doing clean) it
> regenerates and compiles fine without duplicate class exception. The problem
> in my other code where I have the problem is, I just realized that the
> annotation processor is run when it should not be!
>
> When I do "mvn install" and then directly a new "mvn install" nothing what so
> ever have changed in the annotations being processed! Still the annotation
> processor is triggered for some reason in this case! The interesting
> question here is how does the annotation processor framework determine if a
> processor needs to run or not ? It can't have a clue about what the processor
> will be generating, so how does it determine this ? Also, this invocation
> when it shouldn't only occurs when built with maven, but I realize that does
> not necessarily mean that maven is at fault. Hmm. I have some more
> troubleshooting to do here.
>
> /Tommy
>
>
> 19 jul 2013 kl. 18:33 skrev Russell Gold <[email protected]>:
>
>> Hi Tommy,
>>
>> I am not seeing this problem, myself.
>>
>> When you get the duplicate class problem, do you find multiple copies of the
>> generated source in your target directory? Multiple copies of the same class
>> files? AFAIK that is the only way you should ever see a duplicate class
>> exception
>>
>> - Regards,
>> Russ
>>
>> On Jul 19, 2013, at 11:40 AM, Tommy Svensson <[email protected]> wrote:
>>
>>> Hello Russ,
>>>
>>> No, that is not exactly my case. I just tried to build from the IDE to
>>> confirm my suspicion that the problem only occurred in maven. I'm using
>>> Intellij Idea 12 and it is nice enough to recognize that my project is a
>>> maven project. When I tell it to "make" or "rebuild" it does build itself
>>> not using maven, but it uses the same target paths as maven would. It tries
>>> to avoid the problem you describe.
>>>
>>> My problem is that as long as I build with maven I have to do a "mvm clean
>>> install" every time since an "mvn install" … "mvn install" will fail on the
>>> second install with a duplicate class exception for the generated code. As
>>> I said, I suspect that maven have already built the previously generated
>>> classes before annotation procession is run by maven and when the
>>> annotation processor produces new versions of the same classes they are
>>> compiled again and produces exactly the same class file targets as already
>>> produced before during the build. This causes the duplicate class
>>> exception. That is at least my theory.
>>>
>>> /Tommy
>>>
>>>
>>> 19 jul 2013 kl. 17:28 skrev Russell Gold <[email protected]>:
>>>
>>>> Hi Tommy,
>>>>
>>>> I've run into some problems along these lines, but in my case, it only
>>>> happens when I build first using Maven and then try to recompile in the
>>>> IDE. The problem appears to be that the two disagree on where the
>>>> generated classes go (there was a change in one of the JDK releases, I
>>>> believe).
>>>>
>>>> I work around that by doing a clean compile in maven before starting IDE
>>>> work.
>>>>
>>>> Is that your problem? Or are you only seeing this by only doing repeated
>>>> Maven builds? I don't have that problem.
>>>>
>>>> - Russ
>>>>
>>>> On Jul 19, 2013, at 11:22 AM, Tommy Svensson <[email protected]> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have found a problem when using auto triggered annotation processors
>>>>> (META-INF/services/javax.annotation.Processor) with maven builds! The
>>>>> problem occurs when the code have been built once and the annotation
>>>>> processors have been triggered and generated code. If I then build again
>>>>> without doing a clean in between then I get a duplicate class exception
>>>>> for each generated class. I suspect this is because maven have already
>>>>> build the previous versions before annotation processing is triggered and
>>>>> when the newly updated/generated sources are compiled it conflicts the
>>>>> the previous built classes.
>>>>>
>>>>> This problem does not occur when I build in the IDE not using maven. Then
>>>>> the annotation processing behaves as expected. I suspect that if the
>>>>> processor weren't specified in
>>>>> META-INF/services/javax.annotation.Processor, and was run manually with
>>>>> apt-maven-plugin it would work better, but that is not an option. I wan't
>>>>> my processor to be able to be used the standard Java way, and with maven,
>>>>> without having 2 versions of it. I have found a way to identify in the
>>>>> processor when there already are old sources available and don't
>>>>> regenerate then, which will make it run in maven, but will then not
>>>>> update the generated sources without first doing a clean when annotations
>>>>> are updated. This is of course not a good solution.
>>>>>
>>>>> Is there any other known way to solve this problem with maven ? I'm using
>>>>> version 3.1 of the maven-compiler-plugin.
>>>>>
>>>>> Any help is appreciated.
>>>>>
>>>>> Best Regards,
>>>>> Tommy Svensson
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>> -----------------
>>>> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
>>>> and listen to the Misfile radio play
>>>> <http://www.gold-family.us/audio/misfile.html>!
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> -----------------
>> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
>> and listen to the Misfile radio play
>> <http://www.gold-family.us/audio/misfile.html>!
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
