You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2023/02/11 07:39:46 UTC
Gradle Distribution Settings
Dear all,
I'd like to collect some feedback on the Gradle Distribution Settings
(Tools > Options > Java > Gradle > Execution Panel > Distribution Section)
Over the years, Gradle evolved and some usage patterns has changed.
8 years ago, Gradle Daemon was in incubation phase. It could took a few
(5-10) seconds to start a daemon especially with HDDs.
People usually installed some latest Gradle and used that globally,
wrapper was not yet popular.
I think the following settings are obsolete:
- Start Gradle Daemon on IDE Start: Most people are using wrappers,
so a daemon with the IDE defined distribution, just wasting resources.
- Install Gradle Runtime Silently (Project trust is fine for that)
The following options are questionable:
Custom Gradle Distribution. (I think I've used only once around 2.3
when I built my own Gradle distribution due to a bug in Gradle)
The Gradle Distribution Selector Combo Box is over engineered. I would
replace that and the
"Prefer to Use Gradle Wrapper that Comes with the Project" check box in
a simple combo with elements:
Wrapper
8.0
7.6
....
3.0
I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
and there are a few versions which are not working well with NetBeans)
So at the end I would keep the Gradle Home and the combined distribution
selector. Probably move that to root project level as well.
What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle Distribution Settings
Posted by Michael Bien <mb...@gmail.com>.
sounds good to me.
regarding the gradle custom dist selection:
One argument for keeping it would be to have parity to maven which is
still fairly similar in setup, it has daemons, wrappers etc. The UI has
a dist selector too - I use that one sometimes. But I do also agree that
it is more common in gradle projects to use wrappers, while in maven
land it is still often expected that it is installed on your machine
like in old times.
if it isn't too difficult to maintain I would consider keeping that option.
also if you are planning to move elements around in the gradle options,
it would be worth thinking about trying to mirror it in the maven
options so that the UX is somewhat similar.
best regards,
michael
On 11.02.23 08:39, Laszlo Kishalmi wrote:
> Dear all,
>
> I'd like to collect some feedback on the Gradle Distribution Settings
> (Tools > Options > Java > Gradle > Execution Panel > Distribution
> Section)
>
> Over the years, Gradle evolved and some usage patterns has changed.
>
> 8 years ago, Gradle Daemon was in incubation phase. It could took a
> few (5-10) seconds to start a daemon especially with HDDs.
> People usually installed some latest Gradle and used that globally,
> wrapper was not yet popular.
>
> I think the following settings are obsolete:
> - Start Gradle Daemon on IDE Start: Most people are using wrappers,
> so a daemon with the IDE defined distribution, just wasting resources.
> - Install Gradle Runtime Silently (Project trust is fine for that)
>
> The following options are questionable:
> Custom Gradle Distribution. (I think I've used only once around 2.3
> when I built my own Gradle distribution due to a bug in Gradle)
>
> The Gradle Distribution Selector Combo Box is over engineered. I would
> replace that and the
> "Prefer to Use Gradle Wrapper that Comes with the Project" check box
> in a simple combo with elements:
> Wrapper
> 8.0
> 7.6
> ....
> 3.0
>
> I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
> and there are a few versions which are not working well with NetBeans)
>
> So at the end I would keep the Gradle Home and the combined
> distribution selector. Probably move that to root project level as well.
>
> What do you think?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle Distribution Settings
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 11 Feb 2023 at 07:41, Laszlo Kishalmi <la...@gmail.com> wrote:
> "Prefer to Use Gradle Wrapper that Comes with the Project" check box ...
> So at the end I would keep the Gradle Home and the combined distribution
> selector. Probably move that to root project level as well.
Well, I'd certainly appreciate the ability to ignore the wrapper
and/or a UI for easily switching the wrapper version on the root
project level. Even if some defaults are kept globally.
Out of interest, does the Gradle tooling API verify the wrapper files
against known checksums? Something akin to
https://github.com/gradle/wrapper-validation-action ? If not, that
might be a good part of our project trust support.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle Distribution Settings
Posted by Scott Palmer <sw...@gmail.com>.
I’m an odd ball with more than just my Gradle setup 🤣
Basically I just want to use the latest version unless I need to pin it down for compatibility. That lets me see when I’m using something that has been deprecated etc.
Regarding the Gradle User Home setting… I think these days the people that have multiple drives and need to have Gradle store artifacts outside of their home directory likely know various ways to make that happen (e.g. symlink or env var). As I stated, we don’t have a similar override for Maven (which has other ways to deal with it as well), so we don’t likely need this. In any case running from the command line, I doubt users would want to always type the --gradle-user-home option (or remember to if they’ve changed the setting in NB), they probably set the GRADLE_USER_HOME environment variable. That should solve the issue for NetBeans as well.
You could always keep the ability behind a more generic list of additional options to add to Gradle commands. Like the way you can add arguments to build actions from the project settings.
Cheers,
Scott
> On Feb 12, 2023, at 12:29 AM, Laszlo Kishalmi <la...@gmail.com> wrote:
>
> Dear Scott,
>
> You are an odd ball with your setup. I'm sure you are doing that for a reason, so that should be appreciated. Thank you for your feedback! It seems the custom distribution is here to stay.
>
> Setting the Gradle Home is for those (poor) people, who have limited space on their home directory (wrong PC setup, educational setups, etc.), so they could pack their stuff somewhere else.
>
> I'm going to think about your ideas as well! Once again, Thank you for speaking up!
>
>> On 2/11/23 15:32, Scott Palmer wrote:
>> Gradle wrapper should always be the default if it is initialized. So I would reverse the logic for the "Prefer to use Gradle Wrapper" checkbox and change the main part of the Gradle settings dialog to, e.g:
>>
>> [checkbox] Override Project Gradle Version
>>
>> Default Gradle Distribution:
>> [radio] Use Standard Gradle Version: [combobox]
>> [radio] Custom: [path field][browse button]
>>
>> If the wrapper isn't configured for a project, the default version is implied.
>>
>> "Gradle User Home" should be an advanced setting that isn't normally visible, or just remove it. There is no such setting to override the Maven Home, why do we have it for Gradle?
>> "Start Gradle Daemon on IDE Start" isn't needed. If you are opening Gradle projects as the IDE restores the last open projects, starting the daemons needed will happen anyway.
>> "Install Gradle Runtime Silently" isn't needed. It's implied that this will happen if "Default Gradle Distribution" is not set to "Custom"
>>
>> When a new project is made, it uses the Gradle init logic which will automatically configure the Gradle Wrapper with the default Gradle version. So most NB-created projects will have a "project" setting for what Gradle to use. The use of the wrapper is a best practice, so I think this makes sense.
>>
>> The Project Properties should show the current version configured for the Gradle Wrapper and allow it to be changed.
>> If the wrapper is not configured for a project, instead it should show a button to "Initialize Gradle Wrapper with Gradle version: [combobox]" The combobox includes all standard versions and is pre-selected with the word "Default" and the version number of "custom" in parenthesis. e.g. "Default (7.6)" or "Default (custom)"
>>
>> Regards,
>>
>> Scott
>>
>> On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer <sw...@gmail.com> wrote:
>>
>> I don't use the wrapper until a project is final or I have to
>> share it.
>> I am almost always on the bleeding edge as far as Gradle
>> versions. I keep all of my projects on the most recent Gradle
>> version when I work on them, often on the latest release candidate
>> (unless I encounter problems - which I want to be aware of so I
>> can report them or fix my scripts). The wrapper just adds
>> overhead for my day to day usage. I don't need a zillion versions
>> of Gradle cached on my system. If the project is to be shared,
>> then I add the wrapper because then it makes sense.
>>
>> My NB settings are such that I use a version of Gradle at a fixed
>> location via Custom Gradle Distribution, which is just a symlink
>> to the latest version of Gradle that I have downloaded. That
>> symlink is also on my path. So I'm using the latest Gradle in NB
>> and from the command line, unless I invoke the wrapper instead.
>>
>> So I don't want the Custom Gradle Distribution option to go away.
>>
>> The Gradle User Home option is useless to me. I don't understand
>> why I would ever want to change that. That's just asking for
>> trouble as then my command line builds would be doing something
>> different from my NB builds and I don't want that.
>> image.png
>> Scott
>>
>> On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi
>> <la...@gmail.com> wrote:
>>
>> Dear all,
>>
>> I'd like to collect some feedback on the Gradle Distribution
>> Settings
>> (Tools > Options > Java > Gradle > Execution Panel >
>> Distribution Section)
>>
>> Over the years, Gradle evolved and some usage patterns has
>> changed.
>>
>> 8 years ago, Gradle Daemon was in incubation phase. It could
>> took a few
>> (5-10) seconds to start a daemon especially with HDDs.
>> People usually installed some latest Gradle and used that
>> globally,
>> wrapper was not yet popular.
>>
>> I think the following settings are obsolete:
>> - Start Gradle Daemon on IDE Start: Most people are using
>> wrappers,
>> so a daemon with the IDE defined distribution, just wasting
>> resources.
>> - Install Gradle Runtime Silently (Project trust is fine
>> for that)
>>
>> The following options are questionable:
>> Custom Gradle Distribution. (I think I've used only once
>> around 2.3
>> when I built my own Gradle distribution due to a bug in Gradle)
>>
>> The Gradle Distribution Selector Combo Box is over engineered.
>> I would
>> replace that and the
>> "Prefer to Use Gradle Wrapper that Comes with the Project"
>> check box in
>> a simple combo with elements:
>> Wrapper
>> 8.0
>> 7.6
>> ....
>> 3.0
>>
>> I would drop the selection below at least 3.0 (Gradle 2.x are
>> ancient,
>> and there are a few versions which are not working well with
>> NetBeans)
>>
>> So at the end I would keep the Gradle Home and the combined
>> distribution
>> selector. Probably move that to root project level as well.
>>
>> What do you think?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Gradle Distribution Settings
Posted by Laszlo Kishalmi <la...@gmail.com>.
Dear Scott,
You are an odd ball with your setup. I'm sure you are doing that for a
reason, so that should be appreciated. Thank you for your feedback! It
seems the custom distribution is here to stay.
Setting the Gradle Home is for those (poor) people, who have limited
space on their home directory (wrong PC setup, educational setups,
etc.), so they could pack their stuff somewhere else.
I'm going to think about your ideas as well! Once again, Thank you for
speaking up!
On 2/11/23 15:32, Scott Palmer wrote:
> Gradle wrapper should always be the default if it is initialized. So
> I would reverse the logic for the "Prefer to use Gradle Wrapper"
> checkbox and change the main part of the Gradle settings dialog to, e.g:
>
> [checkbox] Override Project Gradle Version
>
> Default Gradle Distribution:
> [radio] Use Standard Gradle Version: [combobox]
> [radio] Custom: [path field][browse button]
>
> If the wrapper isn't configured for a project, the default version is
> implied.
>
> "Gradle User Home" should be an advanced setting that isn't normally
> visible, or just remove it. There is no such setting to override the
> Maven Home, why do we have it for Gradle?
> "Start Gradle Daemon on IDE Start" isn't needed. If you are opening
> Gradle projects as the IDE restores the last open projects, starting
> the daemons needed will happen anyway.
> "Install Gradle Runtime Silently" isn't needed. It's implied that
> this will happen if "Default Gradle Distribution" is not set to "Custom"
>
> When a new project is made, it uses the Gradle init logic which will
> automatically configure the Gradle Wrapper with the default Gradle
> version. So most NB-created projects will have a "project" setting
> for what Gradle to use. The use of the wrapper is a best practice, so
> I think this makes sense.
>
> The Project Properties should show the current version configured for
> the Gradle Wrapper and allow it to be changed.
> If the wrapper is not configured for a project, instead it should show
> a button to "Initialize Gradle Wrapper with Gradle version:
> [combobox]" The combobox includes all standard versions and is
> pre-selected with the word "Default" and the version number of
> "custom" in parenthesis. e.g. "Default (7.6)" or "Default (custom)"
>
> Regards,
>
> Scott
>
> On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer <sw...@gmail.com> wrote:
>
> I don't use the wrapper until a project is final or I have to
> share it.
> I am almost always on the bleeding edge as far as Gradle
> versions. I keep all of my projects on the most recent Gradle
> version when I work on them, often on the latest release candidate
> (unless I encounter problems - which I want to be aware of so I
> can report them or fix my scripts). The wrapper just adds
> overhead for my day to day usage. I don't need a zillion versions
> of Gradle cached on my system. If the project is to be shared,
> then I add the wrapper because then it makes sense.
>
> My NB settings are such that I use a version of Gradle at a fixed
> location via Custom Gradle Distribution, which is just a symlink
> to the latest version of Gradle that I have downloaded. That
> symlink is also on my path. So I'm using the latest Gradle in NB
> and from the command line, unless I invoke the wrapper instead.
>
> So I don't want the Custom Gradle Distribution option to go away.
>
> The Gradle User Home option is useless to me. I don't understand
> why I would ever want to change that. That's just asking for
> trouble as then my command line builds would be doing something
> different from my NB builds and I don't want that.
> image.png
> Scott
>
> On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi
> <la...@gmail.com> wrote:
>
> Dear all,
>
> I'd like to collect some feedback on the Gradle Distribution
> Settings
> (Tools > Options > Java > Gradle > Execution Panel >
> Distribution Section)
>
> Over the years, Gradle evolved and some usage patterns has
> changed.
>
> 8 years ago, Gradle Daemon was in incubation phase. It could
> took a few
> (5-10) seconds to start a daemon especially with HDDs.
> People usually installed some latest Gradle and used that
> globally,
> wrapper was not yet popular.
>
> I think the following settings are obsolete:
> - Start Gradle Daemon on IDE Start: Most people are using
> wrappers,
> so a daemon with the IDE defined distribution, just wasting
> resources.
> - Install Gradle Runtime Silently (Project trust is fine
> for that)
>
> The following options are questionable:
> Custom Gradle Distribution. (I think I've used only once
> around 2.3
> when I built my own Gradle distribution due to a bug in Gradle)
>
> The Gradle Distribution Selector Combo Box is over engineered.
> I would
> replace that and the
> "Prefer to Use Gradle Wrapper that Comes with the Project"
> check box in
> a simple combo with elements:
> Wrapper
> 8.0
> 7.6
> ....
> 3.0
>
> I would drop the selection below at least 3.0 (Gradle 2.x are
> ancient,
> and there are a few versions which are not working well with
> NetBeans)
>
> So at the end I would keep the Gradle Home and the combined
> distribution
> selector. Probably move that to root project level as well.
>
> What do you think?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Gradle Distribution Settings
Posted by Scott Palmer <sw...@gmail.com>.
Gradle wrapper should always be the default if it is initialized. So I
would reverse the logic for the "Prefer to use Gradle Wrapper" checkbox and
change the main part of the Gradle settings dialog to, e.g:
[checkbox] Override Project Gradle Version
Default Gradle Distribution:
[radio] Use Standard Gradle Version: [combobox]
[radio] Custom: [path field][browse button]
If the wrapper isn't configured for a project, the default version is
implied.
"Gradle User Home" should be an advanced setting that isn't normally
visible, or just remove it. There is no such setting to override the Maven
Home, why do we have it for Gradle?
"Start Gradle Daemon on IDE Start" isn't needed. If you are opening Gradle
projects as the IDE restores the last open projects, starting the daemons
needed will happen anyway.
"Install Gradle Runtime Silently" isn't needed. It's implied that this
will happen if "Default Gradle Distribution" is not set to "Custom"
When a new project is made, it uses the Gradle init logic which will
automatically configure the Gradle Wrapper with the default Gradle version.
So most NB-created projects will have a "project" setting for what Gradle
to use. The use of the wrapper is a best practice, so I think this makes
sense.
The Project Properties should show the current version configured for the
Gradle Wrapper and allow it to be changed.
If the wrapper is not configured for a project, instead it should show a
button to "Initialize Gradle Wrapper with Gradle version: [combobox]" The
combobox includes all standard versions and is pre-selected with the word
"Default" and the version number of "custom" in parenthesis. e.g. "Default
(7.6)" or "Default (custom)"
Regards,
Scott
On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer <sw...@gmail.com> wrote:
> I don't use the wrapper until a project is final or I have to share it.
> I am almost always on the bleeding edge as far as Gradle versions. I keep
> all of my projects on the most recent Gradle version when I work on
> them, often on the latest release candidate (unless I encounter problems -
> which I want to be aware of so I can report them or fix my scripts). The
> wrapper just adds overhead for my day to day usage. I don't need a zillion
> versions of Gradle cached on my system. If the project is to be shared,
> then I add the wrapper because then it makes sense.
>
> My NB settings are such that I use a version of Gradle at a fixed location
> via Custom Gradle Distribution, which is just a symlink to the
> latest version of Gradle that I have downloaded. That symlink is also on
> my path. So I'm using the latest Gradle in NB and from the command line,
> unless I invoke the wrapper instead.
>
> So I don't want the Custom Gradle Distribution option to go away.
>
> The Gradle User Home option is useless to me. I don't understand why I
> would ever want to change that. That's just asking for trouble as then my
> command line builds would be doing something different from my NB builds
> and I don't want that.
> [image: image.png]
> Scott
>
> On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Dear all,
>>
>> I'd like to collect some feedback on the Gradle Distribution Settings
>> (Tools > Options > Java > Gradle > Execution Panel > Distribution Section)
>>
>> Over the years, Gradle evolved and some usage patterns has changed.
>>
>> 8 years ago, Gradle Daemon was in incubation phase. It could took a few
>> (5-10) seconds to start a daemon especially with HDDs.
>> People usually installed some latest Gradle and used that globally,
>> wrapper was not yet popular.
>>
>> I think the following settings are obsolete:
>> - Start Gradle Daemon on IDE Start: Most people are using wrappers,
>> so a daemon with the IDE defined distribution, just wasting resources.
>> - Install Gradle Runtime Silently (Project trust is fine for that)
>>
>> The following options are questionable:
>> Custom Gradle Distribution. (I think I've used only once around 2.3
>> when I built my own Gradle distribution due to a bug in Gradle)
>>
>> The Gradle Distribution Selector Combo Box is over engineered. I would
>> replace that and the
>> "Prefer to Use Gradle Wrapper that Comes with the Project" check box in
>> a simple combo with elements:
>> Wrapper
>> 8.0
>> 7.6
>> ....
>> 3.0
>>
>> I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
>> and there are a few versions which are not working well with NetBeans)
>>
>> So at the end I would keep the Gradle Home and the combined distribution
>> selector. Probably move that to root project level as well.
>>
>> What do you think?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
Re: Gradle Distribution Settings
Posted by Scott Palmer <sw...@gmail.com>.
I don't use the wrapper until a project is final or I have to share it.
I am almost always on the bleeding edge as far as Gradle versions. I keep
all of my projects on the most recent Gradle version when I work on
them, often on the latest release candidate (unless I encounter problems -
which I want to be aware of so I can report them or fix my scripts). The
wrapper just adds overhead for my day to day usage. I don't need a zillion
versions of Gradle cached on my system. If the project is to be shared,
then I add the wrapper because then it makes sense.
My NB settings are such that I use a version of Gradle at a fixed location
via Custom Gradle Distribution, which is just a symlink to the
latest version of Gradle that I have downloaded. That symlink is also on
my path. So I'm using the latest Gradle in NB and from the command line,
unless I invoke the wrapper instead.
So I don't want the Custom Gradle Distribution option to go away.
The Gradle User Home option is useless to me. I don't understand why I
would ever want to change that. That's just asking for trouble as then my
command line builds would be doing something different from my NB builds
and I don't want that.
[image: image.png]
Scott
On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi <la...@gmail.com>
wrote:
> Dear all,
>
> I'd like to collect some feedback on the Gradle Distribution Settings
> (Tools > Options > Java > Gradle > Execution Panel > Distribution Section)
>
> Over the years, Gradle evolved and some usage patterns has changed.
>
> 8 years ago, Gradle Daemon was in incubation phase. It could took a few
> (5-10) seconds to start a daemon especially with HDDs.
> People usually installed some latest Gradle and used that globally,
> wrapper was not yet popular.
>
> I think the following settings are obsolete:
> - Start Gradle Daemon on IDE Start: Most people are using wrappers,
> so a daemon with the IDE defined distribution, just wasting resources.
> - Install Gradle Runtime Silently (Project trust is fine for that)
>
> The following options are questionable:
> Custom Gradle Distribution. (I think I've used only once around 2.3
> when I built my own Gradle distribution due to a bug in Gradle)
>
> The Gradle Distribution Selector Combo Box is over engineered. I would
> replace that and the
> "Prefer to Use Gradle Wrapper that Comes with the Project" check box in
> a simple combo with elements:
> Wrapper
> 8.0
> 7.6
> ....
> 3.0
>
> I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
> and there are a few versions which are not working well with NetBeans)
>
> So at the end I would keep the Gradle Home and the combined distribution
> selector. Probably move that to root project level as well.
>
> What do you think?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>