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.
You could always load multiple mappings by calling loadMapping()
multiple times (as in MCPC+), but now it is also supported for
command-line usage. --srg-in mapping1.srg --srg-in mapping2.srg...
equivalent to cat mapping1.srg mapping2.srg.
JarMapping now maintains an InheritanceMap, and will populate
from IInheritanceProvider, if given. This allows inheritance to
be cached either locally or globally (across different JarMappings).
setFallback() allows an IInheritanceProvider to be specified which
will be consulted when inheritance for a requested class is unavailable.
If it returns a value, the inheritance will be cached in the InheritanceMap.
Change data structure to a linked hash map, preserving insertion
order. This allows subpackages to be inserted into the package
map for remapping, before their parent package. For example,
A/B/C -> X and A/B -> Y. With the unordered HashMap data structure,
this was not possible (reliably). With LinkedHashMap, now it is.
Used to "preprocess" a class file, using the ASM tree API,
before remapping with JarRemapper. Right now it only
extracts the inheritance and adds to an InheritanceMap.
Code moved from MCPC+ PluginClassLoader.
JarMapping now contains the IInheritanceProvider and tryClimb()
instead of JarRemapper, to allow other remappers access to the
same inheritance traversal code.
The trailing slash was being remapped, causing incorrect package names.
Expected format is for example:
org/bukkit/craftbukkit/v1_4_6/ org/bukkit/craftbukkit/v1_4_R1
to replace org/bukkit/craftbukkit/v1_4_6 -> org/bukkit/craftbukkit/v1_4_R1
The trailing slash is only to disambiguate from class remaps in csrg.
Remap through only one inheritance provider, instead of a list of them.
The multiple inheritance provider lookup functionality (check each one,
in order, until one provider responds for the class name) is still
available, but refactored into a new InheritanceProviders class.
Simplifies the common case of only having one inheritance provider, and
also reduces the redundant looping code previously in JarMapper/InheritanceMap.
The inheritance map, as generated with --write-inheritance/-H, can now
be read using --read-inheritance/-H. It will be remapped through the
currently loaded inverse mapping before supplying the inheritance provider.
Example usage:
java -cp target/SpecialSource-1.3-SNAPSHOT-shaded.jar net.md_5.specialsource.SpecialSource --shade-relocation net.minecraft.server=net.minecraft.server.v1_4_R1 --shade-relocation org.bouncycastle=net.minecraft.v1_4_R1.org.bouncycastle --srg-in ../jars/1.4.7/cb2obf.csrg --in-jar ../IncompatiblePlugin/target/bukkit-sample-plugin-0.5.jar --out-jar /tmp/sp/out.jar -h /tmp/h
where the inheritance map was previously generated using:
java -cp target/SpecialSource-1.3-SNAPSHOT-shaded.jar:mcpc-plus-1.4.7-R0.2-SNAPSHOT.jar net.md_5.specialsource.SpecialSource --srg-in ~/minecraft/1.4.x/jars/1.4.7/cb2obf.csrg --live --write-inheritance /tmp/h
Only includes mapped classes in the parents, and only includes entries
for classes which have relevant parents (extends/implements classes).
Shrinks inheritance map on MCPC+ build 73 by 279 lines.
