Most likely your resources are either (a) being accessed via a path which ProGuard is changing when the package containing the resource is obfuscated, or (b) being dropped because they are not copied to the output JAR.
You should not need to be explicitly including the Java runtime classes in your configuration.
You might want to look at the following options:
-adaptclassstrings [class_filter] Specifies that string constants that correspond to class names should be obfuscated as well. Without a filter, all string constants that correspond to class names are adapted. With a filter, only string constants in classes that match the filter are adapted. For example, if your code contains a large number of hard-coded strings that refer to classes, and you prefer not to keep their names, you may want to use this option. Primarily applicable when obfuscating, although corresponding classes are automatically kept in the shrinking step too.
-adaptresourcefilenames [file_filter] Specifies the resource files to be renamed, based on the obfuscated names of the corresponding class files (if any). Without a filter, all resource files that correspond to class files are renamed. With a filter, only matching files are renamed. For example, see processing resource files. Only applicable when obfuscating.
-adaptresourcefilecontents [file_filter] Specifies the resource files whose contents are to be updated. Any class names mentioned in the resource files are renamed, based on the obfuscated names of the corresponding classes (if any). Without a filter, the contents of all resource files updated. With a filter, only matching files are updated. The resource files are parsed and written using the platform's default character set. You can change this default character set by setting the environment variable LANG or the Java system property file.encoding. For an example, see processing resource files. Only applicable when obfuscating.
And see http://proguard.sourceforge.net/manual/examples.html#resourcefiles for more detail.