If checking="true" on them, they generate their code to a String instead of a file, and compare that
against existing output. If any generation would produce changes, the build is failed.
As a side effect, generation will now only write files if it's going to modify them, which should
eliminate some spurious compiling.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6349 542714f4-19e9-0310-aa3c-eee0fc999fb1
obtain containment and a stack of specifically typed outer class references to
accomplish what we need without misleading casts.
This will require changes to Yohoho which I shall make forthwith.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6320 542714f4-19e9-0310-aa3c-eee0fc999fb1
1. CrowdPermissionPolicy is an object that lives inside a BodyObject, thus it
cannot use server services like dependency injection, nor BodyLocator. However,
that's not a problem because it will never be used by a ClientObject that is
not a BodyObject. If there were a way to enforce with parameterized types that
it only ever be used in conjunction with a BodyObject, I'd do that, but
parallel inheritance hierarchies are not something that any OO type system I'm
aware of can reason about.
2. ClientResolver and its children are not singletons. One is created for each
client resolution process.
I have certainly fallen prey to the same errors during enthusiastic reactions:
it looks like a rose, it has thorns like a rose, oh wait, it's a blackberry.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6319 542714f4-19e9-0310-aa3c-eee0fc999fb1
from BodyObject, then it's your responsibility to make sure that your
BodyObject carries your Crowd permissions. Checking the ClientObject for your
Crowd permissions and then using those on your (separate) BodyObject is too
weird.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6318 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Rename PrefixServer.Module classes to PrefixModule. They all implement guice's Module, and it's
hard to pass a class around as its interface if they share a name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6303 542714f4-19e9-0310-aa3c-eee0fc999fb1
the real source code. That's where reusable classes live. Amazing!
Also cleaned up some build.xml bits and nixed the Retroweaver stuff. I thought
we might have still been using that, but then I saw the hardcoded path to
/usr/local/jdk1.4 and knew that it couldn't be so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6285 542714f4-19e9-0310-aa3c-eee0fc999fb1
The help message for /help <command> was using the translated/aliased string,
which meant that you had to have a usage translation for each command alias.
This became unmaintainable in Project X, where we had artists adding emotes
with lots of aliases, and I'm guessing it was booched in the Y!PP translations,
since they seem to lack translations for things like m.usage_escuchar. Let's
instead use a usage message based on the untranslated command, then compose
the actual command used into that (for aliases). This should be mostly
backwards-compatible, but I will be updating Yohoho and Bang in addition to
Project X: this involves replacing the command name in the usage translations
with {0} and returning getUsage(command) instead of "m.usage_blabla".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6248 542714f4-19e9-0310-aa3c-eee0fc999fb1
ActionScript bits remain belligerent, but the Java stuff is mostly shipshape.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6222 542714f4-19e9-0310-aa3c-eee0fc999fb1
Charlie Groves