ProtoToJavaBeanCompiler template option about protostuff-googlecode-exported

[GoogleCodeExporter]

Have you tried:

   modules = foo
   foo.source = path/to/your/foo.proto
   foo.output = path/to/your/foo.java.stg
   foo.outputDir = your_output_dir
   foo.options = your_options

group foo : java_bean;

message_getters_and_setters(message, options) ::= <<
// getters and setters
<message.fields:field_getters_and_setters(field=it, options=options, 
message=message)>

// add your extra methods here.
>>

What you suggested could be easily added ... but then again, I think the above 
approach would work fine.  Let me know if it that works you?

Original comment by [email protected] on 25 Jan 2011 at 2:44

• Changed state: Accepted

[GoogleCodeExporter]

oh yes that does work for the scenario I have now.  Thank you.  Out of 
interest, why did you choose not to use the builder pattern?

I dont really like mutable objects, and the idea of a builder where I can set 
the properties then build an immutable instance is much better (for me :-)  ).  

Original comment by [email protected] on 25 Jan 2011 at 3:23

[GoogleCodeExporter]

actually, is it possible that rather than:
foo.output = path/to/your/foo.java.stg

then can have a file on the classpath.  i want to package the template up in a 
jar for other sub components to use, but I cant figure out how to reference the 
file on the classpath in the jar.

thanks, for your help!

Original comment by [email protected] on 25 Jan 2011 at 3:26

[GoogleCodeExporter]

Why not the builder pattern?
For one, ser/deser of cyclic references is not possible with the builder 
pattern.  Protostuff has been built to be as flexible as possible to perform 
any kind of serialization.

With regards to immutablility, you can still make your objects immutable by 
marking all the fields final.
See 
http://groups.google.com/group/protostuff/browse_thread/thread/2bd1299985224d9a
I'll probably add that to protostuff-runtime(as a runtime option) to support 
immutable objects.

Btw, if you want to contribute your extra methods, it can be added to 
protostuff as a standard option.

With regards to loading from classpath, can you file a new issue for that one?
On the other hand, the imported protos can already be imported from the 
classpath (and from a remote http url too).

Original comment by [email protected] on 25 Jan 2011 at 5:36

• Changed state: Done

[GoogleCodeExporter]

Thank you for your reply so quickly!  Ok, I understand why you're not using the 
builder pattern now.  I dont think I will be able to contribute the extra 
method, because they are adding compatibility to a framework I am developing so 
its not really generic.

Ok, I will raise one for the classpath.

One more question if thats ok.  I have a definition in a subfolder importing a 
.proto in another folder, e.g.
./subflder2/Bar.proto

In that file it has this:

import "PATH/subfoler1/Foo.proto";

But when I try to generate a class with the protostuff compiler I get this 
error:

1/25/11 3:39:26 PM JST: Build error for /myproject/pom.xml; 
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
com.dyuproject.protostuff:protostuff-maven-plugin:1.0.0.M7:compile 
(generate-sources) on project my-project: java.lang.RuntimeException: 
java.lang.IllegalStateException: Imported proto ./subfolder1/Foo.proto not 
found.


The import works fine using the protobuf compiler.  I think its a bug, should I 
raise a new issue, or do you think I am doing something wrong?  I need these 
files to compile with the regular protobuf compiler too for now Java components.

thanks again for your help!  I really like the product, its cleaner than the 
protobuf generated classes.

Original comment by [email protected] on 25 Jan 2011 at 6:50

[GoogleCodeExporter]

is PATH a keyword in protobuf?
It would even be better if you could provide a sample set of protos w/c 
replicates the problem (would quicker to fix the bug that way)

Thanks

Original comment by [email protected] on 25 Jan 2011 at 8:05