Yep, sounds like the test stuff I had in mind - for a quick demo I'll set up a repo, put some "libraries" and "gwt" jars/boms into it, and then make a bunch of sample projects. The "gwt jars" will have some service loader wiring, and the sample projects will check to see which jars they end up with, so that we can see which configurations cause which surprises.
Roughly, I'll deploy * LibraryWithNewGwt * LibraryWithOldGwt * LibraryWithBomAndNewGwt * LibraryWithBomAndOldGwt * LibraryWithTransitiveOldGwt (two flavors of this, one for each of the old gwt above) * LibraryWithTransitiveNewGwt (again, two flavors) then try to build projects with old or new gwt, plus 1-2 of the libraries above. If a project ever detects more than one gwt version, we'll fail that, and go from there. > > I'm worried that this two way relocation (o.g:*:2.9.0 relocated to > c.g.g:*:2.9.0, then c.g.g:*:2.10.0 relocating "back" to o.g:*:2.10.0) might > cause more problems than it solves. > Also, referencing a relocating POM will print a warning in the console (at > least for Maven, AFAICT) so you don't actually want to use o.g *before* it > actually exists. Good point - perhaps we just push a o.g:gwt:2.9.0 bom then, and encourage switching to just that? Same idea as before - projects can future proof themselves and move to this BOM, then only have to change its version in the BOM declaration to be correctly updated. This does miss out on some of the benefits though. Will hold off exploring until the above experiment has some results to share. > > One thing we could possibly do to detect such cases would be to add some code > the Main classes (Compiler, DevMode, CodeServer, JUnitShell) that would look > for some duplicate resource on the classpath, or even look for all the > com/google/gwt/dev/About.properties content and warn or fail if it finds > differing gwt.version properties in there (unfortunately this is in gwt-dev > which has fewer risks of being duplicated than gwt-user). > > So, my plan would be: > * test relocation, without overthinking it, and detecting limitations; then > we can refine the plan > * add a check to detect duplicated gwt-user on the classpath when running > GWT tools Yeah, I was thinking about this - It would be nice if we could go back in time and add some nice version sentinel that can be scanned for across all jars, but About.properties is as good as anything. Confirming gwt-dev is current doesn't tell you much (plenty of libraries only use gwt-user), but hopefully it will catch the important cases. Probably should augment the above samples to have another axis: gwt-user, or gwt-user+gwt-dev on each library. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9878fe9-4880-4722-984e-dbf1d8aca600%40www.fastmail.com.
