You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by Andreas Reichel <an...@manticore-projects.com> on 2021/08/21 00:34:27 UTC
Netbeans struggles with hierarchical Gradle Projects
Greetings.
Recently I migrated all my projects from ANT to Gradle and found that a
big enlightenment -- except that I struggle now with my beloved
Netbeans, which does not seem to support a hierarchical project
structure too well:
The ROOT project �has a build.gradle like this:
�allprojects {
repositories {
mavenLocal()
mavenCentral()
maven {
url 'https://oss.sonatype.org/content/repositories/snapshots'
}
}
wrapper {
gradleVersion = '7.1.1'
}
}
subprojects {
apply plugin: 'java'
dependencies {
implementation 'commons-io:commons-io:2.11.0'
implementation 'commons-codec:commons-codec:1.15'
....
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(11)
}
sourceSets {
main {
resources {
srcDirs "src/main/java"
}
}
}
}
}
The ROOT settings.gradle looks like this:
rootProject.name = 'VBox'
include 'ETLBox', 'IFRSBox', 'RISKBox', 'PROFITBox', 'Common', 'Icon', 'Utilities', 'SwingUI'
Under the ROOT project there are four library projects: Common, Icon,
SwingUI and Utilities.
They have similar �build.gradle files:
ROOT/Utilities:
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
ROOT/SwingUI:
plugins {
id 'application'
}
dependencies {
implementation project(':Utilities')
implementation project(':Icon')
}
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
Problem 1:
For any reason, SwingUI is shown correctly as a VBox Subproject, but
Common and Icon are not.
Problem 2:
Netbeans does not seem to resolve the imported external dependencies
for the sub projects. Neither does it resolve the classes for the
siblings projects.
(Although it is able to compile and run the Application projects with
Gradle).
I do not think that I made too many mistakes in setting it up because
the very same Gradle structure works perfectly fine in Idea Intelly-J
and allows me to open, edit , compile and debug all parts. Also Gradle
from the command line works just fine of course.
Can someone explain please, what is going on and how to fix it?
I feel more and more tempted/forced to switch to �Idea Intelly-J
although I still do not like it and really would love to stick with
Netbeans.
Please let me know if you need any more information or details.
Thank you a lot in advance!
Andreas
Re: Netbeans struggles with hierarchical Gradle Projects --> Solved!
Posted by Andreas Reichel <an...@manticore-projects.com>.
Dear All,
thank for the feedback and suggestions.
I have been able to find the problem and to solve it: Ignorantly I had
put a gradle.settings not only into the ROOT folder, but also into each
sub-project and these gradle.settings had defined a rootProject.name
each.
After having deleted these redundant gradle.settings in the sub-
projects, everything works great!
@Laszlo, two suggestions please:
1) Maybe ignore and/or warn about such incorrect settings, when they
confuse Netbeans.
After all, Command Line Gradle and also Intelli-J had not problems with
it and so I still think that I was not totally wrong, while not being
correct either.
2) Maybe double check, while the behaviour was so inconsistent and 4
out of 6 sub-projects were understood by Netbeans while 2 were
interpreted differently.
To me, this was actually the most confusing part.
Anyway, I am good now and would like to thank you so much.
Best regards and cheers
Andreas
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Andreas Reichel <an...@manticore-projects.com>.
Thank you so much Laszlo, your value explanation is much appreciated
and I will consider it now.
Best regards
Andreas
On Sat, 2021-08-21 at 07:57 -0700, Laszlo Kishalmi wrote:
> I'm sorry being short at the first.
> In general specifying version in build is a bad practice. The version
> is not a property of a build process, as long as you have the code in
> hand you should keep that "versionless". Version is a property of the
> release process.
> The build process shall be merely responsible to create an executable
> (reusable) package from the source code.
> The release process shall be responsible to:
> 1. Get a specific source code
> 2. Assign a version to the release
> 3. Create a versioned executable (reusable) package using the build
> process
> 4. Tag the sources
> 5. Upload the versioned packages to a binary repository for further
> use
> Due to some initial technical limitation Maven made version a
> required part of their build. That would result a lot of workarounds
> to put in place, like SNAPSHOT versions, a specific step in maven
> projects to change the version in each and every pom.xml in the
> project before release, etc.
>
> In Gradle version is optional.
>
> The best use of the version property is:
>
> ./gradlew -Pversion=1.2.3 clean build
>
> when the release comes.
>
> OpenJFX project had a problem with it as they generated second
> precision version for their artifacts, so when the dependencies were
> resolved in different times they would reference different jars, so
> NetBeans was not able to connect the dependencies between modules
> with versions crested a few seconds apart.
>
> I would check the project properties for classpath.
>
> Also make sure that the Tools > Options > Java > Gradle >
> Experimental > Enable 'lazy' Source Group Initialization is turned
> off.
>
> You may test NetBeans 12.5-beta1
>
> On 8/20/21 10:43 PM, Andreas Reichel wrote:
>
> >
> > Greetings.
> >
> > On Fri, 2021-08-20 at 18:52 -0700, Laszlo Kishalmi wrote:
> >
> > > Try to get rid of the version specification.
> >
> > I have tried that just because I am desperate and ready to grab any
> > straw.
> > Unfortunately it did not change anything -- and why should it.
> >
> >
> > > What you are doing there is a bad practice.
> >
> > Says who and why. Please elaborate.
> >
> > Best regards
> > Andreas
> >
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Laszlo Kishalmi <la...@gmail.com>.
I'm sorry being short at the first.
In general specifying version in build is a bad practice. The version is
not a property of a build process, as long as you have the code in hand
you should keep that "versionless". Version is a property of the release
process.
The build process shall be merely responsible to create an executable
(reusable) package from the source code.
The release process shall be responsible to:
1. Get a specific source code
2. Assign a version to the release
3. Create a versioned executable (reusable) package using the build
process
4. Tag the sources
5. Upload the versioned packages to a binary repository for further use
Due to some initial technical limitation Maven made version a required
part of their build. That would result a lot of workarounds to put in
place, like SNAPSHOT versions, a specific step in maven projects to
change the version in each and every pom.xml in the project before
release, etc.
In Gradle version is optional.
The best use of the version property is:
./gradlew -Pversion=1.2.3 clean build
when the release comes.
OpenJFX project had a problem with it as they generated second precision
version for their artifacts, so when the dependencies were resolved in
different times they would reference different jars, so NetBeans was not
able to connect the dependencies between modules with versions crested a
few seconds apart.
I would check the project properties for classpath.
Also make sure that the Tools > Options > Java > Gradle > Experimental >
Enable 'lazy' Source Group Initialization is turned off.
You may test NetBeans 12.5-beta1
On 8/20/21 10:43 PM, Andreas Reichel wrote:
> Greetings.
>
> On Fri, 2021-08-20 at 18:52 -0700, Laszlo Kishalmi wrote:
>> Try to get rid of the version specification.
>
> I have tried that just because I am desperate and ready to grab any straw.
> Unfortunately it did not change anything -- and why should it.
>
>> What you are doing there is a bad practice.
>
> Says who and why. Please elaborate.
>
> Best regards
> Andreas
>
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Andreas Reichel <an...@manticore-projects.com>.
Greetings.
On Sat, 2021-08-21 at 10:57 +0300, Emilian Bold wrote:
> > > What you are doing there is a bad practice.
> > Says who and why. Please elaborate.
>
> :-) Says the guy that wrote the Gradle support in NetBeans and that
> (as far as I remember) has a job related to builds and stuff like
> this.
Pardon me for speaking blunt: I would not trust the Pope telling me
what was good or bad -- especially not the pope.
I am certain that Laszlo is right and I am eager to learn, but I would
like to understand the rational and make an informed decision myself.
Also, I tried it and it did not change anything (except changing the
name of the JAR files).
>
> Unlike Ant/Maven it's a pain to learn.
Well, I beg to disagree.
I was very reluctant to migrate from ANT for a very long time until I
was forced to do. Then I tried Gradle and coursed myself for being so
reluctant for so long time. I despise Maven from heart, but Gradle
thinks like me and I really like it. The migration was super easy.
And it works beautifully with IntelliJ and Command Line. Just not with
Netbeans :-(
Cheers
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Emilian Bold <em...@gmail.com>.
>> What you are doing there is a bad practice.
> Says who and why. Please elaborate.
:-) Says the guy that wrote the Gradle support in NetBeans and that
(as far as I remember) has a job related to builds and stuff like
this.
I have nothing else to add. Gradle is great as long as somebody else
configures it properly. Parallel builds and build caches are magic.
Unlike Ant/Maven it's a pain to learn.
--emi
On Sat, Aug 21, 2021 at 8:44 AM Andreas Reichel
<an...@manticore-projects.com> wrote:
>
> Greetings.
>
> On Fri, 2021-08-20 at 18:52 -0700, Laszlo Kishalmi wrote:
>
> Try to get rid of the version specification.
>
>
> I have tried that just because I am desperate and ready to grab any straw.
> Unfortunately it did not change anything -- and why should it.
>
> What you are doing there is a bad practice.
>
>
> Says who and why. Please elaborate.
>
> Best regards
> Andreas
>
---------------------------------------------------------------------
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: Netbeans struggles with hierarchical Gradle Projects
Posted by Andreas Reichel <an...@manticore-projects.com>.
Greetings.
On Fri, 2021-08-20 at 18:52 -0700, Laszlo Kishalmi wrote:
> Try to get rid of the version specification.
I have tried that just because I am desperate and ready to grab any
straw.
Unfortunately it did not change anything -- and why should it.
> �What you are doing there is a bad practice.
Says who and why. Please elaborate.
Best regards
Andreas
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Andreas Reichel <an...@manticore-projects.com>.
Thank you Bernd,
On Sat, 2021-08-21 at 20:01 +0200, Bernd Michaely wrote:
> Is it good practice to define the resources dir equal to the src dir?
certainly not best practise, but an ANT legacy.
To make things worse, it is auto-generating code which declares static
resource variables for a folder of icons. You will get Icon enums at
the end of it, which is very practical for UIs but certainly ugly
regarding coding conventions.
Though nothing I would like to touch right now, because it just works.
Cheers
Andreas
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well that is a heritage from Ant I guess, though the statement only adds
a new resourcedir to the set of resourcedirs
It would be better to use:
sourceSets.main.resources.srcDirs = files('src/main/java')
Though that would be just a slight change. Also an exclude for
"**/*.java" might be desired here.
Though mixing the sources and resources together might be not ideal,
usually it is not a problem for Gradle.
On 8/21/21 11:01 AM, Bernd Michaely wrote:
>
> Hi,
>
> I'm just curious,
>
> sourceSets {
> main {
> resources {
> srcDirs"src/main/java" }
> }
> }
>
> Is it good practice to define the resources dir equal to the src dir?
>
> I think, this might cause problems including:
>
> * it (at least unnecessarily) confuses Gradle's build cache
> * resources are deployed to the final result, so sources might be
> deployed together with the them
> * NB show src and resources separately in the logical Projects view
> and might be confused about this configuration
>
> Greetings,
>
> Bernd
>
>
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Bernd Michaely <in...@bernd-michaely.de>.
Hi,
I'm just curious,
sourceSets {
main {
resources {
srcDirs"src/main/java" }
}
}
Is it good practice to define the resources dir equal to the src dir?
I think, this might cause problems including:
* it (at least unnecessarily) confuses Gradle's build cache
* resources are deployed to the final result, so sources might be
deployed together with the them
* NB show src and resources separately in the logical Projects view
and might be confused about this configuration
Greetings,
Bernd
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Laszlo Kishalmi <la...@gmail.com>.
Try to get rid of the version specification. What you are doing there is
a bad practice.
On 8/20/21 5:34 PM, Andreas Reichel wrote:
> Greetings.
>
> Recently I migrated all my projects from ANT to Gradle and found that
> a big enlightenment -- except that I struggle now with my beloved
> Netbeans, which does not seem to support a hierarchical project
> structure too well:
>
> The ROOT project has a build.gradle like this:
>
> allprojects {
> repositories {
> mavenLocal()
> mavenCentral()
> maven {
> url 'https://oss.sonatype.org/content/repositories/snapshots'
> <https://oss.sonatype.org/content/repositories/snapshots'> }
> }
>
> wrapper {
> gradleVersion = '7.1.1' }
> }
>
> subprojects {
> apply plugin:'java' dependencies {
> implementation'commons-io:commons-io:2.11.0' implementation'commons-codec:commons-codec:1.15' ....}
>
> java {
> toolchain {
> languageVersion= JavaLanguageVersion.of(11)
> }
>
> sourceSets {
> main {
> resources {
> srcDirs"src/main/java" }
> }
> }
> }
> }
> The ROOT settings.gradle looks like this:
> rootProject.name = 'VBox' include 'ETLBox','IFRSBox','RISKBox','PROFITBox','Common','Icon','Utilities','SwingUI'
> Under the ROOT project there are four library projects: Common, Icon,
> SwingUI and Utilities.
> They have similar build.gradle files:
>
>
> ROOT/Utilities:
>
> def getVersion = { ->
> def outputStream = new ByteArrayOutputStream()
> exec {
> commandLine "/usr/bin/hg","log","-r","tip","--template","{latesttag}.{latesttagdistance}-{node|short}" standardOutput =
> outputStream }
> return outputStream.toString().trim()
> }
>
> version = getVersion()
>
> ROOT/SwingUI:
>
> plugins {
> id 'application' }
>
> dependencies {
> implementation project(':Utilities')
> implementation project(':Icon')
> }
>
> def getVersion = { ->
> def outputStream = new ByteArrayOutputStream()
> exec {
> commandLine "/usr/bin/hg","log","-r","tip","--template","{latesttag}.{latesttagdistance}-{node|short}" standardOutput =
> outputStream }
> return outputStream.toString().trim()
> }
>
> version = getVersion()
>
>
> *Problem 1:*
>
>
> For any reason, SwingUI is shown correctly as a VBox Subproject, but
> Common and Icon are not.
>
>
> Problem 2:
>
>
> Netbeans does not seem to resolve the imported external dependencies
> for the sub projects. Neither does it resolve the classes for the
> siblings projects.
> (Although it is able to compile and run the Application projects with
> Gradle).
>
>
>
> I do not think that I made too many mistakes in setting it up because
> the very same Gradle structure works perfectly fine in Idea Intelly-J
> and allows me to open, edit , compile and debug all parts. Also Gradle
> from the command line works just fine of course.
>
> Can someone explain please, what is going on and how to fix it?
> I feel more and more tempted/forced to switch to Idea Intelly-J
> although I still do not like it and really would love to stick with
> Netbeans.
>
> Please let me know if you need any more information or details.
> Thank you a lot in advance!
> Andreas
>
>
>
>
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Scott Palmer <sw...@gmail.com>.
The ‘compile’ configuration shouldn’t be used. It has been deprecated[1][2] in favour of ‘implementation’ and ‘api’ for a long time now. It is no-longer available in Gradle 7.[3]
Scott
[1] https://docs.gradle.org/current/userguide/upgrading_version_5.html#changes_6.0
[2] https://stackoverflow.com/questions/44413952/gradle-implementation-vs-api-configuration
[3] https://docs.gradle.org/current/userguide/upgrading_version_6.html
> On Aug 21, 2021, at 2:22 AM, Rob Walker <ro...@ascert.com.invalid> wrote:
>
>
> Just doing a quick doc scan – and the “implementation” configuration is documented as part of the java-library plugin:
>
> plugins {
> id 'java-library'
> }
>
> But your config below seems to be using the normal java plugin (which is what provides the normal “compile” configurations that I mention below)
>
> subprojects {
> apply plugin: 'java'
>
> dependencies {
> implementation 'commons-io:commons-io:2.11.0'
>
> implementation 'commons-codec:commons-codec:1.15'
>
> ....
>
> }
>
> Could also be worth digging into.
>
> ---
> Rob Walker
>
>
RE: Netbeans struggles with hierarchical Gradle Projects
Posted by Rob Walker <ro...@ascert.com.INVALID>.
Just doing a quick doc scan – and the “implementation” configuration is documented as part of the java-library plugin<https://docs.gradle.org/current/userguide/java_library_plugin.html>:
plugins {
id 'java-library'
}
But your config below seems to be using the normal java plugin (which is what provides the normal “compile” configurations that I mention below)
subprojects {
apply plugin: 'java'
dependencies {
implementation 'commons-io:commons-io:2.11.0'
implementation 'commons-codec:commons-codec:1.15'
....
}
Could also be worth digging into.
---
Rob Walker
From: Rob Walker
Sent: 21 August 2021 07:18
To: Andreas Reichel <an...@manticore-projects.com>; users <us...@netbeans.apache.org>
Subject: RE: Netbeans struggles with hierarchical Gradle Projects
NB definitely works for sub projects, we have a couple of large ones – it can be finnicky, but with all the dependencies in place it seems to work.
I’m not a Gradle expert, but I’m guessing “implementation” must be a configuration phase which includes “compile” in our case, we use “compile” e.g.
dependencies {
compile project(':Utilities')
compile project(':Icon')
}
One observation is that your ROOT/Utilities doesn’t seem to have any build tasks or other info in it – maybe Netbeans doesn’t like that. Perhaps try adding a “description=” also, maybe even some fake dependencies. Could be that such a minimal gradle file is ending up nulled out. Something to wake NB up to it being a set of Java sources that it recognizes as needing building.
Other than that, I’d say persevere and experiment – once we got our sub-project setup into NB it’s worked pretty well.
---
Rob Walker
From: Andreas Reichel <an...@manticore-projects.com>>
Sent: 21 August 2021 01:34
To: users <us...@netbeans.apache.org>>
Subject: Netbeans struggles with hierarchical Gradle Projects
Greetings.
Recently I migrated all my projects from ANT to Gradle and found that a big enlightenment -- except that I struggle now with my beloved Netbeans, which does not seem to support a hierarchical project structure too well:
The ROOT project has a build.gradle like this:
allprojects {
repositories {
mavenLocal()
mavenCentral()
maven {
url 'https://oss.sonatype.org/content/repositories/snapshots'
}
}
wrapper {
gradleVersion = '7.1.1'
}
}
subprojects {
apply plugin: 'java'
dependencies {
implementation 'commons-io:commons-io:2.11.0'
implementation 'commons-codec:commons-codec:1.15'
....
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(11)
}
sourceSets {
main {
resources {
srcDirs "src/main/java"
}
}
}
}
}
The ROOT settings.gradle looks like this:
rootProject.name = 'VBox'
include 'ETLBox', 'IFRSBox', 'RISKBox', 'PROFITBox', 'Common', 'Icon', 'Utilities', 'SwingUI'
Under the ROOT project there are four library projects: Common, Icon, SwingUI and Utilities.
They have similar build.gradle files:
ROOT/Utilities:
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
ROOT/SwingUI:
plugins {
id 'application'
}
dependencies {
implementation project(':Utilities')
implementation project(':Icon')
}
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
Problem 1:
For any reason, SwingUI is shown correctly as a VBox Subproject, but Common and Icon are not.
[cid:image001.png@01D7965D.4D4C4D10]
Problem 2:
Netbeans does not seem to resolve the imported external dependencies for the sub projects. Neither does it resolve the classes for the siblings projects.
(Although it is able to compile and run the Application projects with Gradle).
[cid:image002.png@01D7965D.4D4C4D10]
I do not think that I made too many mistakes in setting it up because the very same Gradle structure works perfectly fine in Idea Intelly-J and allows me to open, edit , compile and debug all parts. Also Gradle from the command line works just fine of course.
Can someone explain please, what is going on and how to fix it?
I feel more and more tempted/forced to switch to Idea Intelly-J although I still do not like it and really would love to stick with Netbeans.
Please let me know if you need any more information or details.
Thank you a lot in advance!
Andreas
RE: Netbeans struggles with hierarchical Gradle Projects
Posted by Rob Walker <ro...@ascert.com.INVALID>.
NB definitely works for sub projects, we have a couple of large ones – it can be finnicky, but with all the dependencies in place it seems to work.
I’m not a Gradle expert, but I’m guessing “implementation” must be a configuration phase which includes “compile” in our case, we use “compile” e.g.
dependencies {
compile project(':Utilities')
compile project(':Icon')
}
One observation is that your ROOT/Utilities doesn’t seem to have any build tasks or other info in it – maybe Netbeans doesn’t like that. Perhaps try adding a “description=” also, maybe even some fake dependencies. Could be that such a minimal gradle file is ending up nulled out. Something to wake NB up to it being a set of Java sources that it recognizes as needing building.
Other than that, I’d say persevere and experiment – once we got our sub-project setup into NB it’s worked pretty well.
---
Rob Walker
From: Andreas Reichel <an...@manticore-projects.com>
Sent: 21 August 2021 01:34
To: users <us...@netbeans.apache.org>
Subject: Netbeans struggles with hierarchical Gradle Projects
Greetings.
Recently I migrated all my projects from ANT to Gradle and found that a big enlightenment -- except that I struggle now with my beloved Netbeans, which does not seem to support a hierarchical project structure too well:
The ROOT project has a build.gradle like this:
allprojects {
repositories {
mavenLocal()
mavenCentral()
maven {
url 'https://oss.sonatype.org/content/repositories/snapshots'
}
}
wrapper {
gradleVersion = '7.1.1'
}
}
subprojects {
apply plugin: 'java'
dependencies {
implementation 'commons-io:commons-io:2.11.0'
implementation 'commons-codec:commons-codec:1.15'
....
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(11)
}
sourceSets {
main {
resources {
srcDirs "src/main/java"
}
}
}
}
}
The ROOT settings.gradle looks like this:
rootProject.name = 'VBox'
include 'ETLBox', 'IFRSBox', 'RISKBox', 'PROFITBox', 'Common', 'Icon', 'Utilities', 'SwingUI'
Under the ROOT project there are four library projects: Common, Icon, SwingUI and Utilities.
They have similar build.gradle files:
ROOT/Utilities:
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
ROOT/SwingUI:
plugins {
id 'application'
}
dependencies {
implementation project(':Utilities')
implementation project(':Icon')
}
def getVersion = { ->
def outputStream = new ByteArrayOutputStream()
exec {
commandLine "/usr/bin/hg", "log", "-r", "tip", "--template", "{latesttag}.{latesttagdistance}-{node|short}"
standardOutput = outputStream
}
return outputStream.toString().trim()
}
version = getVersion()
Problem 1:
For any reason, SwingUI is shown correctly as a VBox Subproject, but Common and Icon are not.
[cid:image002.png@01D7965C.5A7F78A0]
Problem 2:
Netbeans does not seem to resolve the imported external dependencies for the sub projects. Neither does it resolve the classes for the siblings projects.
(Although it is able to compile and run the Application projects with Gradle).
[cid:image003.png@01D7965C.5A7F78A0]
I do not think that I made too many mistakes in setting it up because the very same Gradle structure works perfectly fine in Idea Intelly-J and allows me to open, edit , compile and debug all parts. Also Gradle from the command line works just fine of course.
Can someone explain please, what is going on and how to fix it?
I feel more and more tempted/forced to switch to Idea Intelly-J although I still do not like it and really would love to stick with Netbeans.
Please let me know if you need any more information or details.
Thank you a lot in advance!
Andreas
Re: Netbeans struggles with hierarchical Gradle Projects
Posted by Andreas Reichel <an...@manticore-projects.com>.
On Sat, 2021-08-21 at 07:34 +0700, Andreas Reichel wrote:
> Problem 1:
>
> For any reason, SwingUI is shown correctly as a VBox Subproject, but
> Common and Icon are not.
Correction:
For any reason, SwingUI and Common are shown correctly as a VBox
Subproject, but Utilities and Icon are not.