Women in Technology

Article:		An Ant Modular Build Environment for Enterprise Applications
Subject:		Sharing modules
Date:		2005-09-16 01:13:02
From:		IgorSemenko
After reading this (great) article, I still have a couple of concerns: 1. Do you have an idea how to share 'modules' between applications? Say, you'll have 'util' package which you would like to share between different applications. 2. How to manage build.xml files themselves and avoid copy-pasting. For example if you have an application consisting from 50 modules, each has own build.xml. Now you want to introduce a style or coverage check. This will require changing 51 build.xml files or so. Thanks.

Showing messages 1 through 1 of 1.

• Sharing modules
  2005-09-16 06:04:45  LesHazlewood [View]
  
  
  Hi Igor,
  
  Thanks for the compliment. Let me try to address your questions:
  
  1. If I have classes across multiple applications, I typically create a separate project called
  <company name>-framework, with its own RCS repository. It contains utility classes, design pattern implementions, etc. that can be used across any application.
  
  All this 'framework' project does is produce a <company name>-framework.jar file that I treat like any other 3rd party library (like commons-logging.jar or hibernate.jar, etc).
  
  By including this jar in your application's lib directory (as described in the article) you treat it as a 3rd party library, only upgrading that jar when you need new functionality. This allows applications to keep their own copy and prevents dependencies on other apps.
  
  2. Your number 2 point is exactly why I created a hierarchical build in the first place. If you define a task in any parent build file, it is immediately available to the children build files because they <import> the parent definitions. So if I declare an ant task:
  

  <target name="styleCheck"> ... 

  
  in the root build.xml file, all modules and submodules may now use that task and can depend on it.
  
  I've worked on projects with over 50 submodules before, and this technique is just what saved us from rewriting tasks over and over again. Just define it once at a parent level, and its immediately available to any of its children.
  
  Regards,
  
  Les