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 thes
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://stackoverfl
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
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
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 desir
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
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 me
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
>> 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
co
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 pract
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.
11 matches
Mail list logo
