Sounds good. I don't know if we would really break anybody if we took out the -resources option now. If it's not an issue, let's clean it up now and take it out.
kathrin On Mon, Sep 28, 2009 at 4:26 PM, <[email protected]> wrote: > Okay, I've made these code changes. New patch coming soon. > > What shall we do about -resources? Is it okay to make it a no-op > immediately, or should we continue to support it a little while longer? > > > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2022 > File > dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java > (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2022#newcode48 > Line 48: public abstract List<SoycArtifact> getReportFiles(); > That would be a problem. For this particular class, it's not intended > that there are any other implementers, and my brief searches could not > turn any up. > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2024 > File dev/core/src/com/google/gwt/core/linker/SoycReportLinker.java > (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2024#newcode76 > Line 76: "Error while generating a Story of Your Compile", e); > Done, and everywhere else I could find a mention of "SOYC" or "Story of > Your Compile". I have not changed PerfLogger calls, class names, or > comments; those seem low priority. I have not changed the command-line > options, but we should do that once we figure out the new options. > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2036 > File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java > (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2036#newcode973 > Line 973: if (sizeBreakdowns != null) { > Now that I look at the code, however, it looks possible to specify > detailed info but not the lite info. In my mind, developers would never > ask for the extra detail without also getting the lite level of detail. > > It looks like a separate issue from this patch. However, I agree it > makes sense to either have the detailed soyc argument imply the regular > one, or to complain about the command-line arguments if the regular one > isn't already specified. > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2036#newcode1071 > Line 1071: } > Done. Changed to EmittedArtifact. > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2025 > File dev/core/src/com/google/gwt/soyc/Settings.java (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2025#newcode185 > Line 185: " present only for backwards compatibility; add any resources > directory to the classpath")); > How about: "present only for backwards compatibility; directory or jar > file with CSS, etc., resources" > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2027 > File dev/core/src/com/google/gwt/soyc/SoycDashboard.java (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2027#newcode77 > Line 77: + "java com.google.gwt.soyc.SoycDashboard options > stories0.xml[.gz] [dependencies0.xml[.gz]] [splitpoints0.xml[.gz]])"); > Even if it's invoked with the legacy syntax, the supplied resources > directory is ignored in this patch as it stands. Can we live with that? > > This arrangement should cover any normal use case where a report is > generated from cron or as part of a continuous build, because the > argument just specifies a prebuilt gwt-soyc-vis anyway. However, > developer setups will be broken for people developing on SOYC; I was > hoping both of those people could simply deal with the break. :) Is > there anyone else being broken if we stop supporting -resources? > > I can implement support for -resources if there's a reason. Can we live > without it? > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2020 > File tools/soyc-vis/build.xml (right): > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2020#newcode18 > Line 18: <fileset > dir="${gwt.root}/dev/core/src/com/google/gwt/soyc/resources"/> > On 2009/09/28 17:22:00, kathrin wrote: > >> Should this be here or rather in the dev's build file? >> > > I was thinking here, for the following reasons. First, the *output* is > going into gwt-soyc-vis.jar, even though the input comes from dev. > Second, eventually gwt-soyc-vis.jar should go away. I've been trying to > move things around so that when we're ready to do that, tools/soyc-vis > can simply be deleted. > > http://gwt-code-reviews.appspot.com/69801/diff/1001/2020#newcode18 > Line 18: <fileset > dir="${gwt.root}/dev/core/src/com/google/gwt/soyc/resources"/> > I was thinking here, mainly because the *output* is used to build > gwt-dev-soyc.jar. > > Additionally, gwt-dev-soyc.jar should eventually go away. At that > point, it's a little cleaner if we can simply remove tools/soyc-vis and > don't also need to update the dev build file. > > > http://gwt-code-reviews.appspot.com/69801 > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
