Yep
if you're interested in good debugging (in SDM?), take a look at the patch i linked? someone else noticed that stack traces break in SDM or any "i loaded my gwt module from another origin", and i also noticed that promise events don't work either in this case, but only in chrome
ha looks like we can, that's terrible
addMethodDefinitionStatement only wants JsExprStmts to be added to it
and only one, since outputDisplayName is expected to return a single thing
maybe a second set of statements in the emitMethodImplementation's if check instead
would like to check back in with @tbroyer, last i heard he was close to a satisfactory way of starting groupId migration, but i never heard back on how that went
@rdeangelis83
private void emitMethodImplementation(JMethod method, JsNameRef functionNameRef,
JsExprStmt methodDefinitionStatement) {
addMethodDefinitionStatement(method, methodDefinitionStatement);
if (shouldEmitDisplayNames()) {
addMethodDefinitionStatement(method, outputDisplayName(functionNameRef, method));
addMethodDefinitionStatement(method, outputFunctionNameProperty(functionNameRef, method));
}
}
private void generatePrototypeDefinitionAlias(JMethod method, JsName alias) {
JsName polyName = polymorphicNames.get(method);
JsExpression bridge = JsUtils.createBridge(method, polyName, topScope);
// Aliases are never property accessors.
generatePrototypeAssignment(method, alias, bridge, JsMemberType.NONE);
}
private JsExprStmt outputDisplayName(JsNameRef function, JMethod method) {
JsNameRef displayName = new JsNameRef(function.getSourceInfo(), "displayName");
displayName.setQualifier(function);
String displayStringName = getDisplayName(method);
JsStringLiteral displayMethodName =
new JsStringLiteral(function.getSourceInfo(), displayStringName);
return createAssignment(displayName, displayMethodName).makeStmt();
}
private JsExprStmt outputFunctionNameProperty(JsNameRef function, JMethod method) {
String displayStringName = getDisplayName(method);
JsStringLiteral displayMethodName =
new JsStringLiteral(function.getSourceInfo(), displayStringName);
JsObjectLiteral descriptor = JsObjectLiteral.builder(function.getSourceInfo())
.add("value", displayMethodName)
.build();
JsStringLiteral prop = new JsStringLiteral(function.getSourceInfo(), "name");
return constructInvocation(function.getSourceInfo(), "Object.defineProperty", function, prop, descriptor).makeStmt();
}try that out, i think it is close (plus or minus formatting)
Apparently it needed more tests: https://groups.google.com/g/google-web-toolkit-contributors/c/L2RMqglOEXo/m/kCNHSaMeBwAJ (as noted in the project readme too)
needing more tests in gradle at least suggests someone proficient in gradle (i have done a lot of work since we last talked, but still consider it to be too complex to learn without already understanding it)
i am not aware of any significant sbt usage of maven, and only minimal ivy usage
Ha, that experiment-5 looked like those "more tests" actually; and prompted doing an experiment-6 deploying Gradle Module Metadata for GWT itself to confirm the early conclusions (so that gwt-user brings a "dependency constraint" on gwt-dev; similar to having the GWT BOM being transitively depended on). There would still be issues for Maven users not using the GWT BOM, that would have to be dealt with "manually" (using exclusions).
But experiment-4 could be regarded as "enough" (particularly for a RC, for instance), or even experiment-3 (experiment-4 actually adds an o.g→c.g.g relocation for older versions, so can be added later)
ok - so to briefly summarize (and possibly glossing over details), the "missing final post" to the thread could be assumed to say something like:
- with proposal-5, the gradle experience is acceptable
- maven requires the use of a bom to be sane, we will need to aggressively push this to any projects that updates either its gwt dependencies or any libraries that it uses, so we need to enlist library publishers to push the bom
oh, why drop back to 3 or 4 if 5 is strictly better for the gradle cases?
Well, 5 is "exercising" 4 with some external libraries; so as far as GWT is concerned, we would be "doing 4". And "doing 4" requires "doing 3" first (or next, actually).
In terms of setting up the deployment for a new version, the aim is experiment-3 (it's identical experiment-4 and experiment-5). The additions of experiment-4 could be done separately to "make things better".
And iterating from that, adding Gradle Module Metadata (similar to what's been proposed for Guava, except we're not interested in the variants here: https://github.com/google/guava/pull/3683/files) implies releasing a new version (it shouldn't stop us doing a first RC without them though)
i readily admit to not understanding the implications of 5
https://github.com/tbroyer/gwt-relocation-tests#experiment-4 says
...with an additional relocation from org.gwtproject to com.google.gwt for version 2.9.0
which seems like "extra relocations", no?
oh i see, not extra relocations, but extra releases
Yes, that's what I was trying to say in the early conclusions with:
Using the org.gwtproject:gwt:2.9.0 BOM helps stay on GWT 2.9.0 without risking mixed com.google.gwt and org.gwtproject dependencies, by automatically downgrading the latter (to 2.9.0, which relocates to the former).
could i ask you to post such a summary on the mailing list, as a way to bring the topic up again, and we can make these changes in the repo in anticipation of a release? i also notice that you have a htmlunit/jetty/asm patch that you might want to merge, i have a draft, doesn't make sense for us to conflict on that (but i'll certainly assist in testing your commit if you'd like to proceed)
Well, I do not have an htmlunit/jetty/asm patch actually. If you're referring to the note in the https://github.com/tbroyer/gwt-relocation-tests#experiment-5, this project uses empty JARs, and I only modified the POMs 🤷