> Martin Fowler has written up a paper on the build process we use for my > current project, if anyone's interested. There's not much in there about > Ant specifically, but it does describe some of the benefits of having an > automated build:
> http://www.martinfowler.com/articles/continuousIntegration.html Apologies for cross-posting but I thought this article would be useful on ant-user as well. Also apologies for the length of this email. I'm hoping this contains useful information to others and that it shouldn't be a private discussion. I'm interested in knowing some more detail in a prioritised order: - The Master Build - BVT - Single Source Point ---------------------------------------------------------------------- The Master Build: Writing an automated build process is not my core business. Are you willing to share this code? Can we get it included into the Jakarta project in some shape or form? It would probably sit on top of Ant. BVT: How do tests get added to the BVT. Is it simply a matter of editing the main BVT entry point and adding the extra junit tests? I'd also be interested in how you run your tests in a J2EE environment. How do you unit test when it depends upon the J2EE environment? Do you write test session beans in order to provide an entry point into the system? I've not given this enough thought yet but this seems a reasonable way to go. A greater discussion of how the tests interact with the build would be useful. The problems with testing in a J2EE environment has slowed down the introduction of automated testing and this is causing me concern as I would like being used. Single Source Point: I would like to know how the build scripts handle building multiple components from a single source tree. I've had projects which contained all the source but found it difficult to label individual applications built from the components. I guess that at worst I am labelling source which is not used by the application. I've also had projects which have a separate directory per component. The problem with this approach is that you get lots of tiny jar files which need to be included when building a component that is dependent on them. But it does mean that I can label only the components that are necessary in the building of the application. If I have a single source tree I have to recompile everything, with a per component approach I only need the latest jar for the component. I disagree with the comment "The trouble with this [per project approach] is then people have to remember which versions of which components work with which versions of other components" as the latest versions of each component should work with the each other. So there is no need to remember anything, if you need to recreate a previous version then all your components are labelled with the information needed to obtain the versions of the components that work together correctly. Multiple projects makes editing files more tedious since you need to change directory structures in order to open files in different projects. I'm not sure how IDE's handle this but with emacs and a tag file I can open the correct file and not be concerned about its location. I'd be interested in adding to the following list of pros and cons. So far I've been happier with the multiple project line of thinking and require some convincing. ====================================================================== Single Source: Pros Simple build process, ie javac *.java Easy to find source since its located as <srcdir>/<package>/<hierarchy>/<to>/<java file> Single Source: Cons Difficulty in separating out the class files into different applications built from source. Difficult to build only source needed for an application without building everything. Multiple Projects: Pros Each component has a smaller number of files to compile. This may speed build process, but it a once off penalty that is being saved. Its obvious and explicit which components an application depends upon from the build process. Re-basing a component does not require re-compilation of dependent component source as you just need the latest version of the component's jar. Each application can be labelled individually with the components that it depends upon. (Note: Labelling components individually requires the inter-component dependencies to be tracked. This overhead provides little benefit since the latest versions should inter-operate correctly and once stable the application plus its components are labelled together. It is irrelevant what versions of the components may be useful together as they do not form a usable whole) Multiple Projects: Cons Many "tiny" jar files which must be included in order to build a component. Many "tiny" jar files should be joined into a single jar for deployment. Currently done via tedious unjar/jar. Finding and editing source from different components may be an issue depending on whether your IDE can support the multiple directory structure. Changes in code that break existing interfaces can cause a massive ripple in the component interaction which requires re-jarring and version controlling multiple components. Compared to a single recompile/jar for a single source. ====================================================================== regards, Barrie -- Barrie Treloar ____________________________________________________________________ Barrie Treloar Phone: +61 8 8303 3300 Senior Analyst/Programmer Fax: +61 8 8303 4403 Electronic Commerce Division Email: [EMAIL PROTECTED] Camtech (SA) Pty Ltd http://www.camtech.com.au --- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. --- ____________________________________________________________________
