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
mfl...@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 <sham...@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-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: users-h...@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-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
