rmannibucau commented on PR #374: URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1829239333
@cstamas assuming MJAR works and is transparently handled by the *JRE* is wrong as I already mentionned. You are just lucky in your tests it was (side note: as war classloader was rarely used in (unit) tests, real runtime classloader is not too so we should be extremly cautious there). The JRE implementation sits in `JarFile` (`java.util.jar.JarFile#getEntry`) so as soon as you don't rely on that to locate `.class` binaries you are doomed. A simple case where it will not work whereas you can expect it to work is you explode your jars in a directory (recall early javaee 6 glassfish times? ;)) but basically any classloader not locating the classes with a jar file (think zipfile also handled it but no more sure) or using the exact ^^ API (like nested jars which preload in mem bytecode for ex) will not work. OSGi which pre-explode the zip in another location can have issue depending the impl and even EE can have issues depending the classloader itself. So overall I don't think it is s ane. Lastly, MJAR conserves half of the issues you have right now so not sure it solves anything. side note: we should make enforcer evolve to validate META-INF/versions/ classes against a defined bytecode cause today you are happy with it cause it is not seen but issue exists. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
