Skip to end of metadata
Go to start of metadata

New documentation (in progress)
The new Groovy documentation is an ongoing effort to create new up-to-date documentation of Groovy core and its module, as a self-tested executable document, built using the Asciidoctor library.

Getting Started with Groovy
Installation and quickstart instructions, tutorials, feature overview.

Using Groovy
Bean scripting, compile-time metaprogramming, AST transformations, dynamic features, IDE support, XML processing, GUI programming, Ant integration, more.

Cookbook Examples
Practical examples that focus on common applications and tasks.

Advanced Usage
Design patterns, polyglot programming, Ant troubleshooting, security, compiling, refactoring, more.

Testing with Groovy
Groovy mocks, model-based testing, unit testing, testing Web applications and Web services, integration with other frameworks, test coverage, more.

Developing with Groovy
Building Groovy from source, setting up the environment, continuous integration, release process, more.

  • No labels


  1. I was wondering if this would be better served as a few pages, rather than one "index" of pages. If it were broken up into logical pieces, it'd be alot easier to search or browse through. It might require not using the 'children' macro in the wiki pages, unless each logical section becomes its own page, then you could use it again.

    I'd be willing to work on reorganizing this if you guys think it'd be a good idea. (smile)

  2. I guess reorganisation would be an option. I believe Confluence now honours ordering of pages, so there are probably a lot of places we could start using that capability.

    A couple of things to realise though is that other places within the wiki might be relying on a particular pages structure, e.g. things like the children macros might be used in higher up pages with different depth settings. Also, we need to make sure that whatever we do still turns out ok when you do the PDF generation. Sometimes the structure is a compromise between what works well on the web site and what works well for the PDF. But don't let those things hold you back - it might just involve some extra testing initially.

  3. Well, I probably wouldn't want to tear up this page, in light of what you said. This page serves as a good "table of contents" to the site, and if you're looking for something specific, it serves that purpose very well. My main "concern" is that it's somewhat intimidating since there's so much information presented.

    Just as some examples, see:

    Java's documentation page is the most cluttered, but it does break its doc's down into use-cases, rather than simply categorizing the content. Groovy's doc's do have separate sections for different kinds of users (the new user, the "I'm looking for more info on X" user, the advanced user, etc.), but I think the page could do a better job of stating the intent of these sections, like Java's doc page does.

    Ruby's page is the most user-friendly, in that it's easily approachable and well-formatted. It doesn't really offer too much as an example beyond that, though. (Plus, it's not really clear why there's four different manuals, 8 different getting started guides, etc.)

    Python's doc is the most like Groovy's, but it doesn't separate content by its various uses: the Tutorial, Reference, and Python/C API all seem equally relevant, even though they would vary dramatically based on what kind of Python developer you are.

    It seems to me that the site should aid you in figuring out what to look at, where to browse. I mean, it's a wiki, but it's also the first-stop for any Groovy developer, so its unbiased display of information might not be the best route.

    Just my two cents: I kind of feel like I've gotten ahead of myself. (tongue)

  4. I don't know if it matters anymore, but the "Groovy JDK" link in the "Reference" section goes to an "Oops!" page.