Comment #4 on issue 476 by sergei.s...@gmail.com: please document how to
use protobuf with maven
http://code.google.com/p/protobuf/issues/detail?id=476
Hi,
This thread has been brought to my attention by Paul, and I am going to use
this opportunity to provide an update (and some history) below.
1. Some history.
I forked David Trott's repository a couple of years ago with a view to
submit a bug fix, but since David did not have resources to continue work
on his branch, I effectively took over the plugin development on my own
branch.
David's implementation of the plugin was based on what Gregory from Google
Protobuf team originally created on a branch, but never merged to the
trunk. With the help of GitHub community members, most of the blocker bugs
were fixed and the plugin became stable enough for everyday use.
I took over the plugin at the time when we ourselves were migrating from an
abomination of Ant+Ivy build to a new shiny Maven-driven environment. The
legacy build had two killer features though, and we wanted to retain these
to a reasonable extent:
a) it was self-sufficient and did not require you to specify protoc
executable location (it was downloaded from our Ivy repo)
b) it worked pretty well with dependent protos scattered across a number of
projects/modules
2. What has been done
We ruled out hosting protoc binaries in our Maven repo. However, instead of
relying on the operating environment or system properties, we wanted to
configure protoc executable in a more portable way. That's when I took a
deep dive into Maven toolchains and figured they would be quite an elegant
solution to the problem.
After the introduction of the new protobuf toolchain, we were able to
specify protoc location in the toolchains file, optionally with multiple
alternative locations for different protoc versions. In the project pom,
the required protoc executable would be selected by simply specifying a
version (or a range of versions).
Introduction of protobuf toolchains also paved the way to providing an
extensive set of stable and predictable integration tests, which was not
possible before.
We noticed that the original plugin did not work correctly with importing
protos from other modules when namespaces were being used. This had been
fixed. We also fixed multi-module builds when protos from module1 in a
reactor project imported protos from module2. Test dependencies have been
fixed too.
I have also cleaned up maven project configuration, updated dependencies
and set up a proper generated Maven site documentation for the plugin:
http://sergei-ivanov.github.com/maven-protoc-plugin/
The above satisfied our immediate requirements and allowed us to proceed
with Maven migration, and the whole set-up has been in production for the
last 1.5 years.
Later additions were mainly own implementations of functionality that
became available on alternative branches, or pull requests from the other
community members, namely:
a) support for generating binary descriptor sets (--descriptor-out protoc
option)
b) integration into Eclipse lifecycle (experimental)
c) started a work on allowing alternative protoc output (C++ and Python),
but it's not complete yet, because I want to perform a major refactoring of
mojos first
d) added support of executing protoc plugins (that is, plugins for protoc
compiler) that are packaged as compiled java classes
3. The future
...is a bit unclear. Quite a few people expressed interest in contributing
to the plugin code, but were deterred by unclear licensing terms. I admit
it's a problem, and I am inviting Google chaps to contact me directly to
discuss it. The original plugin code was submitted under Google Protobuf
licence, and both java package structure and maven coordinates retain
google.com references. I believe initially there was a hope that Google
people would take over and own the plugin, but that has never happened, and
the plugin continues to live its own life separately from Google.
As I understand, Google Protobuf team does not have enough resources and/or
expertise and/or motivation to take over the Maven plugin development and
maintenance, and I cannot blame them for that. I think that, unless there's
a need for some critical bug fix, the latest version of my plugin (released
last night) will be the final one on that branch.
I am going to start a new project from scratch, repackage all classes,
change maven coordinates, assign a liberal open-source licence to it and
either (a) [perhaps unlikely] obtain a copyright release and licence
clearance from the Google Protobuf project team and retain the original
code or (b) [more likely] rewrite whatever is left from the original code
from scratch. The end goal is to make the plugin available in Maven Central.
Kind regards,
Sergei
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
