Merge back to original repo, so we call update it to proto 3.x used by GRPC

[ludoch]

grcp (https://github.com/grpc) is very active now and is relying on proto 3
Java users need a nice Maven integration, so we will update the original repo:
protocolbuffers/protobuf#230
(currently in https://code.google.com/p/protobuf/source/browse/#svn%2Fbranches%2Fmaven-plugin%2Ftools%2Fmaven-plugin but could be move to github soon)
If it is OK with all the contributors of this https://github.com/dtrott/maven-protoc-plugin/ repo, we could align the effort, and then update it to support the new protoc 3.0.0

I see these 4 contibutors:
https://github.com/oschrenk
https://github.com/dtrott
https://github.com/devans
https://github.com/masterzen
That would have to sign a https://cla.developers.google.com/about/google-individual and then we can merge and progress on protoc 3.0

[ludoch]

Adding @masterzen @dtrott @devans @oschrenk for comments and potential agreement for the collaboration and push to Maven central of an updated plugin for protoc 3.0

[oschrenk]

signed

[masterzen]

@ludoch, signed.

[ludoch]

Maybe we should first merge https://github.com/sergei-ivanov/maven-protoc-plugin/commits/master ?
@ssergei-ivanov

[ludoch]

@sergei-ivanov

[sergei-ivanov]

@ludoch You may want to take a look at this issue that was opened 2 years ago in the original protobuf project:
https://code.google.com/p/protobuf/issues/detail?id=476

The net result so far is that I approached people from Google directly and through mailing lists and nothing came out of it. In the end I've given up on the idea of contributing my changes to the plugin back into protobuf project. I (and some of my former colleagues) invested quite some time and effort to bring the plugin to its current state, and I think I shall continue go separate ways with Google. Call me an arsehole, but I am refusing to sign up to Google's CLA and thereby relinguish the rights on my work to Google, who have done bugger all to support the plugin in all these years.

Therefore, my plan is as follows. I am going to produce the last release from my fork in the next few days. That will contain some critical compatibility fixes for the latest Maven and also support for C++ and Python. After that, I am going to invoke Plan B, as detailed in the above protobuf issue:

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 rewrite whatever is left from the original code from scratch. The end goal is to make the plugin available in Maven Central.

All future development will happen in the new plugin.

Apologies if I sounded rude, and apologies if my stance disrupts your immediate plans. I hope to get going with the new clean version of the plugin soon.

[dtrott]

My contributions are significantly less than Sergei's.
I have just signed the CLA, and read Sergei's comment before posting this.

I don't believe I took any pull requests from Sergei into the branch I worked on.
Therefore I will leave it up to you (ludoch) how you wish to proceed.

[sergei-ivanov]

...and to give credit where credit is due, I am eternally grateful to David, Brice and other contributors to the initial GitHub version of the plugin. You've done a marvellous job back in the day.

[devans]

Signed, I think.

We're actually forked right now; this:

gec@42cfc5f

is the only commit I would need either merged or recreated in order to get back on a google run repo.

[sergei-ivanov]

The original protobuf developers effectively abandoned the plugin many years ago, citing their lack of Maven expertise as a reason (which was fair enough). If this is still the case, then who is going to drive the evolution of the plugin on behalf of protobuf team? There is little point in merging back unless there is a firm commitment from the protobuf team or Google to maintain the project and look after it.

[ludoch]

I agree 100%, I am trying to address this now.
Ludo (Googler and Maven/Gradle fan)

On Fri, Mar 6, 2015 at 12:29 PM, Sergei Ivanov [email protected]
wrote:

The original protobuf developers effectively abandoned the plugin many
years ago, citing their lack of Maven expertise as a reason (which was fair
enough). If this is still the case, then who is going to drive the
evolution of the plugin on behalf of protobuf team? There is little point
in merging back unless there is a firm commitment from the protobuf team or
Google to maintain the project and look after it.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[ludoch]

Sergei, I understand your position (been there before!)
I am trying to make sure Google will (finally) be 100% behind this effort, as I see it as a critical success factor for protoc anf grpc future. It has to happen. We now have more Maven/Gradle experts and we are committed more and more to the Open Source community, as it is a critical aspect for the success of the Cloud Platform.
Now, I would be very sorry for the developer community if they see 2 different/equivalent Maven plugins in 2 different namespaces... We need to think first about the developers.
Let's try to resolve this.
And again, I understand your current position, and i thank you for the fact that your offered to the Java community a viable story for supporting the protoc tooling!
Cheers,

[sergei-ivanov]

@ludoch

I think an amicable settlement is still entirely possible. I shall let you figure out with the fellow googlers how the plugin is going to be supported going forward. This is a pre-requisite. You may drop me an e-mail to [email protected] if you'd prefer to discuss it privately.

Anyway. Please give me a couple of days, I want to tag a release of the plugin first, and I think I am finally ready to do that. I reviewed the CLA once again, small print and all, and I think it is not as creepy as it initially appeared to me. I am still dubious about it, because I did not ever have to sign anything with regards to my contributions to other open source projects. I understand the intent behind it, but I would be more comfortable if Google had a separate non-profit entity to manage its open-source IP. But I think that for the greater good I'll sign my soul away, provided that Google indeed demonstrates some care for the plugin.

There are other products that are currently bundled with the plugin on my branch, namely winrun4j. I checked the licence on it, and it is distributed under Eclipse CPL. Their licence looks reasonably benign, but I need a bit more time to read and understand the small print there.

The plugin itself does not have a licence explicitly declared, but I reckon it inherits the licence from the protobuf project. If the plugin merges back into protobuf project, then this becomes a non-issue.

I may need to apply the patch from @devans to my branch (maybe not as-is, depending how well it fits with everyhting else).

Some of the issues I raised in the original protobuf feature request are still relevant. For example, maven coordinates will need to be changed. Apache team has started ruthlessly enforcing the plugin artifact naming convention, and a few developers with maven-xxx-plugin plugins have already received a "cease and desist" note.

It will also be great if you come up with a detailed migration plan from Google perspective.

Kind regards,
Sergei

[ludoch]

Hey Sergei!
Thanks for this nice update...
I think we can make it work, both for Google and for the community and
contributors like you,
Cheers,
Ludo

On Mon, Mar 9, 2015 at 6:05 PM, Sergei Ivanov [email protected]
wrote:

@ludoch https://github.com/ludoch

I think an amicable settlement is still entirely possible. I shall let you
figure out with the fellow googlers how the plugin is going to be supported
going forward. This is a pre-requisite. You may drop me an e-mail to
[email protected] if you'd prefer to discuss it privately.

Anyway. Please give me a couple of days, I want to tag a release of the
plugin first, and I think I am finally ready to do that. I reviewed the CLA
once again, small print and all, and I think it is not as creepy as it
initially appeared to me. I am still dubious about it, because I did not
ever have to sign anything with regards to my contributions to other open
source projects. I understand the intent behind it, but I would be more
comfortable if Google had a separate non-profit entity to manage its
open-source IP. But I think that for the greater good I'll sign my soul
away, provided that Google indeed demonstrates some care for the plugin.

There are other products that are currently bundled with the plugin on my
branch, namely winrun4j. I checked the licence on it, and it is distributed
under Eclipse CPL. Their licence looks reasonably benign, but I need a bit
more time to read and understand the small print there.

The plugin itself does not have a licence explicitly declared, but I
reckon it inherits the licence from the protobuf project. If the plugin
merges back into protobuf project, then this becomes a non-issue.

I may need to apply the patch from @devans https://github.com/devans to
my branch (maybe not as-is, depending how well it fits with everyhting
else).

Some of the issues I raised in the original protobuf feature request are
still relevant. For example, maven coordinates will need to be changed.
Apache team has started ruthlessly enforcing the plugin artifact naming
convention, and a few developers with maven-xxx-plugin plugins have already
received a "cease and desist" note.

It will also be great if you come up with a detailed migration plan from
Google perspective.

Kind regards,
Sergei

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[parsnips]

Hey wanted to ping this thread and see where this is heading? Simple uses maven and we're implementing GRPC stuff internally and we're happy to help with anything necessary to get moving forward on using @sergei-ivanov and @dtrott work in a blessed manner.

[sergei-ivanov]

@ludoch I think it is time to close this thread. We have reached an amicable agreement on licensing with Google, and the plugin has a new home now.
https://www.xolstice.org/protobuf-maven-plugin-0.5.0-released/
It should work with GRPC, but please let me know if it does not, or if any further improvements are required. Thank you for your patience.