rmannibucau commented on PR #374: URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1828410981
Strictly speaking: * IDE was unusable before (was lost between java version) so guess it is kind of a limitation of such setups * I did it when working on the PR so I assume you just didnt tune the compiler release version of the module? * enforcer has several pitfalls can be one but not sure why it would be worse than the mjar flavor, it stays java (actually what we do since > 10 years) * This is *not* broken, any fatjar is in this case and it is java friendly, actually MJAR is this kind of jar However mjar enforces: * more work on the jvm (classloading) * more work (or blocker) on any consumer that uses an IoC and scanner * more work (or blocker) on any consumer not using a flat classpath or classloader compatible with mjars (most of them actually, keep in mind EE does not know about modules and mjar yet, or several spring boot packaging flavors ignore it for ex) If the issue is just about mixing bytecode major version we can have jdk module (release=8) depending on jdk11 one and be it, would probably help with IDE issue too (for idea at least). That said I agree with your original analyzis that the IoC should skip the not loadable component (jdk8 there) and compiling everything with java 11 is the simplest, the 17/21 new API can be handled with reflection quite easily so sounds like the best compromise to me too. You mentionned sisu can break that but I guess we should just ensure it stays a feature either with a global or specific flag (ignorable classes or alike). -- 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
