On Mon, Apr 12, 2010 at 12:05 PM, Freeland Abbott <[email protected]>wrote:
> I wanted to ask the list a question, since we've looped back to an old > discussion at > http://code.google.com/p/google-web-toolkit/wiki/ResourceOracle about how > to treat overlapping source modules. > > The question is what to do if a GWT App inherits two (or more) modules that > have selective source inclusion in a given Java package. That is, they > don't just include *.java, but have some combination of <include> and > <exclude> subtags. What we do now is that the last-specified wins, which is > pretty clearly wrong; what we proposed a while ago is a fairly complicated > idea that nods to backwards compatibility of that broken spec; what I'm > arguing for is a setwise union. I'd be interested to know what a broader > straw poll would expect, and what use cases people can imagine for this. > > The first question is why you wouldn't just use *.java; I've thought of two > reasons for that: > > - Avoiding non-translatable code; in most cases, ideally, you'd just > refactor a "shared" package, but I've seen cases where shared DTOs were in > server packages, or where a previously vanilla Java library like > google-collections <http://code.google.com/p/google-collections/> was > retroactively partially used in GWT. (Note that I don't necessarily > advocate this; I'm not sure the google-collections was being *efficient > * in GWT, only that it was being used! Rodrigo's working on some > collections stuff that should promise efficiency in both languages.) > - Selective component inclusion, for example if you have a bunch of > small widgets in one foo.client.widgets package but want to inherit them > individually; your app might use one module pulling WidgetOne.gwt.xml and a > second module pulling SomethingElse.gwt.xml, both with different subsets of > foo.client.widgets > > One might argue that both "should" be solved by refactoring into different > packages, but I can understand why one might not in those two cases. > > > And next, I've thought of two use cases for the merging: > > - Src and test packages, which are generally in the same Java package, > - Again, the selective library inclusion > > But, it seems to me, that in all of those cases you end up wanting union. > If A inherits B and C, B includes Foo.java, and C excludes Foo.java, you > want A to see Foo.java 'cause it needs B and B needs Foo. > > So C's "exclusion" means "I don't need Foo unless something else does," not > "I can't accept Foo; keep it away from me." > > > I haven't come up with a scenario for the "keep it away from me" > interpretation, except those in which you're already toast. Anyone else? > How would you handle the following: A: include foo*.java, exclude b*.java B: include bar*.java, exclude foobaz.java I am assuming your union would be the following: - all foo*.java - all bar*.java Is that correct? It seems like maybe you would want to merge in the excludes as well so that the most specific rule applies, which would remove foobaz.java from the list. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using "remove me" as the subject.
