sergei-ivanov / maven-protoc-plugin Goto Github PK

Port M2E-related changes from Igor Petruk's plugin:
igor-petruk/protobuf-maven-plugin@c2d6587

Required parameters:

• plugin_id: this can be automatically resolved by protoc to executable name (must be in the PATH)

Optional:

• plugin_executable: an explicit path to the executable
• output_directory: to be derived by default from Maven project environment and plugin_id
• parameter: optional parameter to be passed to the plugin

All other parameters inherited from base mojos.
In order to avoid clashes with built-in plugins, need to check that plugin_id is not one of cpp, java, python or descriptor_set.

Nice to have: support for toolchains. That will require two additional parameters: toolchain_type and toolchain_tool.

Port protoc configuration changes from https://github.com/usmanismail/maven-protoc-plugin fork, but split mojos per language instead of attempting to cover all output languages in a single mojo.

Protoc is now available in the central repository as com.google.protobuf:protoc:2.6.1. Do you think it would be possible to use it in the plugin to avoid the configuration of the protoc path?

I see in the usage page, python and C++. It would be helpful to me if this plugin could also handle C#.

By default it's src/main/proto and it's ok for java. But for Android it should be changed (yes, now android studio supports /src/main/java-like paths but most current android project still use /src for java classes and /proto for .proto).

Can you add protoPath value to configuration section?

Java 8 introduced stringent checks for javadoc well-formedness, which are turned on by default. Need to make sure that all plugin javadocs are up to standard and that site generation under java 8 completes successfully.

At the moment it appears that the generated descriptor set is not attached to the build and there is no configuration option to do so. Need to add an attachDescriptorSet flag and an optional descriptorSetClassifier.

After as proto is compiled I found source proto file in generated classes folder, it lead that proto source code available in APK build file (I write for android). It is very insecure, I don't want to share my protocol to public. How I cant prevent it?

Provide "standalone" mojos (with requiresDependencyResolution=NONE, and possibly also requiresProject=false) alongside the existing mojos. The idea is that not every project requires protos from other project(s), and a standalone mojo will be simpler, more efficient and avoid dependency resolution issues such as http://jira.codehaus.org/browse/MNG-3283.

Follow up on the recent changes in the configuration of Maven core plugins.

I tried downloading the plugin from the link given in the README:

http://sergei-ivanov.github.com/maven-protoc-plugin/repo/releases/

But it does not work. Could you fix it?

Thanks,
Cristian

At the demand of a few engineers in my org, I'm trying to integrate the Maven+proto tooling into a working Eclipse build. I've had success getting successful builds at the command line but am struggling to make sense of this issue. It appears there is a version conflict between the various version of plexus-utils on which a lot of plugins rely — maven-protoc-plugin has made the leap to 3.0.10 while the rest of the world uses 2.0.5 or even 1.5.*. The following error output annotates the pom.xml file in Eclipse:

Execution Generate proto sources of goal com.google.protobuf.tools:maven-protoc-plugin:0.3.1:compile failed: An API incompatibility was encountered while executing com.google.protobuf.tools:maven-protoc-plugin:0.3.1:compile: java.lang.NoSuchMethodError: org.codehaus.plexus.util.DirectoryScanner.setupMatchPatterns()V
-----------------------------------------------------
realm =    plugin>com.google.protobuf.tools:maven-protoc-plugin:0.3.1
strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
urls[0] = file:/Users/jsilland/.m2/repository/com/google/protobuf/tools/maven-protoc-plugin/0.3.1/maven-protoc-plugin-0.3.1.jar
urls[1] = file:/Users/jsilland/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
urls[2] = file:/Users/jsilland/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.2/maven-plugin-annotations-3.2.jar
urls[3] = file:/Users/jsilland/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.10/plexus-utils-3.0.10.jar
urls[4] = file:/Users/jsilland/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
urls[5] = file:/Users/jsilland/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
urls[6] = file:/Users/jsilland/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
urls[7] = file:/Users/jsilland/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
urls[8] = file:/Users/jsilland/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
urls[9] = file:/Users/jsilland/.m2/repository/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar
urls[10] = file:/Users/jsilland/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
urls[11] = file:/Users/jsilland/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
urls[12] = file:/Users/jsilland/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
urls[13] = file:/Users/jsilland/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
urls[14] = file:/Users/jsilland/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
urls[15] = file:/Users/jsilland/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
urls[16] = file:/Users/jsilland/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
urls[17] = file:/Users/jsilland/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
urls[18] = file:/Users/jsilland/.m2/repository/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar
Number of foreign imports: 4
import: Entry[import org.sonatype.plexus.build.incremental from realm ClassRealm[plexus.core, parent: null]]
import: Entry[import org.codehaus.plexus.util.Scanner from realm ClassRealm[plexus.core, parent: null]]
import: Entry[import org.codehaus.plexus.util.AbstractScanner from realm ClassRealm[plexus.core, parent: null]]
import: Entry[import  from realm ClassRealm[maven.api, parent: null]]

-----------------------------------------------------
 (com.google.protobuf.tools:maven-protoc-plugin:0.3.1:compile:Generate proto sources:generate-sources)

And indeed, that particular method (protected setupMatchPatterns) is new in plexus v3. I've reached a functional state by forcing down the version of plexus-utils in the maven-protoc-plugin deps. I guess there might be some different way of solving this issue but my investigation has failed to find another way:

            <plugin>
                <groupId>com.google.protobuf.tools</groupId>
                <artifactId>maven-protoc-plugin</artifactId>
                <version>0.3.1</version>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.plexus</groupId>
                        <artifactId>plexus-utils</artifactId>
                        <version>2.0.5</version>
                    </dependency>
                </dependencies>
            </plugin>

Is there another way besides sprinkling this all over my projects?

Maven2 is officially end of life and not supported anymore. In line with changes in Apache and CodeHaus Maven plugins, the minimum required Maven version for the plugin will be 3.0.0. This will allow to remove extraneous dependencies and any code that exists solely for compatibility reasons with Maven2.

Hi,
We have a large number of proto files to be compiled. We're getting an error about the command line being too long. Is it possible for the plugin to invoke protoc for one file at a time?

In a multi-developer & multi-platform environment, one should take in mind that protoc location is a mutable value.

Since this plug-in allows you to define protoc path in the POM, this is somewhat covered. But would be great if the plug-in could simply download the protoc distribution (depending on the version specified in the POM) and make it available to the user in ~/.protobuf_dist. It would only take the time to download the first time but would then be available to every developer, no matter what OS he'd be running.

http://sergei-ivanov.github.com/maven-protoc-plugin/repo/releases/
returns 404

Hi.
Lately there has been some discussion on the protobuf mailinglist, and on the issuetracker on inclusion of maven plugins to the 3rd party tools wikipage, see http://code.google.com/p/protobuf/issues/detail?id=476

It would be nice if you could comment and provide an "official" standpoint on the current state of the maven-protoc-plugin.

Regards,
Paul

At the moment, the plugin clears out the output directory before invoking protoc. This is often more of an annoyance than help, and it should be made optional. protoc always overwrites the output files and does not complain if they already exist. Maven clean lifecycle goal can be used to clear out the output directory if required.

Follow uo on the recent changes in various maven core and codehaus plugins and raise the minumum requirement for Maven version.

I see from http://sergei-ivanov.github.io/maven-protoc-plugin/usage.html that the tool expects the .proto files to be in src/main/proto.

I am trying to use the plugin on an existing project, that has the .proto scattered amongst the .java files in various package structures under src/java/main.

Is there any way to point the tool to look for .proto under src/java/main instead?

It is better to explicitly to specify the license of any project. Github does not have a sort of default license. Just by publishing your project to github you accept some terms that allow to view and fork the project, but it is still uncertain.

This url: http://sergei-ivanov.github.com/maven-protoc-plugin/repo/releases/ - is missing.

Maven core, utilities and plugins are set to migrate to java6 as a minimum requirement. Update the maven project for the plugin accordingly.

I have class a.proto that imports b.proto.

When I use maven-protoc-plugin it compiles both files with a single protoc command and then
protoc fails with
" PROTOC FAILED: b.proto:21:20: "Msg" is already defined in file "b.proto".

That happens because protoc imports b.proto twice: first when importing a.proto and then when importing b.proto.

The URL listed in the README no longer works:

<pluginRepositories>
    <pluginRepository>
        <id>protoc-plugin</id>
        <url>http://sergei-ivanov.github.com/maven-protoc-plugin/repo/releases/</url>
    </pluginRepository>
</pluginRepositories>

Changes in https://jira.codehaus.org/browse/MNG-5718 broke backward API compatibility for toolchain providers. As a result, the plugin cannot be used with Maven 3.2.5 or later. Need to integrate a workaround from Hervé's reference implementation:
http://svn.apache.org/viewvc/maven/plugins/tags/maven-toolchains-plugin-1.1/src/it/custom-toolchain-plugin/src/main/java/org/apache/maven/plugins/toolchains/its/custom/CustomToolchainFactory.java?view=markup

Submitted by David Elliott

I only have one issue with it: it doesn’t keep the proto_path option in dependency order and this causes problems when people are shadowing .proto files.

It’s a one-line fix: use a new LinkedHashSet just like Maven itself uses to keep the Artifact sets ordered.

it'd be great to have this plugin in maven central.

Maven 3.1 made a breaking change moving to Apache Aether which causes the maven-protoc-plugin to break when usage with Maven 3.1 is attempted (works fine with Maven 3.0.x and Maven 2.x.) See here for info https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound .

To replicate this issue, create a project with a .proto file in it:

src/main/proto/foo.proto

Run mvn compile and the generated java files go in targets/generated-sources. So far so good.

Now, rm -rf the target directory and put any file into the src/test/proto directory:

rm -rf target
touch src/test/proto/README.md

Re-run mvn compile. The proto files are now all generated into targets/generated-test-sources and invisible outside of scope "test" to other projects.

The issue is that there is only one java output directory and if you set it twice using Protoc.setJavaOutputDirectory(), the last one wins. We could patch around this issue by skipping the setJavaOutputDirectory() in if there are no valid .proto source files inside of ProtocTestCompileMojo.addProtocBuilderParameters(). That will fix this case, but might allow you to define protos both in src/main/proto and src/test/proto in the same project.

I'm about to publish a library whose Maven artifact uses this plugin to compile proto messages. I'd like to make this library available on Maven Central, which discourages the use of pluginRepositories and provides only a convoluted way for me to upload a third party artifact to Central, which I would like to avoid doing myself: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository

Is there a concrete plan to make maven-protoc-plugin available on central? I read in a separate bug that there's talk of doing a clean-room implementation of this plugin due to some confusion surrounding licenses, but would this further delay to publishing of this plugin to the rest of the world. I'm happy to contribute time and code to this effort if the plans for this have already been devised.