Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<p>This page documents the current plan for reorganizing the Groovy code-base based on the<br />
discussions and initial decisions from <a href="http://docs.codehaus.org/display/GroovyJSR/GDC+3+report">Groovy devcon3</a>.</p>

<h2>Introduction</h2>

<p>We are going to reorganize the sources and tests to separate:</p>

<ul>
	<li>Regression tests from 1.0 from new tests, or from TCK related tests</li>
	<li>Language-related classes, from library-related ones</li>
</ul>

<p>This also means we should separate more cleanly:</p>

<ul>
	<li>The core language classes</li>
	<li>The library classes</li>
	<li>The module content</li>
</ul>

<p>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.</p>

<p>Separating sources also means creating different artifact deliverables:</p>

<ul>
	<li>groovy-core (incluging &quot;jarjar-ed&quot; ASM and Antlr)</li>
	<li>groovy-gdk</li>
</ul>

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

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

<h2>Current Plan</h2>

<p>Replace the current Maven 1 build with an Ant build.</p>

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

<p>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 &quot;runs out of the box - for a full install&quot;. Anything in AntBuilderExternalLibsTest would also use jars in the external.pom file. We can then create a page like the ant optional task <a href="http://ant.apache.org/manual/install.html#librarydependencies">library dependencies page</a> but I suggest we use pom format rather than listing jars individually.</p>

<p>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.</p>