[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] aspectjtools fail with NPE during maven build
|
@Raimondas: Please create an issue on
https://github.com/eclipse/org.aspectj/issues. The clearer and better
the description, the easier Andy can fix that eventually. If you can
attach a link to a reproducer project, even better. Maybe it would even
make sense to create two issues, one for the ZIP file thing that I could
reproduce by setting the property to a low value and one for the new
problem with failing compilation in AspectJ Maven. Thank you in advance.
@Tim: I never understood the developer and business value proposal of
JMS. Maintaining Eclipse plugins like AJDT is OSGi hell already, since
Java 9 it was successfully replicated right inside the JRE as JMS hell.
Everyone is just busy trying to keep or make their applications and
tools working despite JMS, even more so tools addressing cross-cutting
concerns, such as AspectJ, Byte Buddy etc.
--
Alexander Kriegisch
https://scrum-master.de
Timothy Spear schrieb am 19.02.2022 03:47 (GMT +07:00):
>
>
> I have never had a classpath that long, however I am finding due to module
> related logic gradually being enforced more by the JDK, that third party
> libraries are producing fewer "fat jars". The result has been my classpath
> has been growing over the past few years on a couple projects as I
> increment the versions of the third party libraries.
>
>
> Tim
>
>
> On Fri, Feb 18, 2022 at 3:11 PM Andy Clement <andrew.clement@xxxxxxxxx
> <mailto:andrew.clement@xxxxxxxxx> > wrote:
>
>>
>> Good digging Raimondas.
>>
>>
>> I added that openArchives limit hundreds of years ago due to giant
>> classpaths causing issues when working in eclipse as I recall. We have no
>> testcases that explore the limit.
>>
>>
>> > would you classify this as a bug or simply as a limitation and setting
>> the system property is the correct way too solve it?
>>
>> I think the intent was that if closed these would reopen themselves, so a
>> bug. Perhaps with module systems coming around in Java9 that introduced
>> 'other routes' to accessing the zipFile which have not been guarded with
>> the check to verify it is open - actually that is probably the problem.
>> Shouldn't be too hard to fix.
>>
>>
>> The information I saw raimondas share that gives us something to go on is
>> that it works with 1.9.4. I presume as you say it works with 1.9.4 that
>> it does *not* work with 1.9.5. That gives us a handful of issues to
>> review to see which one may be disturbing this area of code.Although one
>> of them is the scary "update to JDT for Java13" which may have brought
>> something in we aren't patching properly. We don't have great test
>> coverage for module scenarios, so if it is there, gonna be tricky to work
>> out without a repro.
>>
>>
>> Andy
>>
>>
>> On Thu, 17 Feb 2022 at 19:44, Alexander Kriegisch
>> <alexander@xxxxxxxxxxxxxx
>> <mailto:alexander@xxxxxxxxxxxxxx> > wrote:
>>
>>>
>>> Forget my questions about Java version and AspectJ Maven configuration,
>>> I simply forgot to scroll down to the original message. A reproducer
>>> project for the new problem would still be helpful, though. We have
>>> nothing to work with now, other than textual information. I can only
>>> speculate like before about java.lang classes or about you having a
>>> problem with duplicate classes on your classpath, maybe the ones from
>>> the original JAR and the unpacked and woven ones. I recommend that there
>>> is be a separate Maven module taking care of the customer-specific
>>> aspect weaving step, depending on the original JAR, unpacking and
>>> weaving it, producing a new JAT replacing it, and all the other modules
>>> only depending on the woven JAR, not on the original one. Otherwise, it
>>> could be like a lottery what the compiler and/or later the application
>>> runtime find first on the classpath.
>>>
>>> --
>>>
>>> Alexander Kriegisch
>>>
>>> https://scrum-master.de
>>>
>>>
>>> Alexander Kriegisch schrieb am 18.02.2022 10:09 (GMT +07:00):
>>>>
>>>> Great digging, Raimondas! I am impressed that you debugged so deeply
>>>> into AJC and found org.aspectj.weaver.openarchives. I never knew or
>>>> used that setting before.
>>>> ----------------------------------------
>>>>
>>>> Andy, if you want to reproduce the problem, just run a command like
>>>> this on JDK 9+ (on 8 you have to add JDK tools.jar to the classpath):
>>>> java -Dorg.aspectj.weaver.openarchives=20 -classpath "c:\Program
>>>> Files\Java\AspectJ\lib\aspectjtools.jar" org.aspectj.tools.ajc.Main -cp
>>>> "c:\Program Files\Java\AspectJ\lib\aspectjrt.jar" -8 Code.java
>>>>
>>>> You cannot call the ajc.bat or ajc shell scripts directly, because they
>>>> do not provide any way to pass JVM options. But of course you can set
>>>> _JAVA_OPTIONS before calling AJC, e.g. like this on Windows:
>>>> set _JAVA_OPTIONS="-Dorg.aspectj.weaver.openarchives=20"
>>>> ajc -cp "c:\Program Files\Java\AspectJ\lib\aspectjrt.jar" -8 Code.java
>>>>
>>>> Caveat: Do not set the value lower than 20, because then it will
>>>> default to 1000, see
>>>> org.eclipse.jdt.internal.compiler.batch.ClasspathJar#ClasspathJar:
>>>> private static int maxOpenArchives = 1000;
>>>> private final static int MAXOPEN_DEFAULT = 1000;
>>>> private static List openArchives = new ArrayList();
>>>> // ...
>>>> static {
>>>> String openarchivesString =
>>>> getSystemPropertyWithoutSecurityException("org.aspectj.weaver.openarchives",Integer.toString(MAXOPEN_DEFAULT));
>>>> maxOpenArchives=Integer.parseInt(openarchivesString);
>>>> if (maxOpenArchives<20) maxOpenArchives=1000;
>>>> }
>>>>
>>>> Anyway, this will immediately reproduce the problem and create an
>>>> ajcore dump:
>>>> java.lang.NullPointerException: Cannot invoke
>>>> "java.util.zip.ZipFile.entries()" because "this.zipFile" is null
>>>> at
>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.getModulesDeclaringPackage(ClasspathJmod.java:146)
>>>>
>>>> Andy, would you classify this as a bug or simply as a limitation and
>>>> setting the system property is the correct way too solve it?
>>>>
>>>> ----------------------------------------
>>>> Raimondas, with regard to the other problem, a reproducer would come in
>>>> handy. It looks like a JMS class-loading problem. At the moment I am
>>>> not sure why it would fail in 1.9.7 or 1.9.8, but pass in 1.9.4. For
>>>> debugging this, I think we need more details. Which JDK are you using
>>>> to build your application? What does the AspectJ Maven configuration
>>>> look like exactly? 1.9.4 is Java 12, i.e. I can infer you are compiling
>>>> to a byte code level no higher than that, maybe 11 or even 8. Do you by
>>>> any chance have any libraries or own code defining classes in the
>>>> java.lang package? The error message hints at something like that, but
>>>> I could be wrong.
>>>>
>>>>
>>>> raimondas@xxxxxxxxxx <mailto:raimondas@xxxxxxxxxx>
>>>> schrieb am 18.02.2022 01:27 (GMT +07:00):
>>>>>
>>>>>
>>>>> An update if anyone comes across this issue.
>>>>>
>>>>> I solved the NPE problem by providing
>>>>> -Dorg.aspectj.weaver.openarchives=2000 when running build (which is
>>>>> not documented anywhere by the way, only in aspectjtools source code).
>>>>> It turns out due to big number of classpath entries some of these
>>>>> entries are closed during processing:
>>>>>
>>>>>
>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar
>>>>>
>>>>>
>>>>> // AspectJ Extension
>>>>>
>>>>> private void ensureOpen() throws IOException { //line 403
>>>>>
>>>>> if (zipFile != null) return; // If its not null, the zip is already
>>>>> open
>>>>>
>>>>> if (openArchives.size()>=maxOpenArchives) {
>>>>>
>>>>> closeSomeArchives(openArchives.size()/10); // Close 10% of those open
>>>>> <-- closed and likely not re-initialized so that zipFile remains null
>>>>>
>>>>> }
>>>>>
>>>>> zipFile = new ZipFile(file);
>>>>>
>>>>> openArchives.add(this);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> However, after fixing this NPE I immediately run into another issue
>>>>> when using aspectjtools 1.9.7 and 1.9.8:
>>>>>
>>>>>
>>>>> [ERROR] Failed to execute goal
>>>>> org.codehaus.mojo:aspectj-maven-plugin:1.14.0:compile (default) on
>>>>> project xxx-app: AJC compiler errors:
>>>>>
>>>>> [ERROR] error at (no source information available)
>>>>>
>>>>> [ERROR] C:\Users\....aj:0::0 Type java.lang.Object is indirectly
>>>>> referenced from required .class files but cannot be resolved since the
>>>>> declaring package java.lang exported from module java.base conflicts
>>>>> with a package accessible from module <unnamed>
>>>>>
>>>>>
>>>>> which I solved by using aspectjtools 1.9.4.
>>>>>
>>>>>
>>>>> From: Andy Clement
>>>>>
>>>>> Sent: Tuesday, February 15, 2022 5:23 PM
>>>>>
>>>>> To: raimondas@xxxxxxxxxx ; aspectj-users@xxxxxxxxxxx
>>>>>
>>>>> Subject: Re: [aspectj-users] aspectjtools fail with NPE during maven
>>>>> build
>>>>>
>>>>>
>>>>> What you could do is clone aspectj and build it locally into your
>>>>> maven repo and use it (its pretty straightforward, build a
>>>>> 1.9.9-SNAPSHOT) - with a couple of changes:
>>>>>
>>>>> - get it to print the zipfilename when the zipfile is attempting to be
>>>>> created, which filename is causing us problems here? That will help us
>>>>> see which of the classpath references is tripping it up.
>>>>>
>>>>> - cope with unresolved zip file (null check), if you simply ignore the
>>>>> missing zipFile, does it all build just fine and you didn't need
>>>>> anything from that file?
>>>>>
>>>>>
>>>>> My suspicions are a classpath entry that isn't valid coming from
>>>>> somewhere.
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On Sun, 13 Feb 2022 at 23:49, <raimondas@xxxxxxxxxx> wrote:
>>>>>>
>>>>>>
>>>>>> So far I was not able to reproduce this issue with the minimal
>>>>>> example. The same setup works as expected – aspects build in a
>>>>>> separate library and then used as a library in a different module. In
>>>>>> a small scale project this works fine.
>>>>>>
>>>>>> Please also note that this same unchanged config (as in my prev post)
>>>>>> worked perfectly with jdk1.8 and plugin versions:
>>>>>> aspectj-maven-plugin v1.8, aspectjtools v1.9.4. The issue happened
>>>>>> after upgrade to Java 11 and plugin versions v1.14 and v1.9.7
>>>>>> (keeping previous v1.9.4 for the aspectjtools does not make any
>>>>>> difference).
>>>>>>
>>>>>>
>>>>>> I’ve tried with simplified aspectj-maven-plugin config to see if that
>>>>>> makes any difference:
>>>>>>
>>>>>> <plugin>
>>>>>>
>>>>>> <groupId>org.codehaus.mojo</groupId>
>>>>>>
>>>>>> <artifactId>aspectj-maven-plugin</artifactId>
>>>>>>
>>>>>> <version>1.14</version>
>>>>>>
>>>>>> <configuration>
>>>>>>
>>>>>> <complianceLevel>11</complianceLevel>
>>>>>>
>>>>>> <source>11</source>
>>>>>>
>>>>>> <target>11</target>
>>>>>>
>>>>>> <showWeaveInfo>true</showWeaveInfo>
>>>>>>
>>>>>> <verbose>true</verbose>
>>>>>>
>>>>>> <aspectLibraries>
>>>>>>
>>>>>> <aspectLibrary>
>>>>>>
>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>>
>>>>>> <artifactId>xxx-aspects</artifactId>
>>>>>>
>>>>>> </aspectLibrary>
>>>>>>
>>>>>> </aspectLibraries>
>>>>>>
>>>>>> </configuration>
>>>>>>
>>>>>> <executions>
>>>>>>
>>>>>> <execution>
>>>>>>
>>>>>> <goals>
>>>>>>
>>>>>> <goal>compile</goal>
>>>>>>
>>>>>> </goals>
>>>>>>
>>>>>> </execution>
>>>>>>
>>>>>> </executions>
>>>>>>
>>>>>> <dependencies>
>>>>>>
>>>>>> <dependency>
>>>>>>
>>>>>> <groupId>org.aspectj</groupId>
>>>>>>
>>>>>> <artifactId>aspectjtools</artifactId>
>>>>>>
>>>>>> <version>1.9.7</version>
>>>>>>
>>>>>> <scope>compile</scope>
>>>>>>
>>>>>> </dependency>
>>>>>>
>>>>>> </dependencies>
>>>>>>
>>>>>> </plugin>
>>>>>>
>>>>>> however, issue is still present.
>>>>>>
>>>>>>
>>>>>> The project where issue happens is a large project with hundreds of
>>>>>> modules and >1000 dependency libraries. There is a base platform and
>>>>>> client specific customizations on top of it using base platform APIs.
>>>>>> Some aspects are defined in the base platform (xxx-aspects) and used
>>>>>> as library in the platform customizations for a specific client. The
>>>>>> part with
>>>>>>
>>>>>> <weaveDirectories>
>>>>>>
>>>>>> <weaveDirectory>${project.build.directory}/classesToWeav</weaveDirectory>
>>>>>>
>>>>>> </weaveDirectories>
>>>>>>
>>>>>> simply holds class files that were extracted from the base platform
>>>>>> jars during the app build because they need to have client specific
>>>>>> aspects applied post compilation and then assembled into deployment.
>>>>>>
>>>>>>
>>>>>> I perfectly understand that without being able to reproduce issue
>>>>>> locally it is hard to say anything. To me issue seems more like what
>>>>>> I call “curse of the large systems” when factors you wouldn’t even
>>>>>> think of may cause unexpected problems. I’d appreciate any hints
>>>>>> based on your knowledge about the tools that are being used.
>>>>>>
>>>>>>
>>>>>> From: Alexander Kriegisch
>>>>>>
>>>>>> Sent: Sunday, February 13, 2022 7:00 AM
>>>>>>
>>>>>> To: aspectj-users@xxxxxxxxxxx
>>>>>>
>>>>>> Subject: Re: [aspectj-users] aspectjtools fail with NPE during maven
>>>>>> build
>>>>>>
>>>>>>
>>>>>> It is a bit difficult to debug a Maven POM without any code,
>>>>>> especially one with unusual settings like your mix of aspect library,
>>>>>> custom includes and custom weave directory. I wonder what those are
>>>>>> all for. I never use custom settings like those, even when using
>>>>>> aspect libraries.
>>>>>>
>>>>>> So please create an MCVE
>>>>>> <https://stackoverflow.com/help/mcve> on GitHub. I
>>>>>> need something to compile (and run after I fixed the build) in order
>>>>>> to reproduce your problem. I have never seen anything like it. Just
>>>>>> create a minimal Maven project with just as many modules as needed to
>>>>>> reproduce the error. In each module, there can be very simple aspect
>>>>>> and application code, I do not need your original source code. But it
>>>>>> should be reproducible. Then I can probably help you pinpoint the
>>>>>> root cause and maybe suggest an alternative approach or fix
>>>>>> something.
>>>>>>
>>>>>>
>>>>>> raimondas@xxxxxxxxxx schrieb am 12.02.2022 19:38 (GMT +07:00):
>>>>>>>
>>>>>>>
>>>>>>> We are doing migration of our project to Java 11 and got blocked by
>>>>>>> this aspectjtools fail with NPE during maven build. Context:
>>>>>>>
>>>>>>> 1. Java 11 (AdoptOpenJDK jdk-11.0.10.9-hotspot)
>>>>>>>
>>>>>>> 2. aspectj-maven-plugin v1.14
>>>>>>>
>>>>>>> 3. aspectjtools v1.9.7
>>>>>>>
>>>>>>> 4. pom.xml snippet
>>>>>>>
>>>>>>> <plugin>
>>>>>>>
>>>>>>> <groupId>org.codehaus.mojo</groupId>
>>>>>>>
>>>>>>> <artifactId>aspectj-maven-plugin</artifactId>
>>>>>>>
>>>>>>> <version>1.14</version>
>>>>>>>
>>>>>>> <configuration>
>>>>>>>
>>>>>>> <complianceLevel>11</complianceLevel>
>>>>>>>
>>>>>>> <source>11</source>
>>>>>>>
>>>>>>> <target>11</target>
>>>>>>>
>>>>>>> <showWeaveInfo>true</showWeaveInfo>
>>>>>>>
>>>>>>> <verbose>true</verbose>
>>>>>>>
>>>>>>> <aspectLibraries>
>>>>>>>
>>>>>>> <aspectLibrary>
>>>>>>>
>>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>>>
>>>>>>> <artifactId>xxx-aspects</artifactId>
>>>>>>>
>>>>>>> </aspectLibrary>
>>>>>>>
>>>>>>> </aspectLibraries>
>>>>>>>
>>>>>>> <includes>
>>>>>>>
>>>>>>> <include>**/*.aj</include>
>>>>>>>
>>>>>>> <include>**/*.class</include>
>>>>>>>
>>>>>>> </includes>
>>>>>>>
>>>>>>> <Xlint>cantFindType=ignore</Xlint>
>>>>>>>
>>>>>>> <weaveDirectories>
>>>>>>>
>>>>>>> <weaveDirectory>${project.build.directory}/classesToWeav</weaveDirectory>
>>>>>>>
>>>>>>> </weaveDirectories>
>>>>>>>
>>>>>>> </configuration>
>>>>>>>
>>>>>>> <executions>
>>>>>>>
>>>>>>> <execution>
>>>>>>>
>>>>>>> <!-- Compile and weave aspects after all classes compiled by javac
>>>>>>> -->
>>>>>>>
>>>>>>> <phase>process-classes</phase>
>>>>>>>
>>>>>>> <goals>
>>>>>>>
>>>>>>> <goal>compile</goal>
>>>>>>>
>>>>>>> </goals>
>>>>>>>
>>>>>>> </execution>
>>>>>>>
>>>>>>> </executions>
>>>>>>>
>>>>>>> <dependencies>
>>>>>>>
>>>>>>> <dependency>
>>>>>>>
>>>>>>> <groupId>org.aspectj</groupId>
>>>>>>>
>>>>>>> <artifactId>aspectjtools</artifactId>
>>>>>>>
>>>>>>> <version>1.9.7<version>
>>>>>>>
>>>>>>> <scope>compile</scope>
>>>>>>>
>>>>>>> </dependency>
>>>>>>>
>>>>>>> </dependencies>
>>>>>>>
>>>>>>> </plugin>
>>>>>>>
>>>>>>>
>>>>>>> 5. Stack trace:
>>>>>>>
>>>>>>> [ERROR] Failed to execute goal
>>>>>>> org.codehaus.mojo:aspectj-maven-plugin:1.14.0:compile (default) on
>>>>>>> project xxx: AJC compiler errors:
>>>>>>>
>>>>>>> [ERROR] abort ABORT -- (NullPointerException) null
>>>>>>>
>>>>>>> [ERROR] null
>>>>>>>
>>>>>>> [ERROR] java.lang.NullPointerException
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.getModulesDeclaringPackage(ClasspathJmod.java:146)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathLocation.isPackage(ClasspathLocation.java:184)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.findClass(ClasspathJmod.java:55)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.internalFindClass(FileSystem.java:544)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findClass(FileSystem.java:464)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findType(FileSystem.java:617)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.env.IModuleAwareNameEnvironment.findType(IModuleAwareNameEnvironment.java:101)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.internal.core.builder.StatefulNameEnvironment.findType(StatefulNameEnvironment.java:101)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPlainPackage(LookupEnvironment.java:1151)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:136)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:487)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.buildTypeBindings(AjLookupEnvironment.java:1471)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:870)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:449)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:427)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1096)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:275)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:188)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:103)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:47)
>>>>>>>
>>>>>>> [ERROR] at org.aspectj.tools.ajc.Main.run(Main.java:372)
>>>>>>>
>>>>>>> [ERROR] at org.aspectj.tools.ajc.Main.runMain(Main.java:250)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:568)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>>>>>>>
>>>>>>> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>>>>>>>
>>>>>>> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>>>>>>>
>>>>>>> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>>>> Method)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>>>>>>
>>>>>>> [ERROR] at
>>>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>>>>>>
>>>>>>> [ERROR]
>>>>>>>
>>>>>>>
>>>>>>> The problem is that ClasspathJmod objects for JMOD files have
>>>>>>> zipFile=null
>>>>>>>
>>>>>>>
>>>>>>> hence this code in ClasspathJmode fails
>>>>>>>
>>>>>>>
>>>>>>> After some more patching and debugging I also found that some of
>>>>>>> ClasspathJar objects throw NPE for the same reason – zipFile is null
>>>>>>>
>>>>>>>
>>>>>>> I could not find if there is some configuration missing or something
>>>>>>> else that has to be provided in pom.xml so that aspect plugin
>>>>>>> finishes successfully. Appreciate any help on this.
>>>>>>>
>>>>>>>
>>> _______________________________________________
>>> <https://www.eclipse.org/mailman/listinfo/aspectj-users>
>>> aspectj-users mailing list
>>> aspectj-users@xxxxxxxxxxx
>>> <mailto:aspectj-users@xxxxxxxxxxx>
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> <mailto:aspectj-users@xxxxxxxxxxx>
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
