On 08/27/2015 11:03 PM, Dave Borowitz wrote:
> Following up the discussion on
>
https://gerrit-review.googlesource.com/70409 in a separate thread.
>
> > However, the Eclipse build has stopped working with:
> >
> > AutoValue_LabelVote cannot be resolved to a type
> >
> > in LabelVote.java.
> >
> > I've bisected it to this commit, but haven't investigated what
> > actually causes it yet.
>
> If do a full clean/rebuild and then look in your error log (Window ->
> Show View -> Error Log), you should see a series of errors starting with:
>
> Could not write generated class com.google.gerrit...AutoValue_...:
> javax.annotation.processing.FilerException: Source file already created:
> /gerrit/.apt_generated/com/google/gerrit/...
>
Yes. I didn't have that view open by default; I was only looking at the
console log.
> This comes from:
>
https://github.com/google/auto/blob/master/value/src/main/java/com/google/auto/value/processor/AutoValueProcessor.java#L742
>
> An internal mailing list discussion tells me that the linked Eclipse bug
> was fixed in such a way as to make that workaround insufficient. The
> problem has to do with the Eclipse batch compiler splitting up calls to
> the annotation processor if the number of source files in the project
> exceeds a certain threshold, by default 2000 files. Coincidentally,
> Gerrit has about 2200 .java presently.
>
> You should be able to increase the batch size of the project by adding
> the following under -vmargs in your eclipse.ini:
>
> -DmaxCompiledUnitsAtOnce=10000
>
I can confirm that this fixes it for me (Eclipse 4.5 on Ubuntu).
> I think the reason us Googlers weren't seeing this before is that our
> internal projects often contain very many class files, to the point
> where the internal Eclipse package distribution has this property bumped
> way up by default.
>
>
> If this workaround works, we at the very least need to document it, but
> it's still an annoying hassle as part of Eclipse setup.
https://gerrit-review.googlesource.com/70494
> Absent an
> upstream fix, which doesn't seem to be immediately forthcoming, there's
> not really a whole lot we can do other than drop AutoValue support
> entirely.
Adding a line to eclipse.ini is a minor inconvenience and I don't think
it justifies reverting the AutoValue changes.