Fix package.info files Part 2

  • 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
    1. public void validate(String providedAPI, String apiOwner, String apiVersion)
    2. {
    3. if (Loader.instance().getModClassLoader().containsSource(this.getSource())) {
    4. FMLLog.bigWarning("The API %s from source %s is loaded from an incompatible classloader. THIS WILL NOT WORK!", providedAPI, this.getSource().getAbsolutePath());
    5. }
    6. // TODO Compare this annotation data to the one we first found. Maybe barf if there is inconsistency?
    7. }


    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:



    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!

    The post was edited 2 times, last by Speiger ().

  • ...


    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.