I'm not sure if we should do this. For example JSP you have mentioned works in the same way (you can create them only in Web Pages and not in the Sources packages, even if you explicitly choose them in context menu)..

Although we might think about allowing both locations Web Pages and Sources Pages for groovy scripts.. if this would be good enough for you..

After the fix for issue 225728, I understand your point. I didn't know about groovlets, so I didn't see real use case for having groovy files under the Web Pages node.
I'll improve wizard for that purpose. Just one question, should this be possible only for Groovy Scripts or is it desired to have the same also for Groovy classes?

Well, I'm not too sure how much of a distinction NetBeans is making between Groovy Scripts and Groovy Classes at this point, anway. Groovlets usually do not contain a class definition, but I don't see anything preventing the programmer from putting a full fledged class definition into something that was created as a Groovy Script. If the distinction is to make sense, then I'd be creating Groovy Classes for compiled code (and that should have a source package assigned) and Groovy Scripts for dynamic code. As such it would suffice to enable this for Groovy Scripts.

Thanks for following this up so quickly. I've been using NetBeans for ages but I'm pretty new to Groovy. I really don't want to be pushed toward Eclipse, just because it receives some official SpringSource support.

(In reply to comment #3)
> Well, I'm not too sure how much of a distinction NetBeans is making between
> Groovy Scripts and Groovy Classes at this point, anway. Groovlets usually do
> not contain a class definition, but I don't see anything preventing the
> programmer from putting a full fledged class definition into something that was
> created as a Groovy Script. If the distinction is to make sense, then I'd be
> creating Groovy Classes for compiled code (and that should have a source
> package assigned) and Groovy Scripts for dynamic code. As such it would suffice
> to enable this for Groovy Scripts.

Mm, I've been playing with it a little bit and it seems to be quite hard to make the wizard logic correct. For example if one is creating Groovy script it should be possible to add it to the both Source packages and Web pages BUT unlike the Source Packages, in Web Pages we doesn't need package validation, we don't need default package option etc. ..on the other hand if we would make the UI identical with the one for JSPs, it would not be possible to create Groovy script in Source Packages (or it would look weird) which is wrong as well..

So easiest solution seems to me that we should rather create a new wizard type called "Groovlets" (enabled only in Web projects) which would look exactly like JSP wizard and put everything only to Web Pages. And thus Groovy scripts/classes would stay the same.

What do you think?

> Thanks for following this up so quickly. I've been using NetBeans for ages but
> I'm pretty new to Groovy. I really don't want to be pushed toward Eclipse, just
> because it receives some official SpringSource support.

Great to hear! Your anticipation is really appreciated.. we are still long way before we could consider our groovy support as the really good one, but without users involved in the planning/testing/reporting we hardly can move to the right direction. Always nice to hear that anyone is interested in and trying to help.

(In reply to comment #4)
> So easiest solution seems to me that we should rather create a new wizard type
> called "Groovlets" (enabled only in Web projects) which would look exactly like
> JSP wizard and put everything only to Web Pages. And thus Groovy
> scripts/classes would stay the same.
> 
> What do you think?
> 
Well, not knowing what behavior others are expecting from Groovy Script, that'd be the safe route. It also comes with the added opportunity to have a different template for a Groovelet. So yes, adding "Groovlet" in analogy to JSP should be the way to do this.

It would be extra sweet of course, if the wizard could add the following entries to web.xml unless they are already there:

    <servlet>
        <servlet-name>GroovyServlet</servlet-name>
        <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>GroovyServlet</servlet-name>
        <url-pattern>*.groovy</url-pattern>
    </servlet-mapping>

Groovlets are fantastic for some quick AJAX backend programming. With NetBeans new found strength in HTML5 and Groovy support inching towards even par, we'd end up with a convincing combination. Any chance to get this in for 7.3 offical release?

Great, sounds we have an agreement :) ..of course, web.xml update is possible.
Based on the latest comments, changing the issue type back to enhancement.

(In reply to comment #5)
> Groovlets are fantastic for some quick AJAX backend programming. With NetBeans
> new found strength in HTML5 and Groovy support inching towards even par, we'd
> end up with a convincing combination. Any chance to get this in for 7.3 offical
> release?

Unfortunately no. We are way after the feature development phase and only few last high priority issues (if any) will be integrated to the NetBeans 7.3 branch. Nevertheless I can do this in early NetBeans 8.0 development and if you would be interested you could use our daily builds (of course they are not as stable as final releases, but on the other hand the feature set is better and actual:))

Hi Martin,

I'm excited to see this marked as "STARTED". Creating the web.xml entries for the Groovy Servlet is just the icing on the cake. Could you make that step optional, when you get around to it? Just a simple "Do you want the Groovy Servlet added to web.xml? YES or NO". Background: I've created a separate implementation of the Groovy Servlet, the GRESTServlet, that can be used instead of the standard Groovy Servlet and also relies on .groovy files in the WEB portion of the project as well.

Jochen