I'll help Pascal with the changes, but it might be good to get a few more comments before changing too much. It *might *not be trivial for Benchmark to subclass the new Strategy because it does its own thing as well, but it shouldn't be too difficult.
I agree that the annotation should override existing properties. I vote for @WithBindingProperties for the annotation name. Thanks, John LaBanca jlaba...@google.com On Fri, Sep 25, 2009 at 1:41 PM, Bruce Johnson <br...@google.com> wrote: > On Fri, Sep 25, 2009 at 1:19 PM, Pascal Muetschard <pmuetsch...@google.com > > wrote: > >> 1) What happens if the module returned by getModuleName() already >> specifies a fix value for a given property? More generally, how should one >> think about how these annotations dovetail with the settings in the module >> config? >> >> The annotation will override what is defined in the module. I think that's >> what is expected and "it just works". >> > > Makes sense. Normally, when you <set-property> you can specify multiple > values (which often generates multiple permutations, though not always). > Seems like the annotation should support that if it doesn't. > > 2) The terminology is different than we've used in the past. Granted, we >>> haven't been very consistent with the term for "deferred binding properties" >>> (e.g. we've also called them "client properties"), but we've never called >>> them "module parameters". I know that doesn't make for a nice annotation >>> name, but I do want to avoid introducing yet another name for the same >>> concept. >>> >> >> Good point. I will do the rename and publish another patch. >> > > Sadly, I'm not positive what the right name should be. Perhaps > @WithClientProperties? > > I'd like to hear from others as to the best term. > @WithDeferredBindingProperties seems too weighty. > > >> 3) Would these annotations apply to the benchmarking subsystem? Should >> they? Could they? >> >> Yes it could. The simplest way would be to change the benchmark >> JUnitShell.Strategy to extend the new strategy. I don't know the benchmark >> system well, so I didn't want to change it. If somebody that does know the >> benchmark system well could look at this, I'd be more than happy to help... >> > > I'd really like to look into this at the same time. It's always so much > harder to find time to go back and retrofit these kinds of enhancements than > to just add them uniformly when they first go in. > > @John L: Thoughts? Could you point Pascal in the right direction w.r.t. > benchmarking? > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
