Skip to end of metadata
Go to start of metadata

How can contribute?

We always welcome patches and bug reports. If you don't want to dig into the code, we can always use more testers. Regular patchers may be given full dev access.

Design Decisions

This is to help contributors understand why we made some of the choices we made when designing GMavenPlus.

Why Reflection to access Groovy tools?

Interfaces and OSGI modules would be preferable to decouple the plugin from particular Groovy versions, but at the moment the effort to modularize Groovy is incomplete and no interfaces exist for the tools. Rather than try to isolate the dependencies to create a tools module, it was simpler to just use reflection for now. This does have the disadvantage of code that's a bit harder to read, and perhaps a greater chance of runtime errors. Perhaps at some point in the future, we can use OSGI instead.

Why was this written for JDK 1.5?

This plugin focuses on supporting newer versions of Groovy, and since Groovy 1.7, JDK 1.5 or greater is required. At some point in the future, JDK 1.4 may be supported.

Why use the project's Groovy?

We chose not to implement a system like GMaven's providers or Groovy-Eclipse's compilers to keep the system simpler, avoid possible issues between the version the code was compiled with and the version used at runtime, to avoid the need for a new release every time a new version of Groovy comes out, and because I'm hoping it'll cause less confusion than the providers mechanism.

Why the name?

Because I'm terrible at coming up with names :) Part of it was that I wanted a name that tied into it's history and this was one of the first things that came to mind. I had some other ideas later, but I'd already mentioned this project under that name in a few places and wanted to maximize traffic to the project, so I just stuck with it.

  • No labels