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

« Previous Version 2 Next »

I think the biggest challenge for our build system is how to implement multiproject builds. It is likely that most of users will do multiproject builds.


  • Gant enables DRY for multiproject builds. This is were Ant has massively failed so far.
  • Gant offers an intuitive way to write a multiproject build.
  • Gant offers out of the box functionality for standard Java build tasks, which will grow from release to release.
  • Gant offers maximum flexibility for customization. This is were Maven has massively failed.

Directory structure for multiproject builds

I think it is good to be very flexible regarding the possible directory structures. For Steven's use case it was good enough to assume that all projects are toplevel folders of the root folder. But there are many situations were this structure is not expressive enough and therefore should not be imposed.

In my last project we had a structure like:

  • shared
  • client
  • ...
  • services
    • services-shared
    • service1
    • ...
    • serviceN

And I'm sure there are much more complicated project structures out there which can't be changed or people don't want to change them. I propose to have only one assumption. There is a root folder were we (might) have a top level buildfile and all projects folder must be contained somewhere in this root folder.

Determining the projects to be build

Even if I do not consider pathological cases, automatically determining the projects to be build is not easy or at least not cheap. The rule would be that everything is a project which contains a buildfile. If we look at the projects layout described in the section above (nested projects), we would have to scan many, many folders to look for the buildfiles (e.g. src/main/java/org/codehaus/.....). We could try to be smart and have the policy not to look in folders with name src. But the name src is just a convention and could be changed by the user. We could read the configuration of a found project first and then continue our search. But there might be some folder in a project with many files and subfolder which just sits there (e.g. not in use any longer but people don't want to delete it). For every build that is triggered we would have to scan this folder to look for buildfiles. I think an easy way out of this problem is that people have to declare the projects to be build in a top level build file. This has also the advantage to have a static file containing the projects layout.

  • No labels