Summary:
Java compiler environment for enterprise applications today, the more and more difficult to manage. A mountain of code, configuration files, and dependence on third parties (third-party dependencies) have made it difficult to manage the build environment. This article shows an example of an Ant build environment, and it comes from my experience over the years to modify multiple item. Here and now, it may not be the best solution, but it certainly has stood the test of time, it will certainly help you build and run on most projects, whether large or small.Copyright Disclaimer : can be reproduced, be sure to indicate the original source and author information and this statement is reproduced the form of hyperlinks
original English Address:
http://www.onjava.com/pub/a/onjava/2005/06/22 /modularant.html
Chinese address:
http://www.matrix.org.cn/resource/article/43/43716_Ant.html
keywords: Ant compile
build environment for enterprise Java applications today, the more difficult managed. A mountain of code, configuration files, and dependence on third parties (third-party dependencies) have made it difficult to manage the build environment.
In short, we reluctantly accept that all of the source code in a root directory, all the configuration files in the root directory to another, and third-party libraries also deal with such practices. Enterprise build environment but rarely do so. Today's enterprise Java projects, on the structure, function, and organization is very complex. They usually have a lot of source code, and support resources (property documents, pictures, etc. Editor's Note: Originally supporting artifacts, literally translated as support for objects, but here the context paraphrase support resources more properly) going to management. There are so many things to manage, when a team trying to build a compiler optimization scheme, they often feel confused and frustrated.
If, no matter how much this project, we are able to build environment is simple to handle all of our source code in a unified framework, things are not any better it will become? This article shows an example of an Ant build environment, and it comes from my experience over the years to modify multiple item. Here and now, it may not be the best solution, but it certainly has stood the test of time, it will certainly help you build and run on most projects, whether large or small.
Warning
to explain some issues, so you will not read this article only to find it you have no value:
* Based on the understanding of the Ant. It is for those who would like to use Ant and readers.
· Build environment here refers to the module (modular) and modules (module), and the module is again defined directories and subdirectories. (Translator's Note: the module is a collection of modular module which module is constituted by a plurality of independent modules.) This means that the file and the source code is stored in many different directories. So, if you use something like Eclipse or IntelliJ Idea IDE tools that can help you manage the class and location of the file, then this article will be more beneficial for you. Of course, you can also use a text editor, but I'm afraid you will find that you frequently climbing up and down on multiple trees "tree."
concept
First, let's talk about hiding out in a few core concepts after the build environment. They are modular, hierarchical structure (Hierarchical), and Resource Driver (artifact-driven). What about their exact meaning of what is it?
Module
Module compiled refers to a way of compiling organized around software modules. A module is a logical set of functional units, corresponding to a characteristic of the system. For the compiler environment, the performance of a module configuration file source code and a set of self-contained (self-contained collection), the source code used to build the profile and performance characteristics of the software that named modules correspond. It is almost your revision control system (RCS: Revision Control System) (such as CVS or Subversion) in the directory tree is one to one. A few examples: security, administration, wiki, email can be a module.
Hierarchy
level compiler to compile embodiment containing structure refers to a layered module. That is, for a module, it may be composed of smaller, more specific sub-module (submodule) is constituted.
If a module contains sub-module, then it has the responsibility to ensure that those sub-modules are compiled in an appropriate manner.
Then, we will discuss how to apply the concept of hierarchy is an example to establish the build environment.
Object driven
object is driven compilation means that each module (Module1) occurring or submodule (submodule), the object is to produce a single, deployable. In Java project, these objects are mainly .jar, .war, or .ear file. In other types of compilations, they are usually binary executable file or dynamic link library (.dll or .so).
Examples of the build environment is object-driven, we will discuss how it can be deployed to create objects.
Although these three concepts are easy to understand, but combined with the build environment, then they become very powerful.
Now let's look at how organizations build environment.
Module structure
when a lot of time to be fulfilled, the problem is decomposed into several smaller parts is a very effective method. We need a good divide and rule (divide-and-conquer) technology to help us to manage large amounts of source code. Create a module compiled in the build environment is a good way.
Let's create a module by creating a directory in the root directory of the application. This new directory becomes the basis for this module. In each module directory, we store documents and source code associated with it.
This is a sample program compiler environment, organized by module:
appname /
| - ADMIN /
| - Core /
| - db /
| - lib /
| - ordermgt /
| - Reports /
| - Web /
| - the build.xml
Here is what each node:
• in addition lib / outside of each directory is a module. In this example, admin module provides an implementation of POJO, it allows a person to manage the application (for example, creating a user, authorization, etc.). The same, Reports module, capable of producing components for realizing the report. The core modules are those components in many or all of the modules are used, they are not really a function of the system and linked. (E.g., type of StringUtil) Typically, all other modules will be dependent on the core (Core) module.
Other modules and admin, reports, and core modules: they have their own self-contained system functions, and with other modules to distinguish. In addition, because our sample application can support a web-based interaction, we can also have a web module that contains everything to create a .war file required.
· Lib / directory rather special. It contains all the files needed .jars third-party applications to compile or run. We all third-party .jars documents required by other modules in this directory, rather than their own modules. The following reasons:
1. In a more manageable place reliance on third parties (third-party dependencies). Build.xml file may be a module, with Ant the <path> change statements to define the module uses these libraries.
2. The possibility of duplicate files by excluding .jars, thereby avoiding loading the class version conflicts or API. If more than one module using Jakarta Commons Logging module is responsible for storing a commons-logging.jar file, what happens? Assuming that each module are in possession of a backup Jakarta Commons Logging module, so there will be a potential problem - a module to back up and held by another module held by some different versions. When the application is running, only the first one .jar files found on the classpath are loaded to meet the required, which can potentially cause a conflict with other modules. Let's avoid such conflicts by holding only one .jar file in the root directory.
3. dependence on third parties as you change the source code version. Browse a lot of projects, you will find that this is you want your library depends on the most important reasons CVS. By doing so, you can make sure that, whether you derive from the CVS is the version of the software or that branch, you can find a suitable version of the third-party libraries to support specific versions of your software.
· Root build.xml file is the main file management. It compiles each module to know what files and target (target: Translator's Note, should be <target>, is a statement in Ant) is a must. Then, by the module to ensure that these items (artifact) is properly compiled.
For example, suppose a project being compiled, it is time to compile ordermgt module, and compile the file root (root build file) should know to call ordermgt / build.xml file an Ant task to complete this compilation. The ordermgt / build.xml file should know exactly what to build generating ordermgt .jar file need. Moreover, if the project is compiled and merged into a .ear file, the root build.xml file should know how to build.
Root build.xml file is going to know how to compile a module and the order in which to compile it? The following is part of a Ant XML file, it shows how build.xml file is complete the set target:
<!-- =========================================
Template target. Never called explicitly,
only used to pass calls to underlying
children modules.
========================================= -->
<target name="template" depends="init">
<-- Define the modules and the order in which
they are executed for any given target.
This means _order matters_. Any
dependencies that are to be satisfied by
one module for another must be declared
in the order the dependencies occur. -->
<echo>Executing "${target}" \
target for the core module...</echo>
<ant target="${target}" dir="core"/>
<echo>Executing "${target}" \
target for the admin module...</echo>
<ant target="${target}" dir="admin"/>
...
</target>
Whether the root file called build.xml compile goal which, by the template target responsible for passing a certain order to the respective sub-modules. For example, if we want to clean up the whole project, we should simply call the clean target can be at the root of the project, then the following tasks will be executed:
<!-- =========================================
Clean all modules.
========================================= -->
<target name="clean" depends="init">
<echo>Cleaning all builds"</echo>
<antcall target="template">
<param name="target" value="clean"/>
</antcall>
</target>
Root file build.xml clean target to achieve the call by calling template goal indirectly, thus ensuring that all modules are cleanup.
The above organizations and relevant module compiler target is really the source and build management becomes easier. This structure helps you faster and easier to find the source you want. The target template to manage how tasks are performed.
But the most exciting part of the module structure is here:
After completing a full compilation of the whole project can be compiled independently of any module. Just switch on the command line to the next module directory and execute:
> Ant target
then build.xml file that module will be executed. You can run any target at any level compiled, but only to the level to be compiled.
Why is this important? Because it allows you to work independently in your module, and only the compiled module. In this way, every time you modify the source code of the modules you do not need to recompile the whole project, for a huge project, which will save a lot of time.
Now, let's look at how an independent internal module is constructed.
Content modules
we follow the normal Java industry's habit to organize the module directory structure to manage source code. Although there are many different habits, our compiler environments about directory structure:
modulename
| - Build /
| - etc /
| - src /
| - the Test /
| - the build.xml
below each node meaning:
· Build: This directory is special, it is a compilation of modules produced. In addition to it, other files and directories will be added to the above list revision control system (RCS: Revision Control System). build directory contains all the files generated during compilation, from auto-generated XML file to compile complete Java .class files, as well as any eventual release file (distribution artifacts) (such as .war, .jar, .ear, etc. Wait). This makes clean up the build becomes very easy, just delete the directory just fine.
· Etc: this directory is stored when compile or run (run time) modules required profile. Most of the time, you will find properties files and XML configuration file Here, for example log4j.properties or struts-config.xml. Suppose there are a lot of files, they are usually stored in subdirectories of their related components. For example: etc / spring /, etc / struts /, etc / ejb /, and the like.
· Src: This is your source tree root directory. Where in addition to the packet and (or) the directory corresponding to the path, it is nothing else a. So here you will often see com / or net / or org / directory, as com.whatever or net.something or org.mydomain packages start. Note that only one relationship and classpath have something to put this directory. For example: package directory, or .java source file.
· Test: This directory is used to store your test class file. (E.g., JUnit test unit). From the perspective of directory organization point of view, the important thing here is that the package structure here is strictly mirror src directory. This test program is very easy to manage, because you will know immediately: moduleroot / test / com / domain / pkg / BusinessObjectTest
Is a test to be moduleroot / src / com / domain / pkg / BusinessObject 's. This simple mirroring technology for managing large amounts of code is very useful. It enables you to easily find your test program.
· Build.xml: This file Ant knows how to do what needs to be done each piece of this module is to complete the compilation and distribution of items it is responsible. If the current module contains sub-module, it also knows how to compile and in what order to compile those sub-modules. Sub-modules and compile order are we will soon be explained, very important concept.
Sub-module
sub-module is another module (parent module) subset. You may have seen other models - based on a flat hierarchy Ant: for example, only one layer deep structure. Our compiled structure to go farther: We have 2 layers.
Continuing our concept compile and sub-modules, you will see the following compilation of a level, modules and sub-modules expand the following directory:
module1 /
submodule1.1 /
| - etc /
| - src /
...
| - Build .xml
submodule1.2 /
| - etc /
| - src /
...
| - the build.xml
the build.xml
Module2 /
...
the OK, this looks a bit complicated. Why do we need this?
Let us add point enterprise applications and object-driven background knowledge to answer the question again.
Enterprise-level applications in most cases are based on the client / server model. Even if you just develop a web application, it usually constitutes a client / server application MVC. In this way, the page itself is a customer perspective, and the "server" side components are usually business POJO, it released instead of page components to perform business logic. Although they .war a file, but the main view for drawing (rendering a view) (client code) code and architecture for a clear separation between the business processing request codes (server code). At least, here is this!
In traditional client / server applications, the concept of client and server more apparent. There are separate GUI client to communicate through the socket and server-side business objects.
For if the client application we only need to change the client code, server-side program only changes to server source code, it would be simple and elegant. This two also share some common code, common to send to the client and server side .jar file is also a good idea. Our build environment has the ability to realize our ideas.
Next we will see how the sub-module help me drive us to achieve the object compiled.
Object hierarchy and compiler
deployment scenarios (deployment scenario) only describes the object-driven compilation of skin needs: build environment for each module or sub-module complex will be deployed to create a client or server-side objects. In our build environment that is easy to implement, as long as the existing module is further broken down into common, client, and server sub-modules just fine. Parent-child relationship and the responsibilities entrusted to compile the compiler also contributed to this hierarchy.
With our sample program in the admin module, for example, let us look at the expanded tree in this hierarchy is like:
appname /
| - admin /
| - the Common /
| - etc /
| - src /
| - the Test /
| - the build.xml
| - Client /
| - etc /
| - src /
| - the Test /
| - Build .xml
| - Server /
| - etc /
| - src /
| - the Test /
| - the build.xml
the build.xml - |
...
construct as defined previously content of each sub-module are in accordance with, but some noteworthy that different:
ADMIN module without those usual module. It only contains sub-module and a build.xml file, but it does not produce any compilation own product. But by the previously described template (template) technology to call common / build.xml, server / build.xml, and compile target client / build.xml file to compile the work.
So, if you want to compile admin module, you only need to switch to the admin directory, then run Ant:
> cd admin /
> Ant
This command will call build.xml file admin, and the results are compiled common, server, and client module. After each sub-module is compiled, will produce three items:
APPNAME-ADMIN-common.jar are
APPNAME-ADMIN-server.jar
APPNAME-ADMIN-client.jar
Common server .jars and files to the server may be deployed (e.g. in a .ear file), and the common and client .jars files may be deployed to the client (e.g., .war file WEB-INF / lib directory).
What is the purpose of each sub-module is it? They help to subsets of neat features to organize the code, these sub-assemblies are deployed on different aspects of the application. What is the content of the three sub-modules typically containing:
· the Common: module, all the client and server code layer will be used. This usually means that the interface POJO, unit type, and the like.
· Server: the server level to achieve the desired class. They are usually commercialized POJO interfaces, DAO EIS for the realization of the connection, and so on.
· Client: the client layer to achieve the required class, such as Swing GUI objects, EJO remote interface, and so on.
This sub-module independence (granularity) and their corresponding deployment objects from four aspects to generate substantial help for you:
1. Download Time: You can ensure the independence of the client application, such as an applet or Java Web Start programs, only minimal subset need to download the program requires to run .jar file. This ensures that the applet or application is first run can be downloaded as soon as possible.
2. dependency management: build.xml file sub-module of the Ant <path> identification, you can add other modules or sub-modules of the current sub-module dependent. This avoids any or at runtime does not support the API lazy or accidental use of the developer is not supported
.
3. dependency order: Father module determines the order of sub-compiled modules, so you can re-set to make sure you write client code relies on common code without relying on server-side code. Similarly, common code can not rely on the server or client code. If you do not, the compiler will abort, and you'll immediately get a warning, you should not use the type you use. Under this sounds like a trivial problem, but have different experience in complex projects or those programmers case, the problem surfaced quickly, and will not be noticed in the dependency management.
4. Just as processing modules, and you can also run the following commands to switch to the directory's sub-module to compile a separate sub-modules:
> Ant
and Ant will only compile the module, saving time.
Conclusions
modules and sub-modules looks a bit complicated. At this point they seem to have this need, in your opinion. But please believe my experience, they greatly simplify how you manage source code and associated files, and how to compile Ant is your product. Here the definition of structure really makes the product features and source code management becomes easier in a team environment. It excludes many tasks To achieve the full organization of the imaginary, and once established, it is quite transparent. If you are starting a new project client / server model, and then try to apply it. You will have more time to devote to your program, rather than for the configuration and management but the heart.
Special thanks Transdyn delivers the Jeremy Haile, he provides meaningful information and for reviewing this article.
Reproduced in: https: //www.cnblogs.com/licheng/archive/2008/11/04/1326669.html