Team development process
Even if each member of the team is allowed to choose an IDE or editor, even an operating system, you still need to set up a baseline for each platform. In particular, JDK and JAR files need to be fully synchronized. Ideally is to select the latest stable available Java / JDK version for all developers and target systems and use it for a while.
Consider sending a person responsible for controlling all the tools for all uses - especially the open source software tools have a new version built every night. This tool is only updated every month, or when the official version is released.
Another good strategy is to use a unified directory tree, add new additional tools in that tree. All reference can be related to this tree. If the team member wants to add a project to their path to their path, then you can include a command line tool in the path - including those that are called those Ant Exec tasks. Place each thing under the Code Control Tool, then you can get one-stop service to build / run the environment from the CVS or similar tool.
Distribute using Ant (deploy)
Ant and previous tools such as Make have a big difference, which is reasonable to distribute Java to remote sites that is reasonably integrated into Ant. In the past, we had to come to do these things, and many people have made great efforts to make this task easier.
Ant can be distributed through JAR / TAR / ZIP package files, and use the WAR task based on JAR to make servlet distribution. JLINK is a JAR generating tool that allows you to merge multiple sub-files. The JLINK is an ideal construction process when a separate JAR file is generated by each sub-project. CAB can be used to build a CAB file in the Win32 platform. This is useful if you have to distribute it for IE.
The FTP task allows you to upload the material to the server. Be careful to put your FTP password in the build file - there is strict access to control better. If you need to determine if the file has a UNIX extension before the file is uploaded, the FixCRLF task is a very useful transition step at this time. The WebDAV mission capable of providing safer upload files to the web server has been discussed for a long time, but it is still waiting for implementation in the list of information to be implemented. Interesting is that there is this task in the Jakarta activity library. All MacOS X, Linux and Windows XP are all supported by WebDAV file systems, and you can even use
EJB tasks can distribute EJBs, and the
Finally, of course, there is also a rollback task when using Copy and CopyDir copy files to the target location, or just send to the user or process using Mail or additional MIMEMAIL. In a project, our team uses Ant to build a CD image with Ant through a construct file of a long string COPY task, and actually works very well. The remote terminal web browser downloads it, where we also run through the Winnt remote desktop connection, and then transfer more easily through SSH channels.
Directory Structure
How do you organize your extremely dependent engineering directory? As a beginning, there are some model layouts of directory layout. All Jakarta projects follow a probably similar style, which is easy to transfer from one project to another, and it is easy to clean.
Simple engineering
This project contains subdirectory:
bin
Basic library
build
Tree; created by Ant and can be cleared in the Clean task
Dist
Distribute the output here; ANT creates Clean clear
DOC
Manual document
Lib
Guide the Java library to this
SRC
The original file is placed in the hierarchical tree according to the frame structure of the matching package; the rule of Java can require this directory.
BIN, LIB and SRC directory should be under source control. Other files - INF files, images, etc. In another content directory of distribution jar, these files can also be placed under the source folder, web.xml and similar manifest files (manifest) placed in metadata ( Metadata) Directory, Web Content - JSP, HTML, images, etc. are placed on the web directory. Place these content in a directory (or in the subdirectory), which will make it easier before the distribution before the distribution. Actually generates a distribution package - such as a WAR file - can be resolved by the appropriate Ant task: Do not need to create your source file directory tree according to the distribution level.
Javadoc output can be directed to the DOC / folder of the Build /, or to Doc / Javadoc.
Interface and implementation
If the interface and implementation of code are separated, it can make minor changes, establish a separate path, store the interface file - or better, build as JAR: A JAR as an interface, one as an implementation.
Loosely coupled subproject
Multiple projects have their own directory trees, source code access rights. The only exception is bin and the lib directory across all items. Sometimes this is very good - this helps keep all copies of Xerces.jar synchronization, but sometimes it is very bad - it updates the function JAR file before the unit test is completed.
In order to maintain a single construction across all sub-items, use the build.xml file that can be adjusted to the parent directory of the subject.
If different teams have different access / submission rights, this style is working very well. The risk is due to the more returning rooms, which may eventually lead to incompatible source files, libraries and build processes, and add your workload, and integrated pain.
The only way to keep control a clear loosely coupled item set is to maintain a complete test process for automatically build and recommend all code compatibility. Sam Ruby is running such a process to detect all Apache Java libraries and notify everyone, when some things happen; your own project is bitter to use Cruise Control to automatically, continuous and background running build processes.
Tight subproject
Tight projects put all the sources in the same tree; different projects have different subdites. Build files can be moved to these subdirectories (SRC / COM / ISERAN / CORE and SRC / COM / ISERAN / EXTRAS), or put it in the top directory - named using separate build files Core.xml And extras.xml.
If everyone trusts each other, and the child project is not a huge complicated, this project style works well. Risk is that the segmentation project will become a must-be in front of the project - but the project segmentation is not possible to make the project segmentation in the pre-project pressure and entangled build files. If this is the case, then keep it until time to reconstruct the project directory structure.
ANT update strategy
Once you start using Ant, you have to make a policy for your team and how to update the code update. A simple strategy is "Any official version of heavy pressures will push all the unimported tasks (like a daylight like sleeping). This allows you to be unstable unstable unstable, but the main disadvantage is that it is the task and characteristics of you are addointed with Ant.
One update behavior often needs to modify build.xml. Most modifications are triggered backwards, but sometimes incompatible changes are necessary. This is why you need a calm update after the release of the big milestone release. This is also why the Ant.jar and related files in the CVS tree can help determine if the old version of your software is still being built.
The most offense strategy is to get a snapshot of Ant source files every week, build it, use it. This forces you to more regularly adjust build.xml to make new tasks and property stable work. Otherwise, you really have to want new features, enjoy free extra work, or add trouble to your colleagues. Once you use new tasks to extend Ant, normal builds may suddenly become easier to fail. The latest Ant build is still the best choice for writing extensions, because you can use the basic class to improve the order improvement. This can also prevent you from waste time on those that have been completed. One piece of complex things, such as connecting the EJB engine, SOAP server or just a new submitted task that is translated to capitalization to capital, maybe you need to do - so, grab it, improve it, and contribute this It is raised to other people in the world. This is certainly more than you start your "text-size write conversion" task in Ant 0.8, six months, announced its existence and discovery that you have achieved very helpful. Good. The final benefit of this process is that it will increase your task to the Ant CVS tree, and when Ant accepts all you need to make your project work, it has been in advance. If this happens, you can turn to an official version of an AT and spend all the difficulties.
You should also progress to develop mail lists, as this is where other developers can submit their work, difficulties and experience. Capacity can be high: more than 40 messages per day, so consider sending them to an email address you don't often use. And do not let anyone in the team registered, otherwise it may be very distracted.
Put all together
What is the ANT build process? To simplify us assume a single directory structure, build a file should contain many top goals:
l Build - (increment) construction
l test - run the JUnit test
l Clean - Clear Output Directory
l Deploy - Load JAR, WAR, and any executable system
l Publish - Output source or binary flow to any distribution directory
l fetch - get the latest source file from the CVS tree
l DOCS / JAVADOCS - Documentation
l All - Clean, Fetch, Build, Test, DOCS, Deploy
l main - Default building process (often build or build & test)
Sub-project 'Web', 'bean-1', 'bean-2' can be given their own build files --Web.xml, bean-1.xml, bean-2.xml - use the same entry point. Other top targets related to databases, website images, etc., can also be considered if they are part of the process.
The Debug / Release switch can be called before the compilation task is called, and the relevant properties are defined, separate initialization target controls. Ant call is here a scam because it allows you to have two attribute initialization paths.
The internal target should be used when constructing:
l init - initialization properties, additional tasks, read into the properties files for each user
l INIT-RELEASE - Initialization Release property
l Compile - actual compilation
l Link / Jar - Making jar files or similar things
l Staging - Pre-release processes before being released to the production site and test
Debug / Release conversions can be resolved by setting the state of the init-release property, such as Release.Build is set: -
Then your independent goals, such as "compile", relying on this state's goal; have default properties being set, then this property is used. Because the ANT property is constant, if the Release target is running, its setting will overwrite the default value:
Debug = "True" Debuglevel = "$ {build.debuglevel}" INCLUDEANTRUNTIME = "false" SRCDIR = "SRC"> As a result, we now have a build file, and the Release mode can only contain file names and row debugging information (using the bug report), and the development system also contains variable information. The item name attribute that can be repeated in the initialization task is useful. This allows you to distinguish that Ant file is corrupted from multiple build files. What to participate in internal Ant tasks To see your own project. A very important strategy is "Redefine by Reference Reserved" - You can reuse it by a ID of the path, then use 'refike' attributes to reference them. You only need to define a shared path in the file, and the file set can also be reused in a similar method. Once you set the path structure and define the Ant task, you should start coding. The goal with the earlier priority must be set in the automatic test process, because it not only helps ensure that the code is working, but also verifies the construction process work. All right. Building a file is not like a newly added source file, only when you want to rename the release or part of the build process. In some point you may arbitrarily want to re-construct the entire build process, reconstruct the project, etc., but your build file should be used as the basis for the split build process - only dragging the shared attribute to a build file to read In the property file, keep the target name unified and project coordination work. Re-constructing source code control systems are often more difficult. Conclude
