I have found a bug in the way that the derivedProtopathElements get
calculated. It
is assumed that all the dependency artifacts will be files (specifically
jar files)
but this is not the case when doing a reactor (multi-module) build.
For reactor builds, the compile artifacts can be directories, e.g.,
target/classes,
from other modules that were built as part of the same mvn invocation.
I'd like to second the comment that I don't really see the need to always
be looking
in dependency jars for .proto files. If I'm depending on an artifact with
proto
files, why would I assume that the java bindings were not generated and
included in
that dependency's jar? My preference would be to require transitive
sources of proto
files be listed explicitly in the plugin config.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
@supercargo,
I fixed this bug in the github fork:
http://github.com/dtrott/maven-protoc-plugin
There is also a maven repository holding a version that contains that fix.
Can we merge into the trunk in time for release 2.3.1 ?
Here is a patch that merges this the maven-plugin branch into r344 and
fixes issues #138 and #149 and #152
Please?
Hi all,
It seems clear that Greg doesn't have time to maintain this, and I can't
maintain it either as I know nothing about Maven. Would someone like to
fork it off into a separate googlecode project? It seems logically
separate anyway. (In fact, I'm planning to split the protobuf C++, Java,
and Python components into three separate projects at some point.)
Comment #20 on issue 81 by g...@google.com: Maven Protoc Plugin Code Review
http://code.google.com/p/protobuf/issues/detail?id=81
Kenton brought this issue to my attention offline and I apologize for
ignoring it. This issue has been assigned to an account I haven't be using.
It looks like there are a lot of good bug reports and some good patches. I
believe that, in order to integrate the patches, the authors need to agree
to the CLA (http://code.google.com/legal/individual-cla-v1.0.html), which
can be sort of a hassle.
Though there seems to be interest here, I'm tempted to just deprecate it in
favor of http://github.com/dtrott/maven-protoc-plugin as it seems that is
being very actively developed. Any compelling reasons not to?
This issue is now blocking issue 138.
See http://code.google.com/p/protobuf/issues/detail?id=138
--
This issue is now blocking issue 149.
See http://code.google.com/p/protobuf/issues/detail?id=149
This issue is now blocking issue 152.
See http://code.google.com/p/protobuf/issues/detail?id=152
I don't suppose the protoc compiler itself could be distributed as a maven
artifact? It would be great to be able to specify it in the pom instead of
having to ensure an exe exists in the path of every machine that builds the
source.
I don't believe that Maven has any support for platform-dependent
artifacts. That said, it might be worth documenting installation via some
of the different package management utilities (e.g. apt, macports).
Would classifiers (e.g. <classifier>windows</classifier>) help in the
creation of platform-dependent artifacts?