[
https://issues.apache.org/jira/browse/MRESOLVER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bence Sipka updated MRESOLVER-94:
---------------------------------
Description:
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.<init>: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.
was:
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.<init>: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 circument these parts of
the code.
Possible solution:
Null checks, and hard coding the version number.
> 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.<init>: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)
