New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extensibility #237
Extensibility #237
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
I think the Travis failure indicates that you need to merge in recent changes. |
*/ | ||
public interface AutoValueExtension { | ||
|
||
public interface Context { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The public modifier is redundant.
Conflicts: value/pom.xml
@eamonnmcmanus I think this is in a good state to check out. To see an example of a working extension implementation, check out my auto-parcel code. I'm still having a problem with my Parcelable extension in that the annotated class has to implement the Parcelable interface, but AutoValue takes the |
* An AutoValueExtension allows for extra functionality to be created during the generation | ||
* of an AutoValue class. | ||
* | ||
* Extensions are discovered at compile time using the {@link java.util.ServiceLoader} APIs, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you insert a <p>
at the start of the first line of each paragraph here (except the first)? Like this:
* <p>Extensions are discovered...
Sorry, I guess I didn't comment when those were resolved, but they should all be resolved in the commits from that same day. |
OK, I'll take a look later today. Sorry about the misunderstanding. |
@@ -0,0 +1,40 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this?
I'm expecting @cgruber to make a PR shortly that will export Google's internal changes. Merging with those changes won't be too hard, I hope, and after that I think we should be good to go. |
Changes are in. I think that erroneous empty file is the result of a test and was added through a careless |
Regarding the erroneous file, it must have been created by AutoAnnotationCompilationTest. That creates the file using File.createTempFile — is it possible that your system creates temporary files in the current directory?? |
That's certainly possible. My system is a Mac, I haven't tested the default File.createTempFile functionality there. |
Meanwhile we're running into issues merging in the latest Google changes. Those changes are unfortunately more extensive than I thought, so you might be in for a bit of merging work when they go in. I'm reluctant to merge this PR first, though, for fear of making that other merge even worse. |
Could you resolve the merge conflicts? Then I'll have another look. Hopefully Travis issue travis-ci/travis-ci#4621 will be solved soon so we'll be able to get a correct indication of test status. |
Conflicts: value/src/main/java/com/google/auto/value/processor/AutoValueProcessor.java value/src/main/java/com/google/auto/value/processor/BuilderSpec.java
Merged and passing tests locally. |
@eamonnmcmanus Does that bug cause Travis to hang? Shows that it's still building after 5 hours. |
Seems Travis has been very slow of late. I waited about as long as that yesterday for a build. |
Looks like Travis is back up and all checks pass. |
Add an initial version of the Extensibility API to AutoValue.
Thanks for your patience with this! |
Thank you both this CR is well worth the wait! |
@frankiesardo are you able to obtain the same results with this as with your |
I pushed a branch that uses the new Extension api. So far so good. The only problem is related to the Parcelable interface method Forcing the user to implement it, even if it's a simple method, it's an annoyance. Not sure if AutoValue can do something about it. |
In #202 you mention briefly the possibility for an extension to claim a list of abstract methods. That would be helpful in this case. |
I'm working on that. On Tue, Aug 11, 2015, 3:36 PM Frankie Sardo notifications@github.com
|
Add an initial version of the Extensibility API to AutoValue. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=100543793
*** Reason for rollback *** Google's internal test rig detected substantial numbers of failures, and so this commit was auto-rolled-back. *** Original change description *** Merge pull request #237 from rharter/extensibility Add an initial version of the Extensibility API to AutoValue. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=100545729
*** Reason for rollback *** Re-attempt original commit, but with internal build fixes to avoid sending the SPI code to android builds, where javac/javax types don't exist. *** Original change description *** Automated g4 rollback of changelist 100543793. *** Reason for rollback *** Many tests lost their lives securing this commit. *** Original change description *** Merge pull request #237 from rharter/extensibility Add an initial version of the Extensibility API to AutoValue. *** ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=101824430
This is a first pass implementation of issue #202, providing two options for extending AutoValue through the use of compile time plugins.
The first method, is by having your extension create an intermediate class between the abstract template class and the final AutoValue implementation of the class. The provides a good mechanism for adding functionality to an AutoValue class, while still keeping the implementation segregated.
The second method is to alter the final AutoValue class itself. This was required to support Android Parcelable implementations, as Parcels are required to have static factory objects, and this isn't achievable via inheritance. Using this method, extensions have to option of adding imports, interfaces and code to the resulting AutoValue class implementation. You can see a working example of one such plugin here.
You can view a test Android app that makes use of the auto-parcel extension here.