Normally, loadMappingsDir() loads:
obf -> num -> pkgmcp
but with numericSrgNames, it loads:
pkgmcp -> num
where:
obf = obfuscated "notch" names
num = numeric "srg" names
pkgmcp = descriptive "csv" names
This implementation could probably be improved further.
Compatibility Note: --numeric used to load these mappings:
obf -> num
that is, ignoring the fields/methods.csv. But this turned out not to
be too useful. You can still get this mapping with ignoreCsv=true, but
now numericSrgNames and --numeric loads the much more useful mapping:
pkgmcp -> num
Useful for targetting FML runtime deobfuscation.
Not used by CSVMappingTransformer, since the CSVs only contain:
func_###,newname
field_###,newname
with no class name, but it could be used by other load transformers.
Since AccessMap never downgrades visibility, 'private' in AT is
effectively equivalent to 'no change'. Useful in case you want to
change other flags but not the visibility. Accept '*' as private.
In addition to filenames and URLs, loadAccessTransformer(String) now
accepts the literal "pattern:" followed by an access transformer line.
Useful for adding individual transformations without a new _at.cfg.
Now will only upgrade, from private->default->protected->public.
Useful for modifying access with wildcards, e.g. classname.* protected
to change all fields in the class to protected -- except those which
are already public. This matches FML's access transformer behavior.
Allows for easily changing arbitrary symbol access flags. Supports
FML *_at.cfg access transformer file format loading in AccessMap.
Multiple AT's can be merged together and applied simultaneously
from the remapper 'preprocessor' class. Symbol visibility, final,
as well as any Java access flag can be set or cleared with +/-.
The remapped jar is altered and will fail to validate against
the included signatures from the original jar, if any. Normally
not a problem, you can compile against the remapped jar as a library
with no errors. However, when loading the jar from Maven (hit with
the Forge jar), signature validation will fail. Stripping the
signature files fixes this.
* Add getResource(), extracted from getClass()
* Remove getInputStream(), using getResource() instead
* Change getEntries() to getEntryNames(), hiding JarEntry
* Store filename for getFilename()
Mappings or jars downloaded from http URLs given to --srg-in or
--in-jar, --first-jar, --second-jar, will be cached locally in
a temporary directory, and reused on subsequent invocations if
present. The cache can be invalidated with --force-redownload.
Instead of in the command-line interface.. this allows
other code providing an interface to SpecialSource to
easily pass user-supplied options for loading mappings.
Normally, --srg-in on a directory will load joined.srg or
client.srg and server.srg, translated through fields.csv,
methods.csv, and packages.csv, if available. --numeric will
ignore fields.csv and methods.csv, remapping the jar to
the numeric "srg" names instead of descriptive "csv" names.
(packages.csv will still be used if it exists; if you want
flat packaging then specify joined.srg to --srg-in directly.)
You can now provide an HTTP URL to --in-jar and
it will be downloaded to a temporary file before
remapping. Example:
java -jar target/SpecialSource-1.3-SNAPSHOT-shaded.jar --in-jar http://assets.minecraft.net/1_4_7/minecraft_server.jar --out-jar /tmp/net.jar --srg-in ../MinecraftForge/mcp/conf/
packaged.srg is created by FML/MCP from joined.srg
and packages.csv. Now that we support reading packages.csv,
remove support for packaged.srg; one fewer codepath.
If packages.csv is found in a mapping directory, the
classes in .srg will be mapped through it. This is an
alternative to reading packages.srg, which isn't present
in the FML distribution (only joined.srg+packages.csv).
When remapping Minecraft + Forge, was failing with:
Exception in thread "main" java.util.zip.ZipException: invalid entry compressed size (expected 13048 but got 13084 bytes)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:248)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:343)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:360)
at net.md_5.specialsource.JarRemapper.remapJar(JarRemapper.java:141)
at net.md_5.specialsource.SpecialSource.main(SpecialSource.java:220)
Full details: https://gist.github.com/agaricusb/5036166
To fix this, we always create a JarEntry. Explanation from:
http://javahowto.blogspot.com/2011/07/how-to-programmatically-copy-jar-files.html
It usually occurs when text file entries in the source jar file contain some non-ASCII characters such as ^I ^Z ^D ^C. Some common files are META-INF/COPYRIGHT.html, META-INF/LICENSE.txt, etc, probably because these files were created in a non-ASCII editor but saved as text files. Open them in vi or vim to see these offending characters. To avoid this type of ZipException, always create a new JarEntry with the same name, and pass it to putNextEntry() method. Do not pass the existing jar entry from the source jar file to putNextEntry() method.
Removed the ^/@-style input specifications, in favor of
command-line options (which apply to all mappings loaded):
--in-shade-relocation: applies to srg-in input names
--out-shade-relocation: applies to srg-in output names
--reverse: reverses srg-in input/output names
Output shading relocation is useful if remapping through
--srg-in obf2cb.srg, and you want versioned names to match CB.
Example from packaged.srg:
PK: . net/minecraft/src
PK: com com
PK: net net
PK: net/minecraft net/minecraft
PK: net/minecraft/client net/minecraft/client
PK: net/minecraft/server net/minecraft/server
SpecialSource package remaps currently are class prefix matches,
taking precedence over class remaps. So net->net would match all
net.* classes when using reversed MCP (for reobfuscation), causing
no classes to remap. However the current behavior is useful for MCPC+,
remapping entire package hierarchies. Probably both behaviors should be
supported at some point, but until they are, disabling .srg PK:.
--srg-in ^filename will load the mappings as if they were reversed.
This is a decoration on the filename instead of a separate command-
line option flag so it can apply to the particular mapping file,
when loading multiple mappings simultaneously.
You can now specify an MCP config directory with --srg-in and
the .srg will be loaded along with the fields.csv and methods.csv
mappings, providing descriptive "csv" names instead of the
numeric "srg" names. Example usage:
java -jar target/SpecialSource-1.3-SNAPSHOT-shaded.jar --in-jar ../jars/minecraft_server-147.jar --srg-in ../MinecraftForge/mcp/conf/ --out-jar /tmp/minecraft-server-pkgmcp.jar
For compiling mods against the minecraft-server-pkgmcp.jar
as a library, an alternative to recompiling all of Minecraft
by using MCP (much faster, like compiling Bukkit plugins).
Note: if the fields.csv and methods.csv are not present, the
numeric "srg" names will be loaded instead.
JarMappings loaded from disk are now transformed through a
JarMappingInputTransformer interface, which can arbitrarily
transform classes on loading. Currently only implemented
by ShadeRelocationSimulator.
