http://gwt-code-reviews.appspot.com/1503804/diff/1/samples/dynatablerf/build.xml
File samples/dynatablerf/build.xml (right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/samples/dynatablerf/build.xml#newcode8
samples/dynatablerf/build.xml:8: <!-- Run the annotation processor -->
On 2011/08/02 17:43:26, rjrjr wrote:
This is a sample, can you be a bit more verbose? Annotation processor
is an
implementation detail.
So really people "only" need to include this jar if they want compile
time
notification of RF errors. Which seems like a pretty big deal,
especially if the
rf server will no longer do such validation by default.
The server code won't accept the RequestFactory interface if it hasn't
been validated. A runtime error will occur, telling the user to run the
ValidationTool.
Should we do something to force people to include this jar, like
remove RF from
gwt-user? I suppose that's a pretty drastic thing to do to existing
users,
although frankly it's tempting. Will they see any kind of warning if
they don't
include it ?
I'm actually tempted to be drastic.
I've been thinking about pulling the requestfactory server and vm code
from gwt-[user|servlet].jar since that encourages deployment bloat. I
could go either way on pulling the client code from gwt-user.jar.
Would it be better to not include the annotation processor in
requestfactory-client.jar and instead require the user to add
requestfactory-apt.jar to their build path? It would slightly reduce
the amount of code in requestfactory-client.jar and would avoid any
confusion with adding requestfactory-client.jar to a server build
process.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/DeobfuscatorBuilder.java
File
user/src/com/google/web/bindery/requestfactory/apt/DeobfuscatorBuilder.java
(right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/DeobfuscatorBuilder.java#newcode38
user/src/com/google/web/bindery/requestfactory/apt/DeobfuscatorBuilder.java:38:
* Visits a RequestFactory to create its associated DeobfuscatorBuilder
type.
On 2011/08/02 17:43:26, rjrjr wrote:
Visits an RF to create itself? "...its associated {@link
Deobfuscator}..." yes?
Done.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/DescriptorBuilder.java
File
user/src/com/google/web/bindery/requestfactory/apt/DescriptorBuilder.java
(right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/DescriptorBuilder.java#newcode34
user/src/com/google/web/bindery/requestfactory/apt/DescriptorBuilder.java:34:
* Builds descriptors from TypeMirrors for both simple types and methods.
On 2011/08/02 17:43:26, rjrjr wrote:
These descriptors are used by {@link ...}
Done.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
File
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
(right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java#newcode50
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java:50:
* output jar and the binary names of RequestFactory interfaces that
should be
On 2011/07/29 00:53:51, tbroyer wrote:
Out of curiosity: why an output *jar* and not an output folder? (or
giving the
user the choice).
Using a folder would allow outputting to a WAR's WEB-INF/classes
(before
packaging the WAR of course) or, when building using Maven, outputting
to
target/classes or target/generated-classes (whatever is best for
Maven) so the
generated classes can be used by tests (which are run before the code
is
packaged into a JAR, and adding a JAR to the classpath that is not a
dependency
might not be practical, if at all possible; it's late here, so I
haven't checked
how it could work).
Updated so that if the first argument is a directory, the classes will
be emitted as individual files.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java
File
user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java
(right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java#newcode27
user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java:27:
* Provides access to payload deobfuscation services.
On 2011/08/02 17:43:26, rjrjr wrote:
"...for both servers and clients."
Is this the place to mention what GWT clients do instead?
Done.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java#newcode37
user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java:37:
* processor as part of the build process.
On 2011/08/02 17:43:26, rjrjr wrote:
@link, @see
Done.
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/vm/impl/OperationData.java
File
user/src/com/google/web/bindery/requestfactory/vm/impl/OperationData.java
(right):
http://gwt-code-reviews.appspot.com/1503804/diff/1/user/src/com/google/web/bindery/requestfactory/vm/impl/OperationData.java#newcode52
user/src/com/google/web/bindery/requestfactory/vm/impl/OperationData.java:52:
public Builder setClientMethodDescriptor(String clientMethodDescriptor)
{
On 2011/08/02 17:43:26, rjrjr wrote:
nit: usually on a builder these are with*() methods
Done.
http://gwt-code-reviews.appspot.com/1503804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
