We're now using java_import_external instead of maven_jar. This allows
us to specify the relationships between jars, thereby allowing us to
eliminate scores of vendor BUILD files that did nothing but re-export
@foo//jar targets, thus addressing the concerns of djhworld on Hacker
News: https://news.ycombinator.com/item?id=12738072
We now have redundant failover mirrors, which is a feature I added to
Bazel 0.4.2 in ed7ced0018
A new standard naming convention is now being used for all Maven repos.
Those names are calculated from the group_artifact name using the
following algorithm that eliminates redundancy:
https://gist.github.com/jart/41bfd977b913c2301627162f1c038e55
The JSR330 dep has been removed from java targets if they also depend
on Dagger, since Dagger always exports JSR330.
Annotation processor dependencies should now be leaner and meaner, by
more appropriately managing what needs to be on the classpath at
runtime. This should trim down the production jar by >1MB. As it stands
currently in the open source world:
- backend_jar_deploy.jar: 50MB
- frontend_jar_deploy.jar: 30MB
- tools_jar_deploy.jar: 45MB
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143487929
I intend to configure ExpandRecurringBillingEventsAction in production in the near future, but until I verify that there's a 1:1 match between OneTimes expanded via SQL and OneTimes expanded via MR, filter the MR-synthetic OneTimes from the billing data view SQL.
I confirmed that this is the only script that consumes data from OneTime.
(Note that the best way would be to check for the SYNTHETIC flag, but syntheticCreationTime has a value iff the flag exists, and parsing the flags field is a relative pain in the neck compared to checking for null -- this is temporary.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143108200
We have wound up with a few domains with invalid transfer data; the transfer status is SERVER_CANCELLED, but the other data is missing. This tool should set the transfer data for the specified domain back to null in the database.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140883792
This makes the associated nomulus tool commands correctly return error
exit codes when the server-side component fails. This improves
scriptability.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140543216
Soy is gaining support for parsing/validating html structure and as such a number of patterns will start getting rejected by the parser. This change fixes newly errant soy templates by:
* transforming '<' characters that are not part of html tags to '<'
* inserting whitespace following tag names so that they are unambiguous
* changing templates not rendering html to kind="text" so html rules don't apply
* fixing control flow such that all tags (and quoted attribute values) are completely defined within a single control flow block. In some cases this required extracting {let..} vars or whole templates and in others it required duplicating conditions.
* removing stray unmatched quote characters in html tags.
* fixing incorrectly written html comments
LSC: https://docs.google.com/document/d/18MLrX8kUVzYGe1dBaSfh1kcQ_1UB02QHOk4KZtvHkIc/edit#
Tested:
$ blaze test //third_party/java_src/gtld/java/google/registry/flows:all //third_party/java_src/gtld/java/google/registry/tools/soy:all
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140475284
This would have saved me 2+ hours yesterday of mucking around
in datastore and manually copying out the xml bytes so that
I could base64decode them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139472542
While I am doing this, promote LoadAndResaveEntityCommand from
javascrap to the main tool since it's repeatedly been useful, and
rename it and update its documentation to better reflect the
difference between that command and the one I am adding.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139460841
This prevents a potential blind write scenario in which something else has concurrently modified the EppResource in between load and save, and those changes then get overwritten.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138911873
A transient 404 on entity save interrupts a long-running run of this command.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138400654
I added shared base classes to all of the Fee extension types that
make it possible to fully ignore the version in the flows. (You
ask for a FeeCreateCommandExtension, for example, and you get one
without having to worry about which). This is an improvement over
the old code that asked you to provide a list of possible fee
extensions and then ask for the first one in preference order.
As part of this I was able to make the Fee implementation a bit
simpler as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137992390
*** Original change description ***
Remove deprecated methods with Guava 20 release
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137945126
As part of this change, built out a KeyValueMapParameter from the existing TransitionListParameter in order to enable other Map types in commands (two of which are used in CreateLrpTokensCommand).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137476564
This allows separate Bazel projects to reference Nomulus as an external
repository. They can then copy the []
directory structure into their own project and customize the Action
and Module lists for the GAE modules in their own deployment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136863886
It's provided in ToolsRequestComponent, so it absolutely should be running on
the tools service. This was just a flat-out bug.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136630743
Compile-time constant inlining may interfere with JCommander's processing if a field is made final - @ParametersDelegate fields are particularly misleading. Remove the one instance of that and add warning comments elsewhere. See
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136469351
This is to better distinguish between an LRP "token" (the string passed along in EPP) and the datastore entity that contains the token and all metadata.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135943480
This changes everything with external visibility beyond the codebase
(i.e. the name of the compiled binary and the documentation that refers
to it). It does not change a lot of things internal to the codebase,
i.e. the "RegistryTool" class didn't change its name. We can rename that
in a subsequent CL if we want to.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135022087
This change consolidates gtech_tool into registry_tool. Since App Engine has
no actual ACLs on the remote API (any access is essentially root access), we're
removing this to avoid giving the impression to users that gtech_tool is truly
locked down from a security perspective compared to registry_tool.
In addition to merging GtechTool.COMMAND_MAP into RegistryTool.COMMAND_MAP, this
change also removes the {create,update}_sandbox_tld commands (which only made
sense for gtech_tool) and removes references to gtech_tool in the documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134828710
This improves the tests by:
1) Adding tests for alphabetical ordering of the command maps, to keep them
organized, and fixing existing mis-orderings. Note that this is a no-op
test for RegistryTool since it uses ImmutableSortedMap (to resort the
commands after inserting GtechTool.COMMAND_MAP), but it'll be relevant
in the upcoming CL when they get merged. I changed GtechTool.COMMAND_MAP
to use regular ImmutableMap.
2) Checking that RegistryTool.COMMAND_MAP (the full map, after the existing
GtechTool.COMMAND_MAP has been merged in) contains the exact same set of
commands as all the concrete classes implementing Command that we can find.
This is a stronger test than what we had before, which just checked that
every Command class appeared in RegistryTool (i.e. that RegistryTool's
commands are a superset of all Commands found). You'd think that it'd be
impossible for RegistryTool to contain commands that aren't in the set of
Commands we found, but it is if we're not searching for commands properly,
which we weren't (we were only checking within the .tools package and not
within any subpackages (e.g. tools.javascrap). This has now been fixed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134451859
Also creates a new package named 'batch' to house it.
TESTED=I deployed it to alpha, sent a POST request to the task URL, and it
successfully ran the [].
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134332999
The default is to support GET, which doesn't work with cron fanout which only
uses POST.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134284855
This refactors the GetEppResourceCommand hierarchy a bit so that instead of
using the type param on the class to do implicit loading (which doesn't
work that well any more for domain applications anyway), we just do the
loading in each child class and rely on the parent class only for printing
and setting common flags.
I did this to make it possible for loadByForeignKey() to have strong typing
(in a future CL), but I think this changes stands on its own merits for
making the logic here more straightforward and actually somewhat shorter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134115072
This refactors LoadAndResaveCommand a bit so that it's more straightfoward
and just switches on an enum to determine the resource type. This has the
pro of actually making the command line flag friendlier anyway.
Also changed how it handles a non-existent (or non-active) resource so that
it throws an IAE rather than silently doing stageEntityChange(null, null).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134113671
It is replaced by loadByForeignKey(), which does the same thing that
loadByUniqueId() did for contacts, hosts, and domains, and also
loadDomainApplication(), which loads domain application by ROID. This eliminates
the ugly mode-switching of attemping to load by other foreign key or ROID.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133980156
It's best to be consistent and use the same thing everywhere. "clientId" was
already used in more places and is shorter and no more ambiguous, so it's the
logical one to win out.
Note that this CL is almost solely a big Eclipse-assisted refactoring. There are
two places that I did not change clientIdentifier -- the actual entity field on
Registrar (though I did change all getters and setters), and the name of a
column on the exported registrar spreadsheet. Both would require data
migrations.
Also fixes a few minor nits discovered in touched files, including an incorrect
test in OfyFilterTest.java and some superfluous uses of String.format() when
calling checkArgument().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133956465
This removes the countless lines of the form "[null, []]" in registry_tool diffs
that are an artifact of the way we handle nulls in Objectify.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133409440
Command allows for both one-off creation and bulk import of assignees via file (the latter will be used for the initial import from Play Store).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133048360
