[
https://issues.apache.org/jira/browse/NETBEANS-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810273#comment-16810273
]
Travis commented on NETBEANS-2346:
----------------------------------
This problem seems to be gone after I uninstalled the new "Gradle" and "Groovy
and Gradle" plugins. I had installed the older "Gradle Support" plugin, and
thought that having the newer plugins disabled would prevent conflicts between
the two. But apparently "disabled" is not equivalent to uninstalled.
So now I'm unsure whether or not this ticket is still relevant. It may be that
this is still a bug, but my configuration change just means I'm no longer
hitting it?
> 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
> Attachments: netbeans-2346-test-project.zip
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
