You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by Christian Pervoelz <cp...@gmail.com> on 2021/06/21 12:35:20 UTC
Gradle support and depending projects
Hi,
I have a gradle container project consisting of two sub projects.
Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
But... every single import statement is marked as "package does not exist".
This applies to
- imports from external libraries
- imports from the other project
- imports from the same project, but a different package
This causes a lot of follow-up problems (e.g. not working code completion,
tons of markers in the side bar about issues), which are quite inconvenient
to work with. It feels like working with a simple text editor, that has a
bit of code coloring and formatting capabilities.
There is also another nasty side effect: When creating a new class in a
project, the file is created, but misses the package declaration. (But even
after adding it manually, the class is still unknown to other classes)
So, my question is:
Might it be, that a gradle project in NB, that is depending on other gradle
projects is not able to use the classpaths given in the project settings
(which are all shown)? Or is it just ignoring those?
Further information:
Windows 10, Gradle 7, OpenJdk 16
--- Thanks in advance
C.
Re: Gradle support and depending projects
Posted by Thomas Kellerer <sh...@gmx.net>.
It seems this problem only affects the project to which the currently visible file in the editor belongs to.
So if I have projects A,B and C open, and the active editor shows a file from project B when I close NetBeans, then those unresolved imports (even in the same package of the project) are typically in project B when I start NetBeans the next time.
Closing and re-opening that project (and only that) seems to fix this problem as well.
Thomas Kellerer schrieb am 21.06.2021 um 18:20:
> For me, switchting to a different project groups fixes this error (at least most of the time)
>
> Christian Pervoelz schrieb am 21.06.2021 um 15:34:
>> Yes, usually that helps for me too, but here neither Clean&Build, restarting the IDE or just reloading the projects helped.
>>
>> After playing around a bit more, I had some findings:
>>
>> a) cleaning the cache in user dir brings some improvements
>> So to say, almost all imports are resolved now (and due to that most of the other stuff works), except those from the other project in the container. And this issue disappears after another clean build (maybe or not).
>> But of course, this is not a valid option for less experienced users.
>>
>> b) the issue seems to appear only, if I load the project for the very first time, so the gradle supports detects problems, which are to be resolved by a primer build
>>
>> c) as soon as any issue appears with the build files, the import statement issues are back
>> Only restarting the IDE helps.
>>
>> d) between various restarts of the IDE the issues mentioned in the first mail might appear or not
>>
>> Hmm, very mysterious that.
>>
>> Anyway, it's hard to provide reliable steps to reproduce, as with another project container it didn't happen at all :(
>>
>> Thanks
>> --- C.
>>
>>
>>
>> Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer <swpalmer@gmail.com <ma...@gmail.com>>:
>>
>> This usually goes away for me if I reload the project after building to ensure the classes being imported have been compiled. It would certainly be better if that wasn’t required.
>>
>> Scott
>>
>>> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz <cpervoelz@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I have a gradle container project consisting of two sub projects.
>>> Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
>>>
>>> But... every single import statement is marked as "package does not exist". This applies to
>>>
>>> * imports from external libraries
>>> * imports from the other project
>>> * imports from the same project, but a different package
>>>
>>>
>>> This causes a lot of follow-up problems (e.g. not working code completion, tons of markers in the side bar about issues), which are quite inconvenient to work with. It feels like working with a simple text editor, that has a bit of code coloring and formatting capabilities.
>>> There is also another nasty side effect: When creating a new class in a project, the file is created, but misses the package declaration. (But even after adding it manually, the class is still unknown to other classes)
>>>
>>>
>>> So, my question is:
>>> Might it be, that a gradle project in NB, that is depending on other gradle projects is not able to use the classpaths given in the project settings (which are all shown)? Or is it just ignoring those?
>>>
>>> Further information:
>>> Windows 10, Gradle 7, OpenJdk 16
>>>
>>> --- Thanks in advance
>>> C.
>>
>
> ---------------------------------------------------------------------
> 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 support and depending projects
Posted by Christian Pervoelz <cp...@gmail.com>.
Great, thanks Laszlo.
Your hint seemed to be the last piece in that puzzle. The issues are gone
now.
---C.
Am Mo., 21. Juni 2021 um 18:38 Uhr schrieb Laszlo Kishalmi <
laszlo.kishalmi@gmail.com>:
> Please check the Experimental Gradle Settings and disable the Lazy
> Source Group Initialization.
>
> On 6/21/21 9:20 AM, Thomas Kellerer wrote:
> > For me, switchting to a different project groups fixes this error (at
> > least most of the time)
> >
> > Christian Pervoelz schrieb am 21.06.2021 um 15:34:
> >> Yes, usually that helps for me too, but here neither Clean&Build,
> >> restarting the IDE or just reloading the projects helped.
> >>
> >> After playing around a bit more, I had some findings:
> >>
> >> a) cleaning the cache in user dir brings some improvements
> >> So to say, almost all imports are resolved now (and due to that most
> >> of the other stuff works), except those from the other project in the
> >> container. And this issue disappears after another clean build (maybe
> >> or not).
> >> But of course, this is not a valid option for less experienced users.
> >>
> >> b) the issue seems to appear only, if I load the project for the very
> >> first time, so the gradle supports detects problems, which are to be
> >> resolved by a primer build
> >>
> >> c) as soon as any issue appears with the build files, the import
> >> statement issues are back
> >> Only restarting the IDE helps.
> >>
> >> d) between various restarts of the IDE the issues mentioned in the
> >> first mail might appear or not
> >>
> >> Hmm, very mysterious that.
> >>
> >> Anyway, it's hard to provide reliable steps to reproduce, as with
> >> another project container it didn't happen at all :(
> >>
> >> Thanks
> >> --- C.
> >>
> >>
> >>
> >> Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer
> >> <swpalmer@gmail.com <ma...@gmail.com>>:
> >>
> >> This usually goes away for me if I reload the project after
> >> building to ensure the classes being imported have been compiled. It
> >> would certainly be better if that wasn’t required.
> >>
> >> Scott
> >>
> >>> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz
> >>> <cpervoelz@gmail.com <ma...@gmail.com>> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I have a gradle container project consisting of two sub projects.
> >>> Clean, Build, Run, Debug, etc.works properly as it should from
> >>> NetBeans.
> >>>
> >>> But... every single import statement is marked as "package does
> >>> not exist". This applies to
> >>>
> >>> * imports from external libraries
> >>> * imports from the other project
> >>> * imports from the same project, but a different package
> >>>
> >>>
> >>> This causes a lot of follow-up problems (e.g. not working code
> >>> completion, tons of markers in the side bar about issues), which are
> >>> quite inconvenient to work with. It feels like working with a simple
> >>> text editor, that has a bit of code coloring and formatting
> >>> capabilities.
> >>> There is also another nasty side effect: When creating a new
> >>> class in a project, the file is created, but misses the package
> >>> declaration. (But even after adding it manually, the class is still
> >>> unknown to other classes)
> >>>
> >>>
> >>> So, my question is:
> >>> Might it be, that a gradle project in NB, that is depending on
> >>> other gradle projects is not able to use the classpaths given in the
> >>> project settings (which are all shown)? Or is it just ignoring those?
> >>>
> >>> Further information:
> >>> Windows 10, Gradle 7, OpenJdk 16
> >>>
> >>> --- Thanks in advance
> >>> C.
> >>
> >
> > ---------------------------------------------------------------------
> > 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 support and depending projects
Posted by Thomas Kellerer <sh...@gmx.net>.
I already did that.
With it enabled, NetBeans was pretty much unusable with our Gradle projects.
Laszlo Kishalmi schrieb am 21.06.2021 um 18:38:
> Please check the Experimental Gradle Settings and disable the Lazy Source Group Initialization.
>
> On 6/21/21 9:20 AM, Thomas Kellerer wrote:
>> For me, switchting to a different project groups fixes this error (at least most of the time)
>>
>> Christian Pervoelz schrieb am 21.06.2021 um 15:34:
>>> Yes, usually that helps for me too, but here neither Clean&Build, restarting the IDE or just reloading the projects helped.
>>>
>>> After playing around a bit more, I had some findings:
>>>
>>> a) cleaning the cache in user dir brings some improvements
>>> So to say, almost all imports are resolved now (and due to that most of the other stuff works), except those from the other project in the container. And this issue disappears after another clean build (maybe or not).
>>> But of course, this is not a valid option for less experienced users.
>>>
>>> b) the issue seems to appear only, if I load the project for the very first time, so the gradle supports detects problems, which are to be resolved by a primer build
>>>
>>> c) as soon as any issue appears with the build files, the import statement issues are back
>>> Only restarting the IDE helps.
>>>
>>> d) between various restarts of the IDE the issues mentioned in the first mail might appear or not
>>>
>>> Hmm, very mysterious that.
>>>
>>> Anyway, it's hard to provide reliable steps to reproduce, as with another project container it didn't happen at all :(
>>>
>>> Thanks
>>> --- C.
>>>
>>>
>>>
>>> Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer <swpalmer@gmail.com <ma...@gmail.com>>:
>>>
>>> This usually goes away for me if I reload the project after building to ensure the classes being imported have been compiled. It would certainly be better if that wasn’t required.
>>>
>>> Scott
>>>
>>>> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz <cpervoelz@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have a gradle container project consisting of two sub projects.
>>>> Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
>>>>
>>>> But... every single import statement is marked as "package does not exist". This applies to
>>>>
>>>> * imports from external libraries
>>>> * imports from the other project
>>>> * imports from the same project, but a different package
>>>>
>>>>
>>>> This causes a lot of follow-up problems (e.g. not working code completion, tons of markers in the side bar about issues), which are quite inconvenient to work with. It feels like working with a simple text editor, that has a bit of code coloring and formatting capabilities.
>>>> There is also another nasty side effect: When creating a new class in a project, the file is created, but misses the package declaration. (But even after adding it manually, the class is still unknown to other classes)
>>>>
>>>>
>>>> So, my question is:
>>>> Might it be, that a gradle project in NB, that is depending on other gradle projects is not able to use the classpaths given in the project settings (which are all shown)? Or is it just ignoring those?
>>>>
>>>> Further information:
>>>> Windows 10, Gradle 7, OpenJdk 16
>>>>
>>>> --- Thanks in advance
>>>> C.
>>>
>>
>> ---------------------------------------------------------------------
>> 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 support and depending projects
Posted by Laszlo Kishalmi <la...@gmail.com>.
Please check the Experimental Gradle Settings and disable the Lazy
Source Group Initialization.
On 6/21/21 9:20 AM, Thomas Kellerer wrote:
> For me, switchting to a different project groups fixes this error (at
> least most of the time)
>
> Christian Pervoelz schrieb am 21.06.2021 um 15:34:
>> Yes, usually that helps for me too, but here neither Clean&Build,
>> restarting the IDE or just reloading the projects helped.
>>
>> After playing around a bit more, I had some findings:
>>
>> a) cleaning the cache in user dir brings some improvements
>> So to say, almost all imports are resolved now (and due to that most
>> of the other stuff works), except those from the other project in the
>> container. And this issue disappears after another clean build (maybe
>> or not).
>> But of course, this is not a valid option for less experienced users.
>>
>> b) the issue seems to appear only, if I load the project for the very
>> first time, so the gradle supports detects problems, which are to be
>> resolved by a primer build
>>
>> c) as soon as any issue appears with the build files, the import
>> statement issues are back
>> Only restarting the IDE helps.
>>
>> d) between various restarts of the IDE the issues mentioned in the
>> first mail might appear or not
>>
>> Hmm, very mysterious that.
>>
>> Anyway, it's hard to provide reliable steps to reproduce, as with
>> another project container it didn't happen at all :(
>>
>> Thanks
>> --- C.
>>
>>
>>
>> Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer
>> <swpalmer@gmail.com <ma...@gmail.com>>:
>>
>> This usually goes away for me if I reload the project after
>> building to ensure the classes being imported have been compiled. It
>> would certainly be better if that wasn’t required.
>>
>> Scott
>>
>>> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz
>>> <cpervoelz@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I have a gradle container project consisting of two sub projects.
>>> Clean, Build, Run, Debug, etc.works properly as it should from
>>> NetBeans.
>>>
>>> But... every single import statement is marked as "package does
>>> not exist". This applies to
>>>
>>> * imports from external libraries
>>> * imports from the other project
>>> * imports from the same project, but a different package
>>>
>>>
>>> This causes a lot of follow-up problems (e.g. not working code
>>> completion, tons of markers in the side bar about issues), which are
>>> quite inconvenient to work with. It feels like working with a simple
>>> text editor, that has a bit of code coloring and formatting
>>> capabilities.
>>> There is also another nasty side effect: When creating a new
>>> class in a project, the file is created, but misses the package
>>> declaration. (But even after adding it manually, the class is still
>>> unknown to other classes)
>>>
>>>
>>> So, my question is:
>>> Might it be, that a gradle project in NB, that is depending on
>>> other gradle projects is not able to use the classpaths given in the
>>> project settings (which are all shown)? Or is it just ignoring those?
>>>
>>> Further information:
>>> Windows 10, Gradle 7, OpenJdk 16
>>>
>>> --- Thanks in advance
>>> C.
>>
>
> ---------------------------------------------------------------------
> 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 support and depending projects
Posted by Thomas Kellerer <sh...@gmx.net>.
For me, switchting to a different project groups fixes this error (at least most of the time)
Christian Pervoelz schrieb am 21.06.2021 um 15:34:
> Yes, usually that helps for me too, but here neither Clean&Build, restarting the IDE or just reloading the projects helped.
>
> After playing around a bit more, I had some findings:
>
> a) cleaning the cache in user dir brings some improvements
> So to say, almost all imports are resolved now (and due to that most of the other stuff works), except those from the other project in the container. And this issue disappears after another clean build (maybe or not).
> But of course, this is not a valid option for less experienced users.
>
> b) the issue seems to appear only, if I load the project for the very first time, so the gradle supports detects problems, which are to be resolved by a primer build
>
> c) as soon as any issue appears with the build files, the import statement issues are back
> Only restarting the IDE helps.
>
> d) between various restarts of the IDE the issues mentioned in the first mail might appear or not
>
> Hmm, very mysterious that.
>
> Anyway, it's hard to provide reliable steps to reproduce, as with another project container it didn't happen at all :(
>
> Thanks
> --- C.
>
>
>
> Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer <swpalmer@gmail.com <ma...@gmail.com>>:
>
> This usually goes away for me if I reload the project after building to ensure the classes being imported have been compiled. It would certainly be better if that wasn’t required.
>
> Scott
>
>> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz <cpervoelz@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> Hi,
>>
>> I have a gradle container project consisting of two sub projects.
>> Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
>>
>> But... every single import statement is marked as "package does not exist". This applies to
>>
>> * imports from external libraries
>> * imports from the other project
>> * imports from the same project, but a different package
>>
>>
>> This causes a lot of follow-up problems (e.g. not working code completion, tons of markers in the side bar about issues), which are quite inconvenient to work with. It feels like working with a simple text editor, that has a bit of code coloring and formatting capabilities.
>> There is also another nasty side effect: When creating a new class in a project, the file is created, but misses the package declaration. (But even after adding it manually, the class is still unknown to other classes)
>>
>>
>> So, my question is:
>> Might it be, that a gradle project in NB, that is depending on other gradle projects is not able to use the classpaths given in the project settings (which are all shown)? Or is it just ignoring those?
>>
>> Further information:
>> Windows 10, Gradle 7, OpenJdk 16
>>
>> --- Thanks in advance
>> C.
>
---------------------------------------------------------------------
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 support and depending projects
Posted by Christian Pervoelz <cp...@gmail.com>.
Yes, usually that helps for me too, but here neither Clean&Build,
restarting the IDE or just reloading the projects helped.
After playing around a bit more, I had some findings:
a) cleaning the cache in user dir brings some improvements
So to say, almost all imports are resolved now (and due to that most of the
other stuff works), except those from the other project in the container.
And this issue disappears after another clean build (maybe or not).
But of course, this is not a valid option for less experienced users.
b) the issue seems to appear only, if I load the project for the very first
time, so the gradle supports detects problems, which are to be resolved by
a primer build
c) as soon as any issue appears with the build files, the import statement
issues are back
Only restarting the IDE helps.
d) between various restarts of the IDE the issues mentioned in the first
mail might appear or not
Hmm, very mysterious that.
Anyway, it's hard to provide reliable steps to reproduce, as with another
project container it didn't happen at all :(
Thanks
--- C.
Am Mo., 21. Juni 2021 um 14:47 Uhr schrieb Scott Palmer <swpalmer@gmail.com
>:
> This usually goes away for me if I reload the project after building to
> ensure the classes being imported have been compiled. It would certainly
> be better if that wasn’t required.
>
> Scott
>
> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz <cp...@gmail.com>
> wrote:
>
>
> Hi,
>
> I have a gradle container project consisting of two sub projects.
> Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
>
> But... every single import statement is marked as "package does not
> exist". This applies to
>
> - imports from external libraries
> - imports from the other project
> - imports from the same project, but a different package
>
>
> This causes a lot of follow-up problems (e.g. not working code completion,
> tons of markers in the side bar about issues), which are quite inconvenient
> to work with. It feels like working with a simple text editor, that has a
> bit of code coloring and formatting capabilities.
> There is also another nasty side effect: When creating a new class in a
> project, the file is created, but misses the package declaration. (But even
> after adding it manually, the class is still unknown to other classes)
>
>
> So, my question is:
> Might it be, that a gradle project in NB, that is depending on other
> gradle projects is not able to use the classpaths given in the project
> settings (which are all shown)? Or is it just ignoring those?
>
> Further information:
> Windows 10, Gradle 7, OpenJdk 16
>
> --- Thanks in advance
> C.
>
>
Re: Gradle support and depending projects
Posted by Scott Palmer <sw...@gmail.com>.
This usually goes away for me if I reload the project after building to ensure the classes being imported have been compiled. It would certainly be better if that wasn’t required.
Scott
> On Jun 21, 2021, at 8:35 AM, Christian Pervoelz <cp...@gmail.com> wrote:
>
>
> Hi,
>
> I have a gradle container project consisting of two sub projects.
> Clean, Build, Run, Debug, etc.works properly as it should from NetBeans.
>
> But... every single import statement is marked as "package does not exist". This applies to
> imports from external libraries
> imports from the other project
> imports from the same project, but a different package
>
> This causes a lot of follow-up problems (e.g. not working code completion, tons of markers in the side bar about issues), which are quite inconvenient to work with. It feels like working with a simple text editor, that has a bit of code coloring and formatting capabilities.
> There is also another nasty side effect: When creating a new class in a project, the file is created, but misses the package declaration. (But even after adding it manually, the class is still unknown to other classes)
>
>
> So, my question is:
> Might it be, that a gradle project in NB, that is depending on other gradle projects is not able to use the classpaths given in the project settings (which are all shown)? Or is it just ignoring those?
>
> Further information:
> Windows 10, Gradle 7, OpenJdk 16
>
> --- Thanks in advance
> C.