You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by Thomas Kellerer <sh...@gmx.net> on 2023/06/13 09:36:40 UTC
Gradle modules and dependency scanning
I noticed one problem (in NetBeans 17 but it also happens with 18) with the Gradle integration.
I am working on a multi-module project (with 40 modules) using Gradle.
Dependencies to classes in modules that are not currently open in the Projects window are not detected.
NetBeans marks classes using classes from a non-opened module with an error ("ClassNotFound"), even though the class is available to Gradle when building
As soon as I open the module containing the "missing" class, and reload the referencing module, the error badges go away.
However I don't really want to have all those 40 modules open all the time to keep the "Projects" window clean, but the fact that most modules will be marked as erroneous, makes this a bit annoying.
Is there anything I can do, to make NetBeans recognize the classes from non-opened modules?
The Maven integration does not have this problem (although I have to admit that most Maven projects I work on have a lot fewer modules than 40)
Regards
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by Ernie Rael <er...@raelity.com>.
I haven't used NB much lately, but this reminds me of a problem I had
late last year. Don't remember all the details, but it involved gradle
projects working with other projects. Part of the solution (or was it a
workaround) was using a composite build; I seem to recall that a
composite build can be set up without requiring changes to to the main
projects and tells gradle what to look at. Can't find the full
discussion, but there's https://github.com/apache/netbeans/issues/4865
-ernie
On 23/06/26 10:19 PM, Thomas Kellerer wrote:
>> The first thing I would recommend you do is a clean check out of the project (assuming it's in a git repo or something) into a new directory.
> I have done that. And deleted the NetBeans cache as well. But the problem comes back as soon as I open a sub-project that references (already compiled) classes from a sub-project that is not opened in NetBeans.
>
>> However, in most cases you won't get there, because something is corrupted in your filesystem and once you clean it
> File system corruption can be completely ruled in my opinion.
>
> As I said: the errors go away as soon as I open the referenced sub-project and do a reload of the referencing project.
> It seems as if NetBeans only uses Java files from open projects for the in-editor syntax check, not the classes built by Gradle (and thus available on the classpath).
>
>
> Ulrich Mayring schrieb am 26.06.2023 um 20:16:
>> The first thing I would recommend you do is a clean check out of the project (assuming it's in a git repo or something) into a new directory. If the issue persists, then do the same thing on a fresh container, which could be derived from an image like gradle:7-jdk17. That way you will have a clean gradle cache, user dir etc.
>>
>> If the problem still persists, then try to check out fewer projects and through trial & error find a minimal set of projects that will trigger the unwanted Netbeans behavior. From that minimal set you can likely delete a lot of code and in the end come up with a smallish, reproducible example.
>>
>> However, in most cases you won't get there, because something is corrupted in your filesystem and once you clean it, the problem will go away. Naturally, these types of corruption are seen much more often on large projects than on small ones.
>>
>> Am 26.06.23 um 19:41 schrieb Mark A. Flacy:
>>> Greetings,
>>>
>>>
>>> Well, yes, I've had gradle issues in the past due to work projects. It is rather important that the people trying to fix issue X have a way to ensure that they are using code that invokes issue X to see if they are actually fixing issue X.
>>>
>>>
>>> _*Nobody*_ expects you to publish your non-opensource project. Anybody else who might consider working upon your issue expects you to provide an example that shows your failure mode if you cannot expose the project with which you have a problem. The interesting bit is that you /may/ (not will, but *MAY*) find the source of your issue while creating the simulated project that reflects the very issue you have.
>>>
>>>
>>> Get a throw-away email account and create a GitHub account for your simulated project. Or provide a link to git repo that shows your issue. Or create a local file tree of your simulated gradle projects tree, tar it up, and attach it to your JIRA ticket.
>>>
>>>
>>> There is not a single person on this mailing list who will get money for fixing your problem. (assuming you haven't set a bounty to do so). You should make it simple to other humans to replicate your problem so that they may help.
>>>
>>>
>>> --
>>>
>>> Mark A. Flacy
>>>
>>> mflacy@verizon.net
>>>
>>>
>>> On Monday, June 26, 2023 7:18:53 AM CDT Thomas Kellerer wrote:
>>>
>>> > Well, I can't show the real project (customer project with NDA). And I can't
>>>
>>> > just create a project of that size (35 projects, 550K lines of code). AndNob
>>>
>>> > besides I don't have a Github account.
>>>
>>> >
>>>
>>> > The problem is, that basically every problem I have with NetBeans and Gradle
>>>
>>> > only happens on bigger projects (and not with some tiny example projects.
>>>
>>> > It would be a lot more helpful if NetBeans offered some diagnostic data
>>>
>>> > that would allow investigating such a problem. It's pretty unrealistic to
>>>
>>> > as every user that has a problem to publish their projects.
>>>
>>> >
>>>
>>> > I thought Gradle uses the term "module" for projects that consist of
>>>
>>> > multiple sub-projects, but apparently I was wrong.
>>>
>>> >
>>>
>>> > The layout is:
>>>
>>> >
>>>
>>> > main_project
>>>
>>> > sub-project1
>>>
>>> > sub-sub-project1
>>>
>>> > sub-sub-project2
>>>
>>> > sub-project2
>>>
>>> > sub-project3
>>>
>>> > sub-sub-project1
>>>
>>> > sub-sub-project2
>>>
>>> > sub-sub-project3
>>>
>>> > sub-sub-project4
>>>
>>> > sub-sub-project5
>>>
>>> > sub-sub-project6
>>>
>>> > sub-sub-project7
>>>
>>> > sub-sub-project8
>>>
>>> > sub-sub-project9
>>>
>>> > sub-sub-project10
>>>
>>> > sub-sub-project11
>>>
>>> > sub-sub-project12
>>>
>>> > sub-sub-project13
>>>
>>> > sub-sub-project14
>>>
>>> > sub-sub-project15
>>>
>>> > sub-project4
>>>
>>> > sub-project5
>>>
>>> > sub-project6
>>>
>>> > sub-project7
>>>
>>> > sub-sub-project1
>>>
>>> > sub-sub-project2
>>>
>>> > sub-sub-project3
>>>
>>> > sub-sub-project4
>>>
>>> > sub-sub-project5
>>>
>>> > sub-sub-project6
>>>
>>> > sub-sub-project7
>>>
>>> > sub-sub-project8
>>>
>>> > sub-sub-project8
>>>
>>> > sub-project8
>>>
>>> > sub-sub-project1
>>>
>>> > sub-sub-project2
>>>
>>> > sub-sub-project3
>>>
>>> > sub-sub-project4
>>>
>>> > sub-sub-project5
>>>
>>> > sub-project9
>>>
>>> > sub-project10
>>>
>>> > sub-project11
>>>
>>> > sub-project12
>>>
>>> > sub-sub-project1
>>>
>>> > sub-sub-project2
>>>
>>> >
>>>
>>> > sub-project13
>>>
>>> >
>>>
>>> > For those sub-projects that aren't recognized I can see the following
>>>
>>> > entries in the NetBeans logfile:
>>>
>>> >
>>>
>>> > INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load
>>>
>>> > aiming EVALUATED for Unloaded Gradle Project:
>>>
>>> > GradleFiles[projectDir=C:\Projects\******\main\commons,
>>>
>>> > rootDir=C:\Projects\*******\main]
>>>
>>> >
>>>
>>> > Thomas
>>>
>>> >
>>>
>>> > Mark A. Flacy schrieb am 26.06.2023 um 13:47:
>>>
>>> > > Create a simple example in GitHub or GitLab so that people have something
>>>
>>> > > to test against.
>>>
>>> > >
>>>
>>> > > I'm not sure how your project is set up, since I normally don't use the
>>>
>>> > > term "module" in gradle projects.
>>>
>>> > >
>>>
>>> > >
>>>
>>> > >
>>>
>>> > > Sent from my Galaxy
>>>
>>> > >
>>>
>>> > >
>>>
>>> > > -------- Original message --------
>>>
>>> > > From: Thomas Kellerer <sh...@gmx.net>
>>>
>>> > > Date: 6/26/23 01:17 (GMT-06:00)
>>>
>>> > > To: users@netbeans.apache.org
>>>
>>> > > Subject: Re: Gradle modules and dependency scanning
>>>
>>> > >
>>>
>>> > > Any ideas?
>>>
>>> > >
>>>
>>> > > Thomas Kellerer schrieb am 13.06.2023 um 11:36:
>>>
>>> > >> I noticed one problem (in NetBeans 17 but it also happens with 18) with
>>>
>>> > >> the Gradle integration.
>>>
>>> > >>
>>>
>>> > >> I am working on a multi-module project (with 40 modules) using Gradle.
>>>
>>> > >>
>>>
>>> > >> Dependencies to classes in modules that are not currently open in the
>>>
>>> > >> Projects window are not detected. NetBeans marks classes using classes
>>>
>>> > >> from a non-opened module with an error ("ClassNotFound"), even though
>>>
>>> > >> the class is available to Gradle when building
>>>
>>> > >>
>>>
>>> > >> As soon as I open the module containing the "missing" class, and reload
>>>
>>> > >> the referencing module, the error badges go away.
>>>
>>> > >>
>>>
>>> > >> However I don't really want to have all those 40 modules open all the
>>>
>>> > >> time to keep the "Projects" window clean, but the fact that most modules
>>>
>>> > >> will be marked as erroneous, makes this a bit annoying.
>>>
>>> > >>
>>>
>>> > >> Is there anything I can do, to make NetBeans recognize the classes from
>>>
>>> > >> non-opened modules?
>>>
>>> > >>
>>>
>>> > >> The Maven integration does not have this problem (although I have to
>>>
>>> > >> admit that most Maven projects I work on have a lot fewer modules than
>>>
>>> > >> 40)
>>>
>>> > >>
>>>
>>> > >> Regards
>>>
>>> > >> Thomas
>>>
>>> > >
>>>
>>> > > ---------------------------------------------------------------------
>>>
>>> > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>>
>>> > > For additional commands, e-mail: users-help@netbeans.apache.org
>>>
>>> > >
>>>
>>> > > For further information about the NetBeans mailing lists, visit:
>>>
>>> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>> >
>>>
>>> > ---------------------------------------------------------------------
>>>
>>> > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>>
>>> > For additional commands, e-mail: users-help@netbeans.apache.org
>>>
>>> >
>>>
>>> > For further information about the NetBeans mailing lists, visit:
>>>
>>> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by Thomas Kellerer <sh...@gmx.net>.
> The first thing I would recommend you do is a clean check out of the project (assuming it's in a git repo or something) into a new directory.
I have done that. And deleted the NetBeans cache as well. But the problem comes back as soon as I open a sub-project that references (already compiled) classes from a sub-project that is not opened in NetBeans.
> However, in most cases you won't get there, because something is corrupted in your filesystem and once you clean it
File system corruption can be completely ruled in my opinion.
As I said: the errors go away as soon as I open the referenced sub-project and do a reload of the referencing project.
It seems as if NetBeans only uses Java files from open projects for the in-editor syntax check, not the classes built by Gradle (and thus available on the classpath).
Ulrich Mayring schrieb am 26.06.2023 um 20:16:
> The first thing I would recommend you do is a clean check out of the project (assuming it's in a git repo or something) into a new directory. If the issue persists, then do the same thing on a fresh container, which could be derived from an image like gradle:7-jdk17. That way you will have a clean gradle cache, user dir etc.
>
> If the problem still persists, then try to check out fewer projects and through trial & error find a minimal set of projects that will trigger the unwanted Netbeans behavior. From that minimal set you can likely delete a lot of code and in the end come up with a smallish, reproducible example.
>
> However, in most cases you won't get there, because something is corrupted in your filesystem and once you clean it, the problem will go away. Naturally, these types of corruption are seen much more often on large projects than on small ones.
>
> Am 26.06.23 um 19:41 schrieb Mark A. Flacy:
>> Greetings,
>>
>>
>> Well, yes, I've had gradle issues in the past due to work projects. It is rather important that the people trying to fix issue X have a way to ensure that they are using code that invokes issue X to see if they are actually fixing issue X.
>>
>>
>> _*Nobody*_ expects you to publish your non-opensource project. Anybody else who might consider working upon your issue expects you to provide an example that shows your failure mode if you cannot expose the project with which you have a problem. The interesting bit is that you /may/ (not will, but *MAY*) find the source of your issue while creating the simulated project that reflects the very issue you have.
>>
>>
>> Get a throw-away email account and create a GitHub account for your simulated project. Or provide a link to git repo that shows your issue. Or create a local file tree of your simulated gradle projects tree, tar it up, and attach it to your JIRA ticket.
>>
>>
>> There is not a single person on this mailing list who will get money for fixing your problem. (assuming you haven't set a bounty to do so). You should make it simple to other humans to replicate your problem so that they may help.
>>
>>
>> --
>>
>> Mark A. Flacy
>>
>> mflacy@verizon.net
>>
>>
>> On Monday, June 26, 2023 7:18:53 AM CDT Thomas Kellerer wrote:
>>
>> > Well, I can't show the real project (customer project with NDA). And I can't
>>
>> > just create a project of that size (35 projects, 550K lines of code). AndNob
>>
>> > besides I don't have a Github account.
>>
>> >
>>
>> > The problem is, that basically every problem I have with NetBeans and Gradle
>>
>> > only happens on bigger projects (and not with some tiny example projects.
>>
>> > It would be a lot more helpful if NetBeans offered some diagnostic data
>>
>> > that would allow investigating such a problem. It's pretty unrealistic to
>>
>> > as every user that has a problem to publish their projects.
>>
>> >
>>
>> > I thought Gradle uses the term "module" for projects that consist of
>>
>> > multiple sub-projects, but apparently I was wrong.
>>
>> >
>>
>> > The layout is:
>>
>> >
>>
>> > main_project
>>
>> > sub-project1
>>
>> > sub-sub-project1
>>
>> > sub-sub-project2
>>
>> > sub-project2
>>
>> > sub-project3
>>
>> > sub-sub-project1
>>
>> > sub-sub-project2
>>
>> > sub-sub-project3
>>
>> > sub-sub-project4
>>
>> > sub-sub-project5
>>
>> > sub-sub-project6
>>
>> > sub-sub-project7
>>
>> > sub-sub-project8
>>
>> > sub-sub-project9
>>
>> > sub-sub-project10
>>
>> > sub-sub-project11
>>
>> > sub-sub-project12
>>
>> > sub-sub-project13
>>
>> > sub-sub-project14
>>
>> > sub-sub-project15
>>
>> > sub-project4
>>
>> > sub-project5
>>
>> > sub-project6
>>
>> > sub-project7
>>
>> > sub-sub-project1
>>
>> > sub-sub-project2
>>
>> > sub-sub-project3
>>
>> > sub-sub-project4
>>
>> > sub-sub-project5
>>
>> > sub-sub-project6
>>
>> > sub-sub-project7
>>
>> > sub-sub-project8
>>
>> > sub-sub-project8
>>
>> > sub-project8
>>
>> > sub-sub-project1
>>
>> > sub-sub-project2
>>
>> > sub-sub-project3
>>
>> > sub-sub-project4
>>
>> > sub-sub-project5
>>
>> > sub-project9
>>
>> > sub-project10
>>
>> > sub-project11
>>
>> > sub-project12
>>
>> > sub-sub-project1
>>
>> > sub-sub-project2
>>
>> >
>>
>> > sub-project13
>>
>> >
>>
>> > For those sub-projects that aren't recognized I can see the following
>>
>> > entries in the NetBeans logfile:
>>
>> >
>>
>> > INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load
>>
>> > aiming EVALUATED for Unloaded Gradle Project:
>>
>> > GradleFiles[projectDir=C:\Projects\******\main\commons,
>>
>> > rootDir=C:\Projects\*******\main]
>>
>> >
>>
>> > Thomas
>>
>> >
>>
>> > Mark A. Flacy schrieb am 26.06.2023 um 13:47:
>>
>> > > Create a simple example in GitHub or GitLab so that people have something
>>
>> > > to test against.
>>
>> > >
>>
>> > > I'm not sure how your project is set up, since I normally don't use the
>>
>> > > term "module" in gradle projects.
>>
>> > >
>>
>> > >
>>
>> > >
>>
>> > > Sent from my Galaxy
>>
>> > >
>>
>> > >
>>
>> > > -------- Original message --------
>>
>> > > From: Thomas Kellerer <sh...@gmx.net>
>>
>> > > Date: 6/26/23 01:17 (GMT-06:00)
>>
>> > > To: users@netbeans.apache.org
>>
>> > > Subject: Re: Gradle modules and dependency scanning
>>
>> > >
>>
>> > > Any ideas?
>>
>> > >
>>
>> > > Thomas Kellerer schrieb am 13.06.2023 um 11:36:
>>
>> > >> I noticed one problem (in NetBeans 17 but it also happens with 18) with
>>
>> > >> the Gradle integration.
>>
>> > >>
>>
>> > >> I am working on a multi-module project (with 40 modules) using Gradle.
>>
>> > >>
>>
>> > >> Dependencies to classes in modules that are not currently open in the
>>
>> > >> Projects window are not detected. NetBeans marks classes using classes
>>
>> > >> from a non-opened module with an error ("ClassNotFound"), even though
>>
>> > >> the class is available to Gradle when building
>>
>> > >>
>>
>> > >> As soon as I open the module containing the "missing" class, and reload
>>
>> > >> the referencing module, the error badges go away.
>>
>> > >>
>>
>> > >> However I don't really want to have all those 40 modules open all the
>>
>> > >> time to keep the "Projects" window clean, but the fact that most modules
>>
>> > >> will be marked as erroneous, makes this a bit annoying.
>>
>> > >>
>>
>> > >> Is there anything I can do, to make NetBeans recognize the classes from
>>
>> > >> non-opened modules?
>>
>> > >>
>>
>> > >> The Maven integration does not have this problem (although I have to
>>
>> > >> admit that most Maven projects I work on have a lot fewer modules than
>>
>> > >> 40)
>>
>> > >>
>>
>> > >> Regards
>>
>> > >> Thomas
>>
>> > >
>>
>> > > ---------------------------------------------------------------------
>>
>> > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>
>> > > For additional commands, e-mail: users-help@netbeans.apache.org
>>
>> > >
>>
>> > > For further information about the NetBeans mailing lists, visit:
>>
>> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>> >
>>
>> > ---------------------------------------------------------------------
>>
>> > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>
>> > For additional commands, e-mail: users-help@netbeans.apache.org
>>
>> >
>>
>> > For further information about the NetBeans mailing lists, visit:
>>
>> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by Ulrich Mayring <ul...@isys.de>.
The first thing I would recommend you do is a clean check out of the
project (assuming it's in a git repo or something) into a new directory.
If the issue persists, then do the same thing on a fresh container,
which could be derived from an image like gradle:7-jdk17. That way you
will have a clean gradle cache, user dir etc.
If the problem still persists, then try to check out fewer projects and
through trial & error find a minimal set of projects that will trigger
the unwanted Netbeans behavior. From that minimal set you can likely
delete a lot of code and in the end come up with a smallish,
reproducible example.
However, in most cases you won't get there, because something is
corrupted in your filesystem and once you clean it, the problem will go
away. Naturally, these types of corruption are seen much more often on
large projects than on small ones.
Am 26.06.23 um 19:41 schrieb Mark A. Flacy:
> Greetings,
>
>
> Well, yes, I've had gradle issues in the past due to work projects. It
> is rather important that the people trying to fix issue X have a way to
> ensure that they are using code that invokes issue X to see if they are
> actually fixing issue X.
>
>
> _*Nobody*_ expects you to publish your non-opensource project. Anybody
> else who might consider working upon your issue expects you to provide
> an example that shows your failure mode if you cannot expose the project
> with which you have a problem. The interesting bit is that you
> /may/ (not will, but *MAY*) find the source of your issue while creating
> the simulated project that reflects the very issue you have.
>
>
> Get a throw-away email account and create a GitHub account for your
> simulated project. Or provide a link to git repo that shows your
> issue. Or create a local file tree of your simulated gradle projects
> tree, tar it up, and attach it to your JIRA ticket.
>
>
> There is not a single person on this mailing list who will get money for
> fixing your problem. (assuming you haven't set a bounty to do so). You
> should make it simple to other humans to replicate your problem so that
> they may help.
>
>
> --
>
> Mark A. Flacy
>
> mflacy@verizon.net
>
>
> On Monday, June 26, 2023 7:18:53 AM CDT Thomas Kellerer wrote:
>
> > Well, I can't show the real project (customer project with NDA). And
> I can't
>
> > just create a project of that size (35 projects, 550K lines of code).
> AndNob
>
> > besides I don't have a Github account.
>
> >
>
> > The problem is, that basically every problem I have with NetBeans and
> Gradle
>
> > only happens on bigger projects (and not with some tiny example projects.
>
> > It would be a lot more helpful if NetBeans offered some diagnostic data
>
> > that would allow investigating such a problem. It's pretty unrealistic to
>
> > as every user that has a problem to publish their projects.
>
> >
>
> > I thought Gradle uses the term "module" for projects that consist of
>
> > multiple sub-projects, but apparently I was wrong.
>
> >
>
> > The layout is:
>
> >
>
> > main_project
>
> > sub-project1
>
> > sub-sub-project1
>
> > sub-sub-project2
>
> > sub-project2
>
> > sub-project3
>
> > sub-sub-project1
>
> > sub-sub-project2
>
> > sub-sub-project3
>
> > sub-sub-project4
>
> > sub-sub-project5
>
> > sub-sub-project6
>
> > sub-sub-project7
>
> > sub-sub-project8
>
> > sub-sub-project9
>
> > sub-sub-project10
>
> > sub-sub-project11
>
> > sub-sub-project12
>
> > sub-sub-project13
>
> > sub-sub-project14
>
> > sub-sub-project15
>
> > sub-project4
>
> > sub-project5
>
> > sub-project6
>
> > sub-project7
>
> > sub-sub-project1
>
> > sub-sub-project2
>
> > sub-sub-project3
>
> > sub-sub-project4
>
> > sub-sub-project5
>
> > sub-sub-project6
>
> > sub-sub-project7
>
> > sub-sub-project8
>
> > sub-sub-project8
>
> > sub-project8
>
> > sub-sub-project1
>
> > sub-sub-project2
>
> > sub-sub-project3
>
> > sub-sub-project4
>
> > sub-sub-project5
>
> > sub-project9
>
> > sub-project10
>
> > sub-project11
>
> > sub-project12
>
> > sub-sub-project1
>
> > sub-sub-project2
>
> >
>
> > sub-project13
>
> >
>
> > For those sub-projects that aren't recognized I can see the following
>
> > entries in the NetBeans logfile:
>
> >
>
> > INFO
> [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load
>
> > aiming EVALUATED for Unloaded Gradle Project:
>
> > GradleFiles[projectDir=C:\Projects\******\main\commons,
>
> > rootDir=C:\Projects\*******\main]
>
> >
>
> > Thomas
>
> >
>
> > Mark A. Flacy schrieb am 26.06.2023 um 13:47:
>
> > > Create a simple example in GitHub or GitLab so that people have
> something
>
> > > to test against.
>
> > >
>
> > > I'm not sure how your project is set up, since I normally don't use the
>
> > > term "module" in gradle projects.
>
> > >
>
> > >
>
> > >
>
> > > Sent from my Galaxy
>
> > >
>
> > >
>
> > > -------- Original message --------
>
> > > From: Thomas Kellerer <sh...@gmx.net>
>
> > > Date: 6/26/23 01:17 (GMT-06:00)
>
> > > To: users@netbeans.apache.org
>
> > > Subject: Re: Gradle modules and dependency scanning
>
> > >
>
> > > Any ideas?
>
> > >
>
> > > Thomas Kellerer schrieb am 13.06.2023 um 11:36:
>
> > >> I noticed one problem (in NetBeans 17 but it also happens with 18)
> with
>
> > >> the Gradle integration.
>
> > >>
>
> > >> I am working on a multi-module project (with 40 modules) using Gradle.
>
> > >>
>
> > >> Dependencies to classes in modules that are not currently open in the
>
> > >> Projects window are not detected. NetBeans marks classes using classes
>
> > >> from a non-opened module with an error ("ClassNotFound"), even though
>
> > >> the class is available to Gradle when building
>
> > >>
>
> > >> As soon as I open the module containing the "missing" class, and
> reload
>
> > >> the referencing module, the error badges go away.
>
> > >>
>
> > >> However I don't really want to have all those 40 modules open all the
>
> > >> time to keep the "Projects" window clean, but the fact that most
> modules
>
> > >> will be marked as erroneous, makes this a bit annoying.
>
> > >>
>
> > >> Is there anything I can do, to make NetBeans recognize the classes
> from
>
> > >> non-opened modules?
>
> > >>
>
> > >> The Maven integration does not have this problem (although I have to
>
> > >> admit that most Maven projects I work on have a lot fewer modules than
>
> > >> 40)
>
> > >>
>
> > >> Regards
>
> > >> Thomas
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>
> > > For additional commands, e-mail: users-help@netbeans.apache.org
>
> > >
>
> > > For further information about the NetBeans mailing lists, visit:
>
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>
> > For additional commands, e-mail: users-help@netbeans.apache.org
>
> >
>
> > For further information about the NetBeans mailing lists, visit:
>
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
--
iSYS Software GmbH
Ulrich Mayring | Full Stack Developer
Technology Lab / R&D
Tel: +49 (0) 89 46 23 28-0 | Fax +49 (0) 89 46 23 28-14
email: ulrich.mayring@isys.de
Grillparzerstraße 10 | D-81675 München
www.isys.de
Sitz der Gesellschaft: München | HRB 111760
Geschäftsführer: Stefan Fischer und Max Haller
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by "Mark A. Flacy" <mf...@verizon.net.INVALID>.
Greetings,
Well, yes, I've had gradle issues in the past due to work projects. It is rather important that
the people trying to fix issue X have a way to ensure that they are using code that invokes
issue X to see if they are actually fixing issue X.
_*Nobody*_ expects you to publish your non-opensource project. Anybody else who might
consider working upon your issue expects you to provide an example that shows your
failure mode if you cannot expose the project with which you have a problem. The
interesting bit is that you /may/ (not will, but *MAY*) find the source of your issue while
creating the simulated project that reflects the very issue you have.
Get a throw-away email account and create a GitHub account for your simulated project. Or
provide a link to git repo that shows your issue. Or create a local file tree of your simulated
gradle projects tree, tar it up, and attach it to your JIRA ticket.
There is not a single person on this mailing list who will get money for fixing your problem.
(assuming you haven't set a bounty to do so). You should make it simple to other humans
to replicate your problem so that they may help.
--
Mark A. Flacy
mflacy@verizon.net
On Monday, June 26, 2023 7:18:53 AM CDT Thomas Kellerer wrote:
> Well, I can't show the real project (customer project with NDA). And I can't
> just create a project of that size (35 projects, 550K lines of code). AndNob
> besides I don't have a Github account.
>
> The problem is, that basically every problem I have with NetBeans and Gradle
> only happens on bigger projects (and not with some tiny example projects.
> It would be a lot more helpful if NetBeans offered some diagnostic data
> that would allow investigating such a problem. It's pretty unrealistic to
> as every user that has a problem to publish their projects.
>
> I thought Gradle uses the term "module" for projects that consist of
> multiple sub-projects, but apparently I was wrong.
>
> The layout is:
>
> main_project
> sub-project1
> sub-sub-project1
> sub-sub-project2
> sub-project2
> sub-project3
> sub-sub-project1
> sub-sub-project2
> sub-sub-project3
> sub-sub-project4
> sub-sub-project5
> sub-sub-project6
> sub-sub-project7
> sub-sub-project8
> sub-sub-project9
> sub-sub-project10
> sub-sub-project11
> sub-sub-project12
> sub-sub-project13
> sub-sub-project14
> sub-sub-project15
> sub-project4
> sub-project5
> sub-project6
> sub-project7
> sub-sub-project1
> sub-sub-project2
> sub-sub-project3
> sub-sub-project4
> sub-sub-project5
> sub-sub-project6
> sub-sub-project7
> sub-sub-project8
> sub-sub-project8
> sub-project8
> sub-sub-project1
> sub-sub-project2
> sub-sub-project3
> sub-sub-project4
> sub-sub-project5
> sub-project9
> sub-project10
> sub-project11
> sub-project12
> sub-sub-project1
> sub-sub-project2
>
> sub-project13
>
> For those sub-projects that aren't recognized I can see the following
> entries in the NetBeans logfile:
>
> INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load
> aiming EVALUATED for Unloaded Gradle Project:
> GradleFiles[projectDir=C:\Projects\******\main\commons,
> rootDir=C:\Projects\*******\main]
>
> Thomas
>
> Mark A. Flacy schrieb am 26.06.2023 um 13:47:
> > Create a simple example in GitHub or GitLab so that people have something
> > to test against.
> >
> > I'm not sure how your project is set up, since I normally don't use the
> > term "module" in gradle projects.
> >
> >
> >
> > Sent from my Galaxy
> >
> >
> > -------- Original message --------
Re: Gradle modules and dependency scanning
Posted by Thomas Kellerer <sh...@gmx.net>.
Well, I can't show the real project (customer project with NDA). And I can't just create a project of that size (35 projects, 550K lines of code).
And besides I don't have a Github account.
The problem is, that basically every problem I have with NetBeans and Gradle only happens on bigger projects (and not with some tiny example projects.
It would be a lot more helpful if NetBeans offered some diagnostic data that would allow investigating such a problem. It's pretty unrealistic to as every user that has a problem to publish their projects.
I thought Gradle uses the term "module" for projects that consist of multiple sub-projects, but apparently I was wrong.
The layout is:
main_project
sub-project1
sub-sub-project1
sub-sub-project2
sub-project2
sub-project3
sub-sub-project1
sub-sub-project2
sub-sub-project3
sub-sub-project4
sub-sub-project5
sub-sub-project6
sub-sub-project7
sub-sub-project8
sub-sub-project9
sub-sub-project10
sub-sub-project11
sub-sub-project12
sub-sub-project13
sub-sub-project14
sub-sub-project15
sub-project4
sub-project5
sub-project6
sub-project7
sub-sub-project1
sub-sub-project2
sub-sub-project3
sub-sub-project4
sub-sub-project5
sub-sub-project6
sub-sub-project7
sub-sub-project8
sub-sub-project8
sub-project8
sub-sub-project1
sub-sub-project2
sub-sub-project3
sub-sub-project4
sub-sub-project5
sub-project9
sub-project10
sub-project11
sub-project12
sub-sub-project1
sub-sub-project2
sub-project13
For those sub-projects that aren't recognized I can see the following entries in the NetBeans logfile:
INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming EVALUATED for Unloaded Gradle Project: GradleFiles[projectDir=C:\Projects\******\main\commons, rootDir=C:\Projects\*******\main]
Thomas
Mark A. Flacy schrieb am 26.06.2023 um 13:47:
> Create a simple example in GitHub or GitLab so that people have something to test against.
>
> I'm not sure how your project is set up, since I normally don't use the term "module" in gradle projects.
>
>
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Thomas Kellerer <sh...@gmx.net>
> Date: 6/26/23 01:17 (GMT-06:00)
> To: users@netbeans.apache.org
> Subject: Re: Gradle modules and dependency scanning
>
> Any ideas?
>
> Thomas Kellerer schrieb am 13.06.2023 um 11:36:
>> I noticed one problem (in NetBeans 17 but it also happens with 18) with the Gradle integration.
>>
>> I am working on a multi-module project (with 40 modules) using Gradle.
>>
>> Dependencies to classes in modules that are not currently open in the Projects window are not detected.
>> NetBeans marks classes using classes from a non-opened module with an error ("ClassNotFound"), even though the class is available to Gradle when building
>>
>> As soon as I open the module containing the "missing" class, and reload the referencing module, the error badges go away.
>>
>> However I don't really want to have all those 40 modules open all the time to keep the "Projects" window clean, but the fact that most modules will be marked as erroneous, makes this a bit annoying.
>>
>> Is there anything I can do, to make NetBeans recognize the classes from non-opened modules?
>>
>> The Maven integration does not have this problem (although I have to admit that most Maven projects I work on have a lot fewer modules than 40)
>>
>> Regards
>> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by "Mark A. Flacy" <mf...@verizon.net.INVALID>.
Create a simple example in GitHub or GitLab so that people have something to test against.I'm not sure how your project is set up, since I normally don't use the term "module" in gradle projects.Sent from my Galaxy
-------- Original message --------From: Thomas Kellerer <sh...@gmx.net> Date: 6/26/23 01:17 (GMT-06:00) To: users@netbeans.apache.org Subject: Re: Gradle modules and dependency scanning Any ideas?Thomas Kellerer schrieb am 13.06.2023 um 11:36:> I noticed one problem (in NetBeans 17 but it also happens with 18) with the Gradle integration.>> I am working on a multi-module project (with 40 modules) using Gradle.>> Dependencies to classes in modules that are not currently open in the Projects window are not detected.> NetBeans marks classes using classes from a non-opened module with an error ("ClassNotFound"), even though the class is available to Gradle when building>> As soon as I open the module containing the "missing" class, and reload the referencing module, the error badges go away.>> However I don't really want to have all those 40 modules open all the time to keep the "Projects" window clean, but the fact that most modules will be marked as erroneous, makes this a bit annoying.>> Is there anything I can do, to make NetBeans recognize the classes from non-opened modules?>> The Maven integration does not have this problem (although I have to admit that most Maven projects I work on have a lot fewer modules than 40)>> Regards> Thomas---------------------------------------------------------------------To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.orgFor additional commands, e-mail: users-help@netbeans.apache.orgFor further information about the NetBeans mailing lists, visit:https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle modules and dependency scanning
Posted by Thomas Kellerer <sh...@gmx.net>.
Any ideas?
Thomas Kellerer schrieb am 13.06.2023 um 11:36:
> I noticed one problem (in NetBeans 17 but it also happens with 18) with the Gradle integration.
>
> I am working on a multi-module project (with 40 modules) using Gradle.
>
> Dependencies to classes in modules that are not currently open in the Projects window are not detected.
> NetBeans marks classes using classes from a non-opened module with an error ("ClassNotFound"), even though the class is available to Gradle when building
>
> As soon as I open the module containing the "missing" class, and reload the referencing module, the error badges go away.
>
> However I don't really want to have all those 40 modules open all the time to keep the "Projects" window clean, but the fact that most modules will be marked as erroneous, makes this a bit annoying.
>
> Is there anything I can do, to make NetBeans recognize the classes from non-opened modules?
>
> The Maven integration does not have this problem (although I have to admit that most Maven projects I work on have a lot fewer modules than 40)
>
> Regards
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists