maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Svensson <to...@natusoft.se>
Subject Re: Maven bug in conjunction with annotation processing ?
Date Sat, 20 Jul 2013 14:06:48 GMT
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 <tommy@natusoft.se>:

> 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 <tommy@natusoft.se>:
> 
>> 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 <russ@gold-family.us>:
>> 
>>> 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 <tommy@natusoft.se> 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 <russ@gold-family.us>:
>>>> 
>>>>> 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 <tommy@natusoft.se>
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: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> 
>>>>> 
>>>>> -----------------
>>>>> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>> 
>>> -----------------
>>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message