summaryrefslogtreecommitdiff
path: root/android
diff options
context:
space:
mode:
authorRomain Gilles <rgilles@github>2016-06-07 09:05:56 +0200
committerRomain Gilles <rgilles@github>2016-06-07 09:05:56 +0200
commit9875b0e0f8af5781a793fb93807641c9cebfb903 (patch)
tree3184c6e819a56e518852ae86e3b456ebbc0c0e44 /android
parente92ae5199d52fd59540a800bec7eef46cd778257 (diff)
downloadflatbuffers-9875b0e0f8af5781a793fb93807641c9cebfb903.tar.gz
flatbuffers-9875b0e0f8af5781a793fb93807641c9cebfb903.tar.bz2
flatbuffers-9875b0e0f8af5781a793fb93807641c9cebfb903.zip
Create a maven like project structure for java development. Make it OSGi compliant. Generate the flatbuffers code for testing (example).
Java developer are mostly comfortable with maven project structure. One one the main concept behind maven is convention. If you follow the maven project convention then your development team will get more effective as they now this project structure and can easily find the production code versus the test code. In this pull request I have structured the java project around 2 main parts: * the `flatbuffers` project. This project is the api / lib project and contains the test code structure + an example of code generation for testing. This avoid to commit generated code. Pre-configure JUnit for test driven development and make this project OSGi compliant. * the `jmh` project. This project aims to provide a placeholder for micro-benchmarking. JMH is a 'de facto' standard for micro benchmarking you can find more details here: http://openjdk.java.net/projects/code-tools/jmh/ For now I didn't move the JavaTest class but it could be a next step with a migration to the JUnit framework. The only impacts are the move of the class and the project structure => no code change.
Diffstat (limited to 'android')
0 files changed, 0 insertions, 0 deletions