Fix package.info files Part 2

Speiger · Aug 8th 2016

Quote

(Quoting Player)
You are wrong, inform yourself better or stop bugging us with poorly researched nonsense.

The warnings come directly from "if (Loader.instance().getModClassLoader().containsSource(this.getSource()))", which effectively just checks for coremods through the class loader differences.

Well to answer is actually wrong. What you are showing is simply a Duplication preventer in the ModAPI manager. So that a mod can not register the same APIPartName (VariableName: provides) twice, and the part you are showing is simply the preventation that if multible mods share the same API Files like RF API or IC2API that no error gets throwen.

Since all your packageInfo files did have the same Provides name it will throw the error because the mod was already added to the preventation System and it will throw then the error...

Instead of looking at this function:

Code

public void validate(String providedAPI, String apiOwner, String apiVersion)
        {
            if (Loader.instance().getModClassLoader().containsSource(this.getSource())) {
                FMLLog.bigWarning("The API %s from source %s is loaded from an incompatible classloader. THIS WILL NOT WORK!", providedAPI, this.getSource().getAbsolutePath());
            }
            // TODO Compare this annotation data to the one we first found. Maybe barf if there is inconsistency?
        }

You should have lookt at the code behind it and you would have noticed the error you made in your head!

Here is the code that is actually throwing it:

Code

public void registerDataTableAndParseAPI(ASMDataTable dataTable)
    {
        this.dataTable = dataTable;




        Set<ASMData> apiList = dataTable.getAll("net.minecraftforge.fml.common.API");




        apiContainers = Maps.newHashMap();




        for (ASMData data : apiList)
        {
            Map<String, Object> annotationInfo = data.getAnnotationInfo();
            String apiPackage = data.getClassName().substring(0,data.getClassName().indexOf(".package-info"));
            String providedAPI = (String) annotationInfo.get("provides"); //HERE IS THE THING WHERE THEY GET THE PROVIDES NAME!
            String apiOwner = (String) annotationInfo.get("owner");
            String apiVersion = (String) annotationInfo.get("apiVersion");
            APIContainer container = apiContainers.get(providedAPI); //HERE THEY DO CHECK IF THE NAME IS ALREADY PROVIDED
            if (container == null) //IF NOT HE IS ADDING IT!
            {
                container = new APIContainer(providedAPI, apiVersion, data.getCandidate().getModContainer(), VersionParser.parseVersionReference(apiOwner));
                apiContainers.put(providedAPI, container);
            }
            else
            {
                container.validate(providedAPI, apiOwner, apiVersion); //IF ITS ALREADY ADDED ITS CHECKING IF THE MOD IS ALREADY IN THE LIST
            }
            container.addOwnedPackage(apiPackage);
            for (ModContainer mc : data.getCandidate().getContainedMods())
            {
                String embeddedIn = mc.getModId();
                if (container.currentReferents.contains(embeddedIn)) 
                {
                    continue;
                }
                FMLLog.fine("Found API %s (owned by %s providing %s) embedded in %s",apiPackage, apiOwner, providedAPI, embeddedIn);
                if (!embeddedIn.equals(apiOwner))
                {
                    container.addAPIReference(embeddedIn);
                }
            }
        }
  }

Display More

So please tell me again that i am wrong player? Because you used all the time in the Package.info class the same name causing this issue!

Player · Aug 8th 2016

...

What you are describing there is merely another bug in the validation logic, FML confuses general validation (the class loader check) with validating against existing copies of the same annotation (unimplemented owner/version consistency check). It doesn't make any sense to not always do the class loader check, which in itself is conceptually broken since it's not applicable to APIs contained in their owner mod jar, but only mods using foreign API.

While unfixed this issue will fail to execute the check and thus hide the warning if there's only one instance of every involved provided API. The problem isn't declaring identical APIs like IC2 did, not doing so is just a workaround, which breaks as soon as someone else ships our API.

@API is and remains severely broken regardless both from a design and implementation POV. The only feature it's ever been good and initially intended for - implicit mod ordering - doesn't help IC2 as its coremod part makes it load as early as possible anyway.

Share