I have solved the problem! Well, … not exactly! I have found a solution to the
problem!
If you se the output in my previous mail:
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile)
@ repoman-service ---
I was using version 3.1 of the maven-compiler-plugin. I downgraded to version
2.3.2, and now everything works perfectly!
I'd say that there is a bug in version 3.1.
And now again I'm asking myself "Why wasn't that the first thing I tested ?" :-)
/Tommy
20 jul 2013 kl. 15:19 skrev Tommy Svensson <[email protected]>:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
