Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

This page documents the current plan for reorganizing the Groovy code-base based on the
discussions and initial decisions from Groovy devcon3.

Introduction

We are going to reorganize the sources and tests to separate:

  • Regression tests from 1.0 from new tests, or from TCK related tests
  • Language-related classes, from library-related ones

This also means we should separate more cleanly:

  • The core language classes
  • The library classes
  • The module content

Core languages classes are everything related to the core concepts of the language as well as the GDK. Library classes contain classes related to various APIs like JMX, Swing, and such. While module content usually require additional dependencies than the ones of the JDK and also usually follow their own release cycle.

Separating sources also means creating different artifact deliverables:

  • groovy-core (incluging "jarjar-ed" ASM and Antlr)
  • groovy-gdk

Having a small groovy-core library is particularly interesting for those wishing to integrate Groovy in their Java applications.

Regarding the tests, we should separate the 1.0 tests in a dedicated folder, while creating new folders for including "Groovy in Action" tests, new tests for 1.1 (with tests specific to Java 1.5 features), as well as tests for the TCK of JSR-241.

Current Plan

Step 1

Replace the current Maven 1 build with an Ant build.

Step 2

  • split src/main into src/core and src/bundled (for bundled modules?)
  • split main.pom into core.pom, bundled.pom and external.pom (or thirdparty.pom?)
  • use a naming convention for any tests that require a third party library that we don't intend to include in the complete install

E.g. for now, assuming AntBuilder lives in bundled (not core) we could split the current AntTest in two, e.g. AntBuilderTest and AntBuilderExternalLibsTest. Any dependencies for AntBuilderTest must have compile or runtime scope in bundled.pom. The functionality represented in AntBuilderTest is what we advertise as "runs out of the box - for a full install". Anything in AntBuilderExternalLibsTest would also use jars in the external.pom file. We can then create a page like the ant optional task library dependencies page but I suggest we use pom format rather than listing jars individually.

So, going back to the AntBuilder example, the main functionality for AntBuilder would be covered in the AntBuilderTest which might require dependencies such as ant.jar and ant-launcher.jar. If we wanted ant junit task to also work out of the box we would have a test for it in AntBuilderTest and include ant-junit.jar as another of our dependencies. If not, we could still have a test for it in AntBuilderExternalLibsTest and it would get mentioned in external.pom. Ant tasks are probably not a good example here but as another example, any SqlTests which rely on a real database would be in SqlXxxExternalLibsTest. Unit tests or system/integration tests that only rely on JDBC core libraries would be part of either core or bundled poms.

  • No labels