Skip to content
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

Refactor ProtobufPlugin to support multiple languages #76

Closed
wants to merge 31 commits into from

Conversation

ngyukman
Copy link
Contributor

Added following plugins while keeping the original plugin to determine which to apply

  • com.google.protobuf.java
  • com.google.protobuf.android
  • com.google.protobuf.base

@ngyukman
Copy link
Contributor Author

I didn't run the testProjectAndroid as it fails even after installing android sdk :(

@zhangkun83 zhangkun83 self-assigned this May 30, 2016
import com.google.protobuf.gradle.ProtobufConvention
import com.google.protobuf.gradle.TaskGenerator
import com.google.protobuf.gradle.Utils
import javafx.concurrent.Task
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import by accident?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

likely the usage is removed after some refactoring

@zhangkun83
Copy link
Collaborator

Please provide more details about what this change does, e.g., what languages are supported.

Please note there is an earlier PR (#44) by @Shad0w1nk that will add C++ support. You will likely step on each other. @Shad0w1nk could you comment on the status of your PR?

@zhangkun83
Copy link
Collaborator

I didn't run the testProjectAndroid as it fails even after installing android sdk :(

Were you trying to (or are you going to) port the android test to the new test framework? What error did you get?

@ngyukman
Copy link
Contributor Author

ngyukman commented Jun 7, 2016

Were you trying to (or are you going to) port the android test to the new test framework? What error did you get?

I got error for testProjectAndroid as following

UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
at com.android.dx.command.dexer.Main.processClass(Main.java:704)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673)
at com.android.dx.command.dexer.Main.access$300(Main.java:83)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602)
at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:632)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:510)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:280)
at com.android.dx.command.dexer.Main.run(Main.java:246)
at com.android.dx.command.dexer.Main.main(Main.java:215)
at com.android.dx.command.Main.main(Main.java:106)
...while parsing com/example/tutorial/Msg$1.class

1 error; aborting

:testProjectAndroid:transformClassesWithDexForArmFreeappDebug FAILED

@ngyukman
Copy link
Contributor Author

ngyukman commented Jun 7, 2016

Please provide more details about what this change does, e.g., what languages are supported.

I am looking for implementing C# support onto the plugin, and here is the draft
ngyukman@e26aa8d

Please note there is an earlier PR (#44) by @Shad0w1nk that will add C++ support. You will likely step on each other. @Shad0w1nk could you comment on the status of your PR?

I have notice that and test case refactoring are borrowing the idea from the PR
hopefully we could have the same base for adding new language support

@zhangkun83
Copy link
Collaborator

Googling for "com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)", all results suggest issues with JDK version or compatibility issues. Assuming 0034 is hex, it is 52 in decimal which indicates Java 8. In build.gradle we set targetCompatibility to 1.7. Are you building from IDE which builds 1.8 target? Please try adjusting settings or change the compatibility levels to 1.8 temporarily to see if the problem goes away.

@ngyukman
Copy link
Contributor Author

ngyukman commented Jun 9, 2016

Thanks @zhangkun83, after using jdk 1.7 I could run the testProjectAndroid, moved also the testProjectAndroid as well

@zhangkun83 zhangkun83 mentioned this pull request Jun 9, 2016
@zhangkun83
Copy link
Collaborator

@ngyukman It doesn't seem the android tests are actually being run. If you alter the assertions in the second half of testProjectAndroid/build.gradle to something apparently wrong, ./gradlew test will still pass.

@Shad0w1nk
Copy link

Test project is something I had difficulty in my pull request. Porting them to the TestKit framework will greatly help. With TestKit, you can say which version of Gradle you want to use for the test which would be useful with Android test as the minimum version of Gradle is not the latest. This way you can have the plugin use the latest version but run the test using an older version.

@ngyukman For sure we can sync up on the work. I was moving toward an implementation in the software model for C++ as this is the direction where Gradle is moving. With the model, this limitation (https://discuss.gradle.org/t/limitation-of-generatedby-in-native-software-model/17321) does slow down the pull request a lot.

@ngyukman
Copy link
Contributor Author

@zhangkun83 you are right the test didn't run correctly due to some stupid mistake
It is now running, and the android test failed at some point now :(

@ngyukman
Copy link
Contributor Author

indeed the same issue found in #78

@ngyukman
Copy link
Contributor Author

Unit test can now be ran on travis :)

@zhangkun83
Copy link
Collaborator

Sorry for being slow because I have other work to do. I will review this as quickly as I can. In general I like the new way of doing tests. I will first review the changes in tests, then the changes in the plugin.

The tests are not re-run when any files are changed in the test projects. This is because the test projects directory are not in the transitive inputs of the test task. You would need something like the following in the root build.gradle:

test.inputs.files fileTree("$projectDir/testProject")
test.inputs.files fileTree("$projectDir/testProjectCustomProtoDir")
test.inputs.files fileTree("$projectDir/testProjectDependent")
test.inputs.files fileTree("$projectDir/testProjectAndroid")

// Include test projects only when we intend to run the tests.
// We have to exclude them when we intend to build the plugin, because the test
// projects apply the plugin at evaluation time. At evaluation time the plugin
// has not been compiled yet.
if (gradle.startParameter.taskNames.intersect(['install', 'uploadArchives', 'publishPlugins'])) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was needed because the plugin needed to be installed from a separate command prior to being tested. You can remove it now.

ngyukman added 2 commits June 15, 2016 22:37
Conflicts:
	build.gradle
	src/main/groovy/com/google/protobuf/gradle/ProtobufPlugin.groovy
	testProjectAndroid/build.gradle
	testProjectDependent/build.gradle
- Add test projects to test inputs
- Remove unnecessary settings
@ngyukman
Copy link
Contributor Author

you are right the testProjects are not part of the test source, thanks

'generateX86RetailappDebugProto', 'generateX86RetailappReleaseProto'] as Set ==
protobuf.generateProtoTasks.all().collect({ it.name }) as Set

assert ['generateArmFreeappDebugAndroidTestProto',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not common to use assert in tests. I would stay away from it, as it's not obvious whether it's enabled or not, although it's enabled in this case as I tested. Please revert to the JUnit assertions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I am not sure what do you mean by whether it's enable or not but groovy assert is always executed, and provide much better comparison report
see http://groovy-lang.org/semantics.html#_power_assertion

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't know the groovy assert was different from Java. That looks good :)

@zhangkun83
Copy link
Collaborator

zhangkun83 commented Jul 20, 2016

@ngyukman The changes in the tests look good to me. I am now looking at the plugin changes.

A code-style note for Groovy files: please apply 2-space general indentation and 4-space line-break indentation, with a line length limit of 100.

void applyWithPrerequisitePlugin(List<String> possiblePluginNames, String pluginToBeApplied) {
possiblePluginNames.each { pluginName ->
project.pluginManager.withPlugin(pluginName, { prerequisitePlugin ->
applyWithPrerequisitePlugin (prerequisitePlugin, pluginToBeApplied)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extra space before left parentheses.

@zhangkun83
Copy link
Collaborator

I feel this PR will take a while to evolve. It may make sense to split out the changes in the tests as a separate PR and get it in sooner.

ngyukman added 2 commits July 24, 2016 19:27
- Set classpath to test projects to remove the need for installing
plugin before running test cases
@ngyukman
Copy link
Contributor Author

committed another approach #102

@ngyukman ngyukman closed this Sep 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants