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 2021/07/15 13:16:00 UTC

[jira] [Commented] (NETBEANS-5846) Gradle reports broken projects, but the build is just fine.

    [ https://issues.apache.org/jira/browse/NETBEANS-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381336#comment-17381336 ] 

Laszlo Kishalmi commented on NETBEANS-5846:
-------------------------------------------

Well, just read the java-platform plugin documentation and it makes sense. BOM projects are just for, roughly saying, declaring dependencies. It does not make sense to bind repository to them. That would happen in the projects/sub-projects where they are being consumed.

I need to think how would be the best way to represent such projects in the UI, though for short term solution, I can probably put an exception in the dependency resolver not-to try to resolve dependencies in projects where the java-platform plugin is applied.

> Gradle reports broken projects, but the build is just fine.
> -----------------------------------------------------------
>
>                 Key: NETBEANS-5846
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-5846
>             Project: NetBeans
>          Issue Type: Bug
>          Components: projects - Gradle
>    Affects Versions: 12.4, 12.5
>            Reporter: Svatopluk Dedic
>            Assignee: Laszlo Kishalmi
>            Priority: Major
>
> To reproduce: checkout the project {{git@github.com:micronaut-projects/micronaut-test.git}} and open its subproject *test-bom*
> The project load reports broken dependencies for:
>  
> {code:java}
> classpath
> +--- org.junit:junit-bom:5.7.1 -> 5.7.1 FAILED
> \--- org.spockframework:spock-bom:2.0-M3-groovy-3.0 -> 2.0-M3-groovy-3.0 FAILED
> {code}
> as well as *gradle dependencies* command. But the message is:
>  
> {quote}.... because no repositories are defined.
> {quote}
> But the outermost project defines *repositories* block. *gradle build* in the -bom subproject succeeds - so perhaps it does not attempt to resolve the entries in the _classpath_  configuration ?
> The net effect is that the 'bom' project is always marked with a warning and 'resolve project problems' action does nothing. If a project's summary state is displayed i.e. in a LSP client, the project as a whole appears to be buggy (but it apparently is not).
> [~lkishalmi] could you please advise why Gradle is reporting 'no repositories defined' ? Or how to filter out this type of no-errors from the retrieved info maps ? Naturally I wouldn't like to suppress _real_ resolution errors...
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
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