SAnt build system development

This page contains a list of ideas and requirements which will make SAnt usable outside of Hippo. Once a minimal set of requirements is agreed upon, SAnt will be modified to suit those requirements.

Table of contents

Introduction

SAnt is a prototype for a community-friendly build system. In its current state it is only usable by Hippo, but you can still download and install it.

It is possible to modify SAnt so it works for your environment but that is a lot of work. That's why it has to be rewritten with multiple teams in mind. This page is used to gather feedback and ideas so shortcomings of other build systems won't be in SAnt 2.0 (if possible).

Get involved

The prototype can be found in the public SVN repository at hippocms.org. SAnt, which includes Ant, the project domains, project types, etc., can be found at: http://svn.hippocms.org/repos/hippo/experimental/sant/trunk/. The classes for SAnt and for each of the project types can be found in subfolders of: http://svn.hippocms.org/repos/hippo/experimental/sant-classes/trunk/.

A discussion list has been set up. Send an email to sant-dev-subscribe@lists.hippo.nl. There is also an archive of the list.

Core goals

Requirements

Usability was a primary objective for SAnt. A usable build system must have the following properties:

• Fast to install and update: within five minutes.
• Non-intrusive: do not interfere with existing build system settings.
• Informative: tell what is available and what you can do.
• Be productive fast: when joining a team you can build their existing projects and you can create new modules specific to their environment immediatly.
• Shared build scripts: absolutely no build instructions in the project so projects of the same type build exactly the same.
• Open: users must be able to investigate, improve and extend the system.

Existing technologies

SAnt currently is an integration of existing technologies. This was a deliberate choice. It would have taken too much time to write one of the components from scratch.

Although some components are not optimal, the new version of SAnt will not try to solve all problems. The main reason is that Hippo needs an easier to use build system now. Replacing a component is still possible but there has to be a very compelling reason to do so.

Glossary

• Module
  • A module provides functionality to a project which is not tied to specific artifacts. Project types can reference modules instead of having to include the build script of a module completely. Examples: an Eclipse module capable of generating Eclipse project files.
• Project command
  • A project command allows a user to perform an operation on a project. It differs from Ant targets in that it does not apply to the whole project, but to an individual file/class/... Example: a command which will generate a test class based on the fully-qualified name of the class to test.
• Project domain
  • A project domain contains the settings specific for a team. This includes the locations of the artifact repositories to use, and the information about where the generated artifacts of a release should be uploaded too. By putting this information in a project domain and adding a reference to a project domain to project, users no longer have to change their settings when they switch from one project to another.
• Project template
  • A project template creates a project instance and prefills it with default values. Project templates will be independent of project types so you can have multiple templates per project types. Multiple templates are needed because, for example, the dependencies used by default by different teams for a project type might differ. Example templates: Hippo bare site, Hippo site with community apps.
• Project type
  • A project type contains the build scripts for projects. All projects having the same project type will be build the same way, and will benefit immediatly from improvements to the project types. Example project types: standard JAR file, JDO-enhanced JAR file, stand-alone application, WAR file, Cocoon block.
• Repository
  • A repository contains all the modules, project types and project domains of a team. By importing a repository in his workspace, a user can immediatly start development on exisiting and/or new projects of the team. A better term is desired to avoid confusion with artifact repositories.

Features

Multiple teams

Multiple repositories

A user does not work with a single team. So the tool must support adding multiple repositories to the the workspace of the user.

Importing repositories

A team might work with a product from another team. This other team probably defined project types specific for their product. Users should not have to import the graph of repositories manually. Instead the tool must support transitive repository importing.

For example: Hippo uses Cocoon a lot, so Cocoon will appear in the list of imported repositories in the repository of Hippo. If someone imports the Hippo repository he automatically gets the Cocoon repository too. He will also be able to use the project types, project templates, etc. for Hippo projects.

Namespaces

Each team must use a namespace it owns for its project domains, project types, project templates, etc. This prevents conflicts when a user imports multiple repositories in their workspace.

Components

Build script language

Although Ant is very powerful because a huge amount of tasks exist for it, it is also inflexible. Conditional statements and processing of collections happen regularly in a build and should be easy.

Scoping and writable properties (i.e. real variables) would really help too.

Ant is too big to completely rewrite, but a build script language that is able to use Ant tasks might be a good replacement for Ant scripts.

Dependency management

The dependency management is currently done by using Ivy but this is not a requirement. Johan Stuyts chose to use Ivy for the project types of Hippo. You are free to do dependency management differently.

Johan is very satisfied with the capabilities of Ivy.

Command scripts

The command scripts currently do too much work. Keeping them in sync between different platforms is too much of a hassle. They should be refactored to be as simple as possible by moving the functionality contained in them to Java.

TODO

Stuff that still needs to be worked out/categorized:

• version pinning. Be able to pin the SAnt and repositories used to a specific revision per project.
• A major problem people have with Maven right now is unreliable repositories and/or immuttable data (POMs for releases) that does change. SAnt uses Ivy and probably suffers from the same problem. Can this be solved?
• Overriding of resources in project types/modules by project domains.
• Make it easier (less boilerplate) to, and report errors (e.g. missing properties used by a module) when:
  • extend an existing project type;
  • including a module in a project type.
• Formalize the structure/layout of project types, modules, templates, etc.
• Templates must be separated from project types, so teams can have different templates for the same project type.
• Prevent checking in of references to development versions.
• Prevent checking in of references to non-existing (read: not released yet) versions.