Bug 54583 - When running <javac> with <compilerarg line="proc:only"/> package-info.class files are still generated
Summary: When running <javac> with <compilerarg line="proc:only"/> package-info.class ...
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.9.1
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-19 18:57 UTC by jgeorgeson
Modified: 2013-05-22 03:38 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jgeorgeson 2013-02-19 18:57:57 UTC
We have a number of processor-only <javac> tasks, but that is specified as a compiler arg as there's no attribute for this setting. With 1.8.x the <javac> task now generates empty package-info.class files if the compiler didn't, but if we're running processor-only, no class files should be generated. I can workaround it by adding a destdir attribute on the affected <javac> calls, but natively recognizing this compiler argument to disable package-info.class generation would be preferred.
Comment 1 Stefan Bodewig 2013-03-03 10:15:40 UTC
Doesn't it work if you use createMissngPackageInfoClass="false"?

I'm a bit reluctant to adding special handling for the proc flag when there may be other args that would also have an effect and createMissngPackageInfoClass has been introduced just for cases like yours.
Comment 2 jgeorgeson 2013-03-13 20:01:11 UTC
That option does work for us. When I searched the Ant manual I was looking for processor related options and completely glossed over this one. However I still think it would be nice to not have to specify both. The javac compiler invoked directly with -proc:only doesn't produce class files, so it's counter-intuitive to have to remember this individual case.
Comment 3 Jesse Glick 2013-03-13 20:17:28 UTC
Agreed with reporter that <javac> should try to follow CLI javac’s behavior unless there is a reason to differ.
Comment 4 Stefan Bodewig 2013-03-14 08:02:02 UTC
Well, my reason would be that we'd have to understand several compiler args by several compilers to ensure we do the right thing.

That being said, I certainly won't block anybody who'd attempt to implement such logic ;-)