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

If a Java dependency jar contains proto files, should extract them and add the extracted dir to --proto_path #15

Closed
zhangkun83 opened this issue May 28, 2015 · 9 comments

Comments

@zhangkun83
Copy link
Collaborator

The Protobuf release jars contain proto files for well-known types. The user may import these types in their own proto files, thus the well-known type proto files should be under a directory included in --proto_path.

maven-protoc-plugin is already doing so.

@mikhailmikhaylov
Copy link

Hello, we are currently using this framework in our project and encountered this issue.
We have a multi module project and each module can have it's own proto files. Proto files by themselves are depended on each other and on protoc's proto files (any.proto and others). And we can only workaround this by manually copying proto files into module.
Could you please let us know are there any plans to resolve this issue in the nearest future

@zhangkun83 zhangkun83 added this to the 0.6.0 milestone Jul 9, 2015
@zhangkun83 zhangkun83 changed the title If a dependency jar contains proto files, should extract them and add the extracted dir to --proto_path If a Java dependency jar contains proto files, should extract them and add the extracted dir to --proto_path Jul 9, 2015
@zhangkun83
Copy link
Collaborator Author

To clarify, this applies to Java dependencies, i.e., compile, testCompile etc.
There are Protobuf dependencies, i.e.., protobuf, testProtobuf etc, that simply contain proto files that will be compiled. This feature, however, is questionable (#25)

@zhangkun83
Copy link
Collaborator Author

There is an issue: if the depended protos and the dependent protos are compiled with different settings of option java_multiple_files, class names for a same message will be different in the two projects. We have two options:

  1. We don't do anything about it. That requires all projects to have the same java_multiple_files setting, or there will be trouble.
  2. We add an option to allow recompiling the proto files. There may still be chance of name collision, e.g., if a message has the same name as the outer class (by default it's the proto file name).

Anyway, Option 2 sounds better than nothing.

@zhangkun83
Copy link
Collaborator Author

According to @pherl, java_multiple_files is available as command line option only for nano, users can always specify this option in proto files, and there won't be a problem if a proto imports another proto that sets this option differently. So this is less of a problem than I initially thought. Users should just avoid using the command line option and always use in-fine options.

zhangkun83 added a commit that referenced this issue Jul 24, 2015
- If a project compiles proto files, they are packaged as resources in
  the compiled jar along with the class files. protobuf-java artifacts
  have already been including proto definitions for built-in types such
  as Any. This is only done for Java. There is a TODO for Android.
- proto files from dependencies are extracted into a temporary
  directory, which is added to the --proto_path argument of the protoc
  command line, so that they can be imported in the proto files of this
  project, but won't be compiled again.

Resolves #15
@zhangkun83
Copy link
Collaborator Author

@mikhailmikhaylov @mmmdreg can you guys give version 0.5.1-SNAPSHOT a try by adding the snapshot repository https://oss.sonatype.org/content/repositories/snapshots/ ?

@zhangkun83
Copy link
Collaborator Author

FYI 0.6.1 includes this feature and has been released on Maven Central.

@yaraki
Copy link

yaraki commented Mar 2, 2017

Is this feature available for protobuf-lite?

@zhangkun83
Copy link
Collaborator Author

No. protobuf-lite doesn't provide those well-known protos.

@ejona86
Copy link
Collaborator

ejona86 commented Mar 2, 2017

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

No branches or pull requests

4 participants