[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088066#comment-17088066 ] Michael Osipov commented on MRESOLVER-94: - [~sipka], do you want to pick up my branch and continue to work on it? This will resolve your problem. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088059#comment-17088059 ] Michael Osipov commented on MRESOLVER-94: - As far as I understand [this|https://stackoverflow.com/a/48526869/696632] you cannot modify anything. I will with {{pom.properties}} for now. The annotation processor is beyond my knowledge and time. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088013#comment-17088013 ] Robert Scholte commented on MRESOLVER-94: - Somebody needs to figure that out, but probably a system property (isolated for the compiler). > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087959#comment-17087959 ] Michael Osipov commented on MRESOLVER-94: - This sounds promising, but how does one pass the {{${project.version\}}} to the processor? > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087893#comment-17087893 ] Robert Scholte commented on MRESOLVER-94: - Current solutions depend on the MANIFEST.MF or pom.properties, both generated during packaging, which is a sign it is actually too late. We could use the template-maven-plugin, but that might not work good within the IDE. I think it should be possible to add a processor to the compiler to set a value of some (annotated) field. Haven't done this before, though, but it should remove any other hack, because the correct value is applied during compilation. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087677#comment-17087677 ] Michael Osipov commented on MRESOLVER-94: - [~rfscholte], can you have a look at MRESOLVER-94 in Maven Core repo. This is a way to fix this. The other affected classes are in Maven Model Builder which don't have access to {{RuntimeInformation}}. I'd duplicate (sigh) the code into Maven Builder Support and load from there if no {{Package}} instance is available. WDYT? > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087237#comment-17087237 ] Michael Osipov commented on MRESOLVER-94: - So this requires changes in Maven Core. There are four spots using {{#getPackage()}}. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945861#comment-16945861 ] Bence Sipka commented on MRESOLVER-94: -- I'm not entirely sure what you mean, but as far as I understand, yes. Reading the pom.properties file would be appropriate for solving this issue. In this case, retrieving the Package object for the class will be unnecessary. The META-INF/maven/org.apache.maven/maven-model-builder/pom.properties contains the property version with the value 3.6.2. Using it in both of the mentioned cases would be suitable. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945808#comment-16945808 ] Michael Osipov commented on MRESOLVER-94: - The version could likely be solved by reading the {{pom,properties}} whereas the package could be static. It would change anyway, will it? > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945727#comment-16945727 ] Bence Sipka commented on MRESOLVER-94: -- Disclaimer: I'm not very vell versed in the implementation details of the maven-resolver library. In my opinion, replacing the this.getClass().getPackage().getImplementationVersion() call with a hard coded value may work, however, it needs to be updated for every release. {code:java} String modelId = "org.apache.maven:maven-model-builder:" + "3.6.2" + ":super-pom";{code} Based on debugging, currently the 3.6.2 string is used under normal circumstances. This would need to be inserted in both DefaultReportingConverter initialization block, and DefaultSuperPomProvider.getSuperModel() function. I recommend to export the "3.6.2" constant to some utility class that holds this constant, and that can be updated easily in one place. However, I'm not sure what is the purpose of including the version number in that modelId, therefore the following could also work: Check if the Package is null. {code:java} Package pack = this.getClass().getPackage(); String modelId = "org.apache.maven:maven-model-builder:" + (pack == null ? "null" : pack.getImplementationVersion()) + ":super-pom";{code} Modify DefaultReportingConverter accordingly as well. The null-check modification is compatible with previous implementations, as it only results in avoiding the null checks, and doesn't have any other effect than avoiding the mentioned NPE. The hard-coded version modification will induce the maintenance burden of updating the version number for the newer releases. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945694#comment-16945694 ] Michael Osipov commented on MRESOLVER-94: - OK, thanks I will look into this. What is your recommendation to fix this issue? > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945661#comment-16945661 ] Bence Sipka commented on MRESOLVER-94: -- The code doesn't have packages in a way, that the ClassLoader that loads the maven-resolves classes, doesn't call ClassLoader.definePackage for the loaded classes. This will result in getClass().getPackage() to return null. Therefore, this.getClass().getPackage().getImplementationVersion() will result in a NPE. According to the documentation of Class.getPackage(), the method can return null, however the implementations in DefaultSuperPomProvider and DefaultReportingConverter doesn't handle this scenario. I don't use the default packages. An example for reproducing this: {code:java} public static void main(String[] args) throws Exception { Path jarpath = Paths.get("maven-resolver-fat-jar.jar"); try (JarFile jar = new JarFile(jarpath.toFile())) { ClassLoader cl = new ClassLoader(null) { @Override protected Class findClass(String name) throws ClassNotFoundException { ZipEntry entry = jar.getEntry(name.replace('.', '/') + ".class"); if (entry != null) { try (InputStream is = jar.getInputStream(entry)) { ByteArrayOutputStream baos = new ByteArrayOutputStream(); byte[] buf = new byte[4096]; for (int read; (read = is.read(buf)) > 0;) { baos.write(buf, 0, read); } byte[] classbytes = baos.toByteArray(); return defineClass(name, classbytes, 0, classbytes.length); } catch (IOException e) { } } return super.findClass(name); } }; Class defaultreportinconverterclass = cl.loadClass("org.apache.maven.model.plugin.DefaultReportingConverter"); System.out.println("App.main() " + defaultreportinconverterclass); System.out.println("App.main() " + defaultreportinconverterclass.getPackage()); defaultreportinconverterclass.getConstructor().newInstance(); } } {code} Minimal example for loading an affected class via a custom classloader from a fat JAR. The maven-resolver-fat-jar.jar contains all classes required by the maven-resolver to operate. The anonymous ClassLoader inner class loads the classes from the appropriate JAR entries. The program will produce the following output: {code:java} App.main() class org.apache.maven.model.plugin.DefaultReportingConverter App.main() null Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at example.saker.maven.support.App.main(App.java:191) Caused by: java.lang.NullPointerException at org.apache.maven.model.plugin.DefaultReportingConverter.(DefaultReportingConverter.java:56) ... 5 more {code} As you can see, a NullPointerException occurs when the DefaultReportingConverter class is being instantiated, as it will call this.getClass().getPackage().getImplementationVersion(). But due to the fact, that no definePackage is called by the ClassLoader, it throws a NPE. The same kind of error occurs when using DefaultSuperPomProvider. > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package
[jira] [Commented] (MRESOLVER-94) NullPointerException if no Package is defined for the current class
[ https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945325#comment-16945325 ] Michael Osipov commented on MRESOLVER-94: - Can you describe how your code does not have packages? Do you use the default package? > NullPointerException if no Package is defined for the current class > --- > > Key: MRESOLVER-94 > URL: https://issues.apache.org/jira/browse/MRESOLVER-94 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.4.1 > Environment: Windows 10, Java 8, custom classloading >Reporter: Bence Sipka >Priority: Minor > > When the maven-resolver and related classes are used with a {{ClassLoader}} > that doesn't define a java.lang.Package object for the loaded classes, the > library throws a {{NullPointerException}}. > Scenario: I'm using the maven-resolver classes to resolver artifacts from > various repositories. I package the app, and deploy it to a custom > environment where the {{ClassLoader}} for the app doesn't define a > {{Package}} for the loaded classes. In these cases, when the maven-resolver > library calls {{this.getClass().getPackage().getImplementationVersion()}} > then a {{NullPointerException}} will occurr. > The following classes are affected: > {{DefaultSuperPomProvider.getSuperModel():81}} > {{DefaultReportingConverter.:56}} > Code around the locations: > {code:java} > String modelId = "org.apache.maven:maven-model-builder:" > + this.getClass().getPackage().getImplementationVersion() + ":super-pom"; > InputSource inputSource = new InputSource(); > inputSource.setModelId( modelId ); > {code} > This exception makes the library unportable to different environments. > Workaround: > Implement a custom variant of the above classes that circumvent these parts > of the code. > Possible solution: > Null checks, and hard coding the version number. -- This message was sent by Atlassian Jira (v8.3.4#803005)