Added the URL where the user had raised this issue!

Well it is hard to discuss the issue while part of the discussion is on mailing list.

I agree with Geertjan. Do we really want to offer project type for any new technology? The same could be applied to
Struts, Spring, basically anything else. The approach "I don't know what the Struts|Spring|Groovy is so I expect there
will be Struts|Spring|Groovy project type" is imo not the case we should optimize for. Anyway if we will provide the
suggested solution what will be the feeling the mentioned user gets - he will select Groovy project and ends up with
Java Project. He will suppose he made a mistake and will try it again. After that he will probably file a P1 issue or he
will take some time and will investigate the properties.

The argument about other IDEs is not valid afaik. Actually we would be (and we are in other areas) different. In other
IDEs you usually select one of the "supports" (favors, faces... don't know the term) you want to use in project (it
would be great to have such panel in project wizard). In fact the Groovy with its Java project integration is pioneering
it. If we will add other languages or frameworks that can integrate with java do we really want to add project type for
each of them? If we will enable the groovy in web project sometime in future should we introduce another web project link?

Actually I think there was a real Groovy project type in the past, but it was discarded and Groovy users appreciate that.

I agree that automatically adding a new project type might be problematic, especially if this proliferates. E.g., what
if someone wants a project with both Groovy, SAF, and other libraries. It might be confusing if we have a project type
for each but not for the combinations.

That said, I think the issue is still valid. Groovy is not very discoverable now. The question is whether we can make it
more discoverable and do so in a way that doesn't create side effects that outweigh the benefits.

Adding HIE engineer on cc.

I don't see any harm in having other links which lead folks down certain paths for very popular frameworks or
technologies such as Groovy. Yes, I think it would be a good idea if gsp and other things become supported to have a
Groovy Web Project. Most likely if someone is going to go down the .gsp route that is going to be their predominate use
case in that particular project, and the point is to get them past that hiccup and to address new user retention. 

Just like with a web site, a new car, or anything else you can think of practically, the first impressions are what
drive new folks looking for their specific needs to be filled. Options are not going to bother someone who knows their
way around, but for new folks it will help them.

The project support already has a pretty good mechanism for guidance all though simple where there is a project type
(which can simply link to other project types) and a description. The current Java description states:
"Creates a new Java SE application in a standard IDE project. You can also generate a main class in the project.
Standard projects use an IDE-generated Ant build script to build, run, and debug your project."

It could mention that it supports other file types, and what else can be done instead of having such a narrowed description.

New Project|Groovy|Groovy Application Project could be something as simple as 
"Groovy support is built into the standard Java projects. Creates a new Java SE application in a standard IDE project.
You can also generate a main Java or Groovy class in the project. Standard projects use an IDE-generated Ant build
script to build, run, and debug your project. See New File|Groovy once your project is created.".

Very low tech, but gets the job done. Can easily be installed by the Groovy support and similar by other support
modules. I think things like Groovy at least, and maybe even things like Spring or Struts2, not Hibernate or Struts1,
deserve their own project types just like a JRuby project or something. Sure, Groovy is using Java and can blend, but
one can just make an all Groovy project basically just the same as they could with JRuby using .jars as libraries. So,
they are technologies which blend with Java, but have differences, and uses where they will be the primary consideration.

Now, if it is an issue of whether those things get in the way of users, then allow users to hide and show things in the
new project wizard.

Now, if some kind of a new "New Project" wizard were created which is smarter that would be even better, maybe it
doesn't even replace the main new project wizard, but instead is another option under categories "Can't find what you
are looking for?", and it goes into another sub wizard, or is a link beside "Choose project" called "Can't find what you
are looking for?". 

It could do something like ask a user to select technologies they would like to support in a project. Each project or
technology support plugin registers some information, and this is shown in a list. Based on selections, options are
provided with explanations, also built from this meta information provided by support modules, that allow the user to
pick what it is they would like to do. This could even go as far as to find out if they need a desktop or web client and
offer other suggestions for what types of projects to use, so instead of creating a single project walk them down the
path to setup the server and client projects and possibly others than may need.

>Now, if it is an issue of whether those things get in 
>the way of users, then allow users to hide and show things in the
>new project wizard.

Here I mean to give the users a panel under Tools|Options, whether in miscellaneous or not, which allows them to uncheck
project templates and categories they don't want to see.

I've been asked to provide HIE viewpoint on this issue, but it is not going to be simple yes/no opinion.

I would say that this approach needs to be considered carefully as it may (as Patrick mentioned) proliferate to other
technologies which is probably not what we want. Whether it will or will not be done should IMO depend on the number of
Groovy users and on their "priority".

The core of the problem seems to be that users are not only not directed towards Java project (by Java project
description not mentioning Groovy in any way), but even led away from it (by existence of separate Groovy category .. i
do not have much domain knowledge in this field, but shouldn't the category be called Grails instead if it only contains
Grails project?). Even though someone knows that Groovy blends with Java, naturally they will first look in Groovy
category if they spot it. After that, they may be left thinking why it is not in the groovy category and trying get it
there .. (enabling modules in plugin manager, etc .. ). So maybe the discoverability issue could really be solved by
other means?

As a side-note, multiple ways of achieving the same thing do create UI clutter and as such are not always good.
Sometimes the benefits outweigh the drawbacks, whether this is the case depends on how the relation of groovy and java
is understood, on number of groovy users and their "priority". I would certainly be against customization of new project
wizard as it doesn't address the original problem, only would be used by a few enthusiasts and .. honestly speaking ..
I'm worried it could be used as argument for "let's make the new project categories a mess .. users can disable the ones
they do not want anyway" ;)

I don't want this to sound like I'm beating a dead horse here, as I'm actually not trying to be argumentative, nor do I
intend to bash. My main and ultimate goal is to help make the IDE as best as it can possibly be from the community user
perspective and an advertised and project faith, popularity, or trust perspective. This is actually my only reason for
creating this issue as the user perspective is what drives those users to see in NB that which they see, and to get from
it what they may, and that in turn keeps the project going which is good for all involved, and is the only true reason
the project exists, because without users what is it.

Priority is a bit subjective to me in this context. There is Groovy support in Java projects. There is then the ability
to set a Groovy class as the main class of a project. There are other IZ issues dealing with how one should be able to
use a Groovy class with script outside of a method, and use that script/code versus using static void main, and others.
Basically Java projects will probably have to directly support things alien to strict Java developers if those abilities
are not pluggable in the Java projects infrastructure...i.e. Groovy turned off then the Java projects have to change the
UI probably without a direct dependency from Java->Groovy but the other way around unless of course the Groovy project
is replacing some of those Java project UI panels, actions, etc. None the less the Groovy support is there now.

Now, I am not really using Groovy for projects at the moment, but I have thought about looking at it for different
things. I know some people who are using it for a lot of things. The support is there. To me, if something is in the IDE
it should be as usable as possible, or maybe should not be there, and of course this is an opinion and subjective as
well. This is where priority becomes subjective too. As the support is there, I would expect it to be as usable as
possible, and as accessible as possible, to not be ignored, not used, and wasted by users as I was raised to have a
general rule that if I am going to do something to do it right, or not do it at all. But too, from conversations I see
in the NB community others have a similar view.

The point to that statement lies in the fact that the main way for users to create a Groovy project or any other project
for a different technology would presumably be through the new project wizard, and that makes sense because while Groovy
can be used with Java, it is an extending language; a new or other technology if you will. You don't have to define any
.java files in a Groovy application, so they can be used together, and both can technically be a separate thing. Thus
some users may very well infer, as the person from the linked URL does, that the only Groovy support is through Grails.
This in turn naturally means the feature isn't used as much as it may otherwise be used depending upon how usable and
accessible it is.

Essentially, the release notes mark this as a milestone for NB 6.5:
http://www.netbeans.org/community/releases/65/

and thus is advertising something for use. If that is put out there, then it should by nature be a priority, or not be
at all. Finite resources, in my opinion, should be used for the most achievable maximum value. Just advertising a
feature isn't enough. Something needs to drive those users of the feature to that feature for the maximum level of user
support once they start to use the product. The same is true for C/C++, PHP, Python, etc. Simply, someone wanting a
Groovy project, isn't going to first think, oh I know, I should create a Java project first and that will give me Groovy
support. I think someone who uses Groovy knows about Grails, and just having a top level Grails project will make them
think the same thing as happens now when they get to the Groovy category...only Grails is supported.

Again on priority. One creates a feature, says it is there, users can't find it, they don't use it, and the priority is
logically going to be lowered as a direct result, and the end result is a feature has less of a chance to be as
successful as it may otherwise; wasted time and resources if it must be abandoned. Where as if the feature is more
accessible, and if there are enough Groovy users, then the priority is going to be raised as direct result. So, the
nature of the pathway in which new users, which may very well be many users of Groovy for the new and advertised Groovy
support, to get to and access that support or be able to see that it is there and available for their needs, can very
well be directly related to and affect the priority, and the decisions in usability and accessibility can be a self
fulfilling prophesy depending on the direction taken.

True, there can be something said for clutter. However, if someone doesn't want that clutter they can turn off the
modules. For instance, when I install PHP, C/C++, Python, what ever, then that fact alone dictates my intentions to use
it at some point, and to see those options provided by that support, clutter if you will. Now, if I have no intentions
of using them, and don't want to see them, I can either disable them, or uninstall them. Either way, if I intend on
using the features I expect to be able to use them, see them, and not have to think about what I'm using as it relates
to the simple things. 

Same as with a PHP user, they would expect to see a PHP project type, and the same could be said of someone looking to
do the same with something like Groovy. The fact that a Groovy project link creates a Java project is superficial if
someone knows, through the project template description, why this is the case, and knows they can work with Groovy files
once the project is created. It is the getting there that counts, and if that means they have to read the help file, or
some tutorial to use the feature in the IDE, then the UI has failed to perform as best as it can.

I completely agree that we should have different project type for Groovy. Unfortunately there will be not enough time to do it for 7.2 but I'll definitely try to implement this for the next version.

I'm marking the issue as a duplicate since it's more an enhancement than a defect.

*** This bug has been marked as a duplicate of bug 187681 ***