You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Laszlo Kishalmi (JIRA)" <ji...@apache.org> on 2019/04/09 14:13:00 UTC
[jira] [Resolved] (NETBEANS-2346) Netbeans throws
ArrayIndexOutOfBoundsException when opening Gradle projects containing
unversioned dependencies
[ https://issues.apache.org/jira/browse/NETBEANS-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Laszlo Kishalmi resolved NETBEANS-2346.
---------------------------------------
Resolution: Fixed
Fix Version/s: Next
Marked resolved as the corresponding PR has been merged.
> Netbeans throws ArrayIndexOutOfBoundsException when opening Gradle projects containing unversioned dependencies
> ---------------------------------------------------------------------------------------------------------------
>
> Key: NETBEANS-2346
> URL: https://issues.apache.org/jira/browse/NETBEANS-2346
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
> Affects Versions: 11.0
> Reporter: Travis
> Assignee: Laszlo Kishalmi
> Priority: Minor
> Labels: pull-request-available
> Fix For: Next
>
> Attachments: netbeans-2346-test-project.zip
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I am trying to load a project that uses local .jar file dependencies. The build.gradle contains something like:
>
> repositories {
> flatDir dirs: [ "$rootDir/lib" ]
> }
> dependencies {
> testImplementation name: 'hamcrest-core-1.3'
> }
>
> And there is a file hamcrest-core-1.3.jar in the project's "lib" folder.
>
> This all works fine with Netbeans versions prior to 11 (using the third-party Gradle plugin, of course).
>
> But when Netbeans 11 vc4 loads the same project, it throws the following exception:
>
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.netbeans.modules.gradle.api.GradleDependency$ModuleDependency.<init>(GradleDependency.java:85)
> at org.netbeans.modules.gradle.api.GradleBaseProjectBuilder.processDependencies(GradleBaseProjectBuilder.java:149)
> at org.netbeans.modules.gradle.api.GradleBaseProjectBuilder.build(GradleBaseProjectBuilder.java:75)
> at org.netbeans.modules.gradle.api.GradleBaseProjectBuilder$Extractor.extract(GradleBaseProjectBuilder.java:288)
> at org.netbeans.modules.gradle.GradleProjectCache.createGradleProject(GradleProjectCache.java:432)
> at org.netbeans.modules.gradle.GradleProjectCache.loadGradleProject(GradleProjectCache.java:257)
> at org.netbeans.modules.gradle.GradleProjectCache.access$100(GradleProjectCache.java:85)
> [catch] at org.netbeans.modules.gradle.GradleProjectCache$ProjectLoaderTask.call(GradleProjectCache.java:348)
> at org.netbeans.modules.gradle.GradleProjectCache$ProjectLoaderTask.call(GradleProjectCache.java:326)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>
> I took a look in GradleDependency.java line 85 and found:
>
> ModuleDependency(String id, Set<File> artifacts) {
> super(id);
> this.artifacts = artifacts;
> String[] parts = id.split(":");
> group = parts[0];
> name = parts[1];
> version = parts[2];
> }
>
> That code appears to be making the blind assumption that all dependencies will have all three parts: group, name, version. But it is possible and legal to specify only name for local .jar dependencies like mine.
>
>
> After this exception, the "Source Packages" subtree is completely missing from the "Projects" pane. Although the project load gracefully recovers and some operations still work on the project, the IDE is effectively unusuable without the ability to browse packages and classes.
>
> I found a simple workaround, which is to rewrite the same dependencies in build.gradle to use the full group:name:version format, with fake group and version values just to make Netbeans happy:
> testImplementation 'dummy:hamcrest-core-1.3:dummy'
> With that workaround, Netbeans 11 works much better.
>
> Although that workaround is acceptable, it results in otherwise unnecessary clutter in the build.gradle files, so I'm hoping to revert it after a future Netbeans update.
>
> Please fix the Netbeans Gradle support to properly handle name-only dependencies like the example above. Thank you!
>
> By the way, I don't know if it makes any difference here, but I'm using:
>
> Windows 10
> Netbeans 11 vc4
> Gradle 5.2
> Java 12
> Gradle Plugin 2.0.2
>
> Yes, I'm trying to keep using the old plugin, but the new Gradle built-in support still interferes in this manner, despite showing up as disabled in the Plugins browser. Apparently some of the built-in code still runs even in that scenario?
>
> If it would help for me to provide an example tiny project to demonstrate this bug, I could provide one on GitHub... just let me know if that would help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists