[protobuf] Re: Issue 149 in protobuf: maven-protoc-plugin fails during multi-project compile
Comment #2 on issue 149 by damian.ryan: maven-protoc-plugin fails during
multi-project compile
http://code.google.com/p/protobuf/issues/detail?id=149
I have encountered exactly the same issue having just converted a set of
previously
separate project builds into multi-module maven build.
One of the child modules invokes protoc during the generate-sources
lifecycle phase.
This module depends on other (peer) child modules within the multi-module
build.
There was never an issue over several months' use when performing
single-module
builds of this module, nor is there now if the module is built in isolation.
However, if a goal below the package lifecycle phase is executed on a
multi-module
build (for example: mvn clean test on the aggregator/parent POM), the build
fails
complaining that the classes directory of a completely different module is
not a file:
[DEBUG] Configuring mojo
'com.google.protobuf.tools:maven-protoc-plugin:0.0.1:compile' --
[DEBUG] (f) outputDirectory =
C:\dev\code\code-trunk\libraries\domain-objects\target\generated-sources\protoc
[DEBUG] (f) project = MavenProject:
com.ubs.etdet.skore:domain-objects:0.6.0-SNAPSHOT @
C:\dev\code\code-trunk\libraries\domain-objects\pom.xml
[DEBUG] (f) protoSourceRoot =
C:\dev\code\code-trunk\libraries\domain-objects\src\main\proto
[DEBUG] (f) protocExecutable =
C:\dev\code\code-trunk\libraries\domain-objects/bin/protoc.exe
[DEBUG] (f) temporaryProtoFileDirectory =
c:\DOCUME~1\damianr\LOCALS~1\Temp\maven-protoc
[DEBUG] -- end configuration --
[INFO] [protoc:compile {execution: generate-sources}]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Protoc failed to execute because:
C:\dev\code\code-trunk\libraries\utils\target\classes is not a file
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Protoc failed to execute because:
C:\dev\code\code-trunk\libraries\utils\target\classes is not a file
However, if any goal bound to a phase of package or later is executed (for
example:
package, install, deploy or release), the build succeeds.
--
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
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: protoc plugin compiler extension framework
i think it would also be very helpful to have some sort of dummy-
example-plugin documentation.
at the moment i am completely lost how to begin to write the plugin.
but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)
On Jan 6, 7:01 pm, Kenton Varda ken...@google.com wrote:
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...
On Wed, Jan 6, 2010 at 1:29 AM, Chris hsifdr...@gmail.com wrote:
Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.
On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
The plugin framework is not meant for this. Plugins can only insert code
at
points that have explicitly been declared by the original generator. For
example, in Java, the code generator generates one insertion point in
each
class. So, you can add new methods to a message type, but you cannot
stick
javadoc comments on the existing methods.
I think that a system which let you arbitrarily edit the generated code
would be too fragile -- any change to the code generator would
potentially
break plugins. In fact, I'm even worried that the current system is
risky
because it allows plugins to get access to private members which could
change, but I don't see any way around that.
All this said, I think it would be great if the protocol compiler
supported
some format for documentation comments and automatically copied those
comments into the generated code. But no one has actually worked on this
yet.
On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott cpigg...@gmail.com
wrote:
Hmm maybe I can use the UninterpretedOption message to do this.
Would something like this work?
message ChrisMessage {
option javadoc = This is an object representing Chris's Message;
repeated int32 field1 = 1 [javadoc=This is a javadoc for field 1];
repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
}
Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */
Possible?
--
You received this message because you are subscribed to the Google
Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: protoc plugin compiler extension framework
Plugins are now mentioned in the docs in several places:
http://code.google.com/apis/protocolbuffers/docs/reference/other.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#plugins(similarly
for java-generated and python-generated)
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.plugin.pb.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.plugin.html
I agree that some sort of tutorial would be nice but my tech writer is on
leave and as an engineer I suck at that sort of thing. :/
Here's a plugin I wrote for my own RPC system:
http://code.google.com/p/capnproto/source/browse/compiler/protoc-gen-capnproto-java.cc
On Fri, Feb 26, 2010 at 9:00 AM, phelyks felix.schm...@gmail.com wrote:
i think it would also be very helpful to have some sort of dummy-
example-plugin documentation.
at the moment i am completely lost how to begin to write the plugin.
but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)
On Jan 6, 7:01 pm, Kenton Varda ken...@google.com wrote:
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:
http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot.
..
On Wed, Jan 6, 2010 at 1:29 AM, Chris hsifdr...@gmail.com wrote:
Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.
On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
The plugin framework is not meant for this. Plugins can only insert
code
at
points that have explicitly been declared by the original generator.
For
example, in Java, the code generator generates one insertion point in
each
class. So, you can add new methods to a message type, but you cannot
stick
javadoc comments on the existing methods.
I think that a system which let you arbitrarily edit the generated
code
would be too fragile -- any change to the code generator would
potentially
break plugins. In fact, I'm even worried that the current system is
risky
because it allows plugins to get access to private members which
could
change, but I don't see any way around that.
All this said, I think it would be great if the protocol compiler
supported
some format for documentation comments and automatically copied those
comments into the generated code. But no one has actually worked on
this
yet.
On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott
cpigg...@gmail.com
wrote:
Hmm maybe I can use the UninterpretedOption message to do this.
Would something like this work?
message ChrisMessage {
option javadoc = This is an object representing Chris's Message;
repeated int32 field1 = 1 [javadoc=This is a javadoc for field
1];
repeated int32 field2 = 2 [javadoc=This is a javadoc for field
2];
}
Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */
Possible?
--
You received this message because you are subscribed to the Google
Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
protobuf%252bunsubscr...@googlegroups.comprotobuf%25252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google
Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to
[protobuf] Re: Issue 169 in protobuf: protoc will not build from a path that contains spaces on OS X 10.6
Updates: Status: WontFix Comment #1 on issue 169 by ken...@google.com: protoc will not build from a path that contains spaces on OS X 10.6 http://code.google.com/p/protobuf/issues/detail?id=169 This appears to be a problem with libtool, one of the tools used in building the protobuf package. We don't maintain libtool so there's not much we can do about this, but you could report the issue to them. It's certainly true that many Unix tools get confused by paths containing spaces, since such paths are usually avoided on Unix systems. -- 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 -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
