[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=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=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=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=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=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=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=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=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=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=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=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=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 the app, and
[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=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)
