Java超级工具(英文影印版)(上下册)
点击看大图基本信息
- 原书名： Java Power Tools
- 原出版社： O'Reilly Media, Inc.
- 作者： John Ferguson Smart [作译者介绍]
- 丛书名： 开明出版社O'REILLY系列
- 出版社：开明出版社
- ISBN：9787802057319
- 上架时间：2009-5-26
- 出版日期：2009 年4月
- 开本：16开
- 页码：871
- 版次：1-1
- 所属分类：
计算机 > 软件与程序设计 > JAVA(J#) > Java
内容简介回到顶部↑
所有真正的工匠都需要用最好的工具来做他们最精细的活儿，程序员也不例外。.
《java超级工具》囊括了30个开源工具，专门用于提高任何规模的团队或者组织中java开发人员的实践水平。
每一章都包含针对一个特定工具的一系列短小精悍的小节——无论这个工具用于构建系统、版本控制或者开发流程中的其他方面——这样你就相当于在一个包装里得到了30本简短的书籍。
无论你选择哪一种开发方式——敏捷、rational统一过程（rup）、极限编程（xp）、scrum或者其他——本书中的实践技巧和工具都使得流程自动化和更优化。《java超级工具》探讨关键的java开发问题领域和最佳实践，并且专注于在开发周期的各个环节能够提高生产力的开源工具，包括：
· 构建工具，例如ant和maven 2
· 版本控制工具，例如cvs和subversion
· 质量度量工具，例如checkstyle、pmd、findbugs和 jupiter
· 用来生成良好文档同时降低写文档和维护文档耗时的工具..
· 单元测试工具，例如junit 4、testng以及开源测试覆盖工具cobertura
· 集成测试、负载测试和性能测试自动化；网络服务、swing接口和网络接口的自动化测试
· 问题管理工具，如bugzilla和trac
· 持续集成工具，例如continuum、cruisecontrol、luntbuild和hudson
提高开发实践水平并且让你在开发流程中的日子更容易些。《java超级工具》对于核心开发人员和软件架构师而言是必读书目，能让他们的职业生涯秩序井然。...
《java超级工具》囊括了30个开源工具，专门用于提高任何规模的团队或者组织中java开发人员的实践水平。
每一章都包含针对一个特定工具的一系列短小精悍的小节——无论这个工具用于构建系统、版本控制或者开发流程中的其他方面——这样你就相当于在一个包装里得到了30本简短的书籍。
无论你选择哪一种开发方式——敏捷、rational统一过程（rup）、极限编程（xp）、scrum或者其他——本书中的实践技巧和工具都使得流程自动化和更优化。《java超级工具》探讨关键的java开发问题领域和最佳实践，并且专注于在开发周期的各个环节能够提高生产力的开源工具，包括：
· 构建工具，例如ant和maven 2
· 版本控制工具，例如cvs和subversion
· 质量度量工具，例如checkstyle、pmd、findbugs和 jupiter
· 用来生成良好文档同时降低写文档和维护文档耗时的工具..
· 单元测试工具，例如junit 4、testng以及开源测试覆盖工具cobertura
· 集成测试、负载测试和性能测试自动化；网络服务、swing接口和网络接口的自动化测试
· 问题管理工具，如bugzilla和trac
· 持续集成工具，例如continuum、cruisecontrol、luntbuild和hudson
提高开发实践水平并且让你在开发流程中的日子更容易些。《java超级工具》对于核心开发人员和软件架构师而言是必读书目，能让他们的职业生涯秩序井然。...
作译者回到顶部↑
本书提供作译者介绍
John Ferguson Smart是Wakaleo咨询公司的首席咨询师 (www.wakaleo.com)，这是一家致力于为企业级Java和敏捷开发领域提供咨询、培训和指导服务的公司。...
.. << 查看详细
.. << 查看详细
目录回到顶部↑
foreword .
preface
introduction
part i. build tools
1. setting up a project using ant
1.1 ant in the build process
1.2 installing ant
1.3 a gentle introduction to ant
1.4 compiling your java code in ant
1.5 customizing your build script using properties
1.6 running unit tests in ant
1.7 generating documentation with javadoc
1.8 packaging your application
1.9 deploying your application
1.10 bootstrapping your build scripts
1.11 using maven dependencies in ant with the maven tasks
1.12 using ant in eclipse
1.13 using ant in netbeans
1.14 manipulating xml with xmltask
1.15 conclusion
preface
introduction
part i. build tools
1. setting up a project using ant
1.1 ant in the build process
1.2 installing ant
1.3 a gentle introduction to ant
1.4 compiling your java code in ant
1.5 customizing your build script using properties
1.6 running unit tests in ant
1.7 generating documentation with javadoc
1.8 packaging your application
1.9 deploying your application
1.10 bootstrapping your build scripts
1.11 using maven dependencies in ant with the maven tasks
1.12 using ant in eclipse
1.13 using ant in netbeans
1.14 manipulating xml with xmltask
1.15 conclusion
前言回到顶部↑
Here is Edward Bear coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. .
--"We are introduced to Winnie-the-Pooh and some bees, and the stories begin," Winnie the Pooh, A. A. Milne
Thus does A. A. Milne introduce that classic character of children's literature, Winnie the Pooh. As you can see, Winnie the Pooh seems to have some issues with the way he goes downstairs (we probably wouldn't be too far off if we were to speak of "pain points").
Software development sometimes feels like this. It is easy to get so bogged down in the details, under the pressure of tight deadlines and changing requirements, that you forget that there might just be a better way. A high number of bugs, a difficult integration process, long and painful builds, and poor project visibility become an accepted part of the developer's life.
The good news is that there are in fact many easy ways to improve your software development lifecycle.
A judicious use of tools can go a long way in boosting developer productivity. For example, many distributed development teams use nothing more sophisticated than a CVS or Subversion repository for storing application code and a mailing list for discussion. Imagine a system in which, whenever someone commits a change, issues are automatically closed or updated based on the commit comment. The issue management system then automatically notifies the issue owner of the change of status. Meanwhile, a dedicated build server detects the commit, builds and tests the system, and notifies the developer of any failures. In a few relatively simple steps, you've taken your development platform to a newlevel of reactivity and responsiveness.
This is just a first step. Soon you will be integrating automatically running unit and possibly integration tests, code coverage tools, style checking tools, and more to create a highly reactive, informative, finely tuned project infrastructure.
Tools are the key to making such an infrastructure work efficiently. Once you start to adopt a set of SDLC tools that suit your project and your organization, you will see a revolutionary shift in a groups development practices. Agile development authors such as Alistair Cockburn rightly point to optimal communication as being the cornerstone of productive development. Developing in a team without continuous integration is like rock climbing without a rope. In addition, developing in a team without collaboration and connective development infrastructure is like developing in a boring beige office space where everyone comes to work on time, enters a closed office, closes the door, and starts programming without ever stopping to have meetings. In other words, programming without a good set of SDLC tools is very much the equivalent of fighting a modern war with swords and armor--the adoption of SDLC tools is a generational shift, the programmers just coming into the workforce will never know an alternative, but the programmers who haven't experienced this shift are in danger of missing the trend altogether.
Now you shouldn't go thinking that SDLC tools are only for large teams or big organizations. They aren't. In fact, most SDLC tools are easy to setup, and almost all organizations can benefit, even a small outfit with only two or three developers.
Most of these tools and techniques are not particularly difficult to put into place, but they do require a minimum of effort, to step back and take a long, hard look at your current practices. Chances are, there are things that can be improved.
This book is part of the O'Reilly Power Tools series, which began with the illustrious Unix Power Tools back in 1993. It has no relation to the "Java Power Tools" library (http://www.ccs. neu.edu/jpt/), which is a software research project in the Java GUI field, conducted by College of Computer & Information Science at the Northeastern University, Boston, under the direction of Richard Rasala.
How This Book Is Organized
One of the most characteristic traits of the open source (http://opensource. org) Java world is choice. It seems that, for any given task, there are always at least two open source tools that can do the job. To reflect this, I have tried to give a representative survey of the available open source tools for each area of software development that we cover. The book does not try to "sell" any one tool, or even any one tool in each domain. On the contrary, we try to give readers enough information so that they can decide for themselves which tool is the most appropriate for their particular organization, and give enough practical information to get them up and running.
This book is organized into sections, with each section covering a particular aspect of the software development lifecycle (or SDLC). With each section, we look at a number of available tools that can be used to improve this aspect of the SDLC.
Build Tools
In the first section, we cover possibly the most fundamental tool of all (after the compiler and the IDE, that is): the build tool. Indeed, when used well, the build tool becomes the cornerstone of your SDLC process. It is this tool that coordinates, federates, and binds the other SDLC tools together into a single, coherent process. And the build tool helps to ensure that your project can be built on any machine, in any environment.
In the Java world, two tools dominate this area. The first is Ant, the traditional Java build tool, which uses a straightforward procedural approach and benefits from a very large user base and a rich set of extensions. The second is Maven 2, which uses a powerful, declarative approach to project build management and, as we will see, goes much further than being a simple build tool. We will look at each of them in some detail in this section.
Version Control Tools
The second section covers that other fundamental component of any software development infrastructure: a version control system not only provides critical backups of your source code, it also lets developers work together on the same project without getting in each other's way. Version control systems also allow you to identify versions and coordinate releases and (if necessary) rollbacks. Finally, as we will see in Part VIII, it is a cornerstone of any Continuous Integration environment.
In this section, we will look at the two most prominent open source version control tools on the market: CVS and Subversion.
--"We are introduced to Winnie-the-Pooh and some bees, and the stories begin," Winnie the Pooh, A. A. Milne
Thus does A. A. Milne introduce that classic character of children's literature, Winnie the Pooh. As you can see, Winnie the Pooh seems to have some issues with the way he goes downstairs (we probably wouldn't be too far off if we were to speak of "pain points").
Software development sometimes feels like this. It is easy to get so bogged down in the details, under the pressure of tight deadlines and changing requirements, that you forget that there might just be a better way. A high number of bugs, a difficult integration process, long and painful builds, and poor project visibility become an accepted part of the developer's life.
The good news is that there are in fact many easy ways to improve your software development lifecycle.
A judicious use of tools can go a long way in boosting developer productivity. For example, many distributed development teams use nothing more sophisticated than a CVS or Subversion repository for storing application code and a mailing list for discussion. Imagine a system in which, whenever someone commits a change, issues are automatically closed or updated based on the commit comment. The issue management system then automatically notifies the issue owner of the change of status. Meanwhile, a dedicated build server detects the commit, builds and tests the system, and notifies the developer of any failures. In a few relatively simple steps, you've taken your development platform to a newlevel of reactivity and responsiveness.
This is just a first step. Soon you will be integrating automatically running unit and possibly integration tests, code coverage tools, style checking tools, and more to create a highly reactive, informative, finely tuned project infrastructure.
Tools are the key to making such an infrastructure work efficiently. Once you start to adopt a set of SDLC tools that suit your project and your organization, you will see a revolutionary shift in a groups development practices. Agile development authors such as Alistair Cockburn rightly point to optimal communication as being the cornerstone of productive development. Developing in a team without continuous integration is like rock climbing without a rope. In addition, developing in a team without collaboration and connective development infrastructure is like developing in a boring beige office space where everyone comes to work on time, enters a closed office, closes the door, and starts programming without ever stopping to have meetings. In other words, programming without a good set of SDLC tools is very much the equivalent of fighting a modern war with swords and armor--the adoption of SDLC tools is a generational shift, the programmers just coming into the workforce will never know an alternative, but the programmers who haven't experienced this shift are in danger of missing the trend altogether.
Now you shouldn't go thinking that SDLC tools are only for large teams or big organizations. They aren't. In fact, most SDLC tools are easy to setup, and almost all organizations can benefit, even a small outfit with only two or three developers.
Most of these tools and techniques are not particularly difficult to put into place, but they do require a minimum of effort, to step back and take a long, hard look at your current practices. Chances are, there are things that can be improved.
This book is part of the O'Reilly Power Tools series, which began with the illustrious Unix Power Tools back in 1993. It has no relation to the "Java Power Tools" library (http://www.ccs. neu.edu/jpt/), which is a software research project in the Java GUI field, conducted by College of Computer & Information Science at the Northeastern University, Boston, under the direction of Richard Rasala.
How This Book Is Organized
One of the most characteristic traits of the open source (http://opensource. org) Java world is choice. It seems that, for any given task, there are always at least two open source tools that can do the job. To reflect this, I have tried to give a representative survey of the available open source tools for each area of software development that we cover. The book does not try to "sell" any one tool, or even any one tool in each domain. On the contrary, we try to give readers enough information so that they can decide for themselves which tool is the most appropriate for their particular organization, and give enough practical information to get them up and running.
This book is organized into sections, with each section covering a particular aspect of the software development lifecycle (or SDLC). With each section, we look at a number of available tools that can be used to improve this aspect of the SDLC.
Build Tools
In the first section, we cover possibly the most fundamental tool of all (after the compiler and the IDE, that is): the build tool. Indeed, when used well, the build tool becomes the cornerstone of your SDLC process. It is this tool that coordinates, federates, and binds the other SDLC tools together into a single, coherent process. And the build tool helps to ensure that your project can be built on any machine, in any environment.
In the Java world, two tools dominate this area. The first is Ant, the traditional Java build tool, which uses a straightforward procedural approach and benefits from a very large user base and a rich set of extensions. The second is Maven 2, which uses a powerful, declarative approach to project build management and, as we will see, goes much further than being a simple build tool. We will look at each of them in some detail in this section.
Version Control Tools
The second section covers that other fundamental component of any software development infrastructure: a version control system not only provides critical backups of your source code, it also lets developers work together on the same project without getting in each other's way. Version control systems also allow you to identify versions and coordinate releases and (if necessary) rollbacks. Finally, as we will see in Part VIII, it is a cornerstone of any Continuous Integration environment.
In this section, we will look at the two most prominent open source version control tools on the market: CVS and Subversion.
序言回到顶部↑
Designing, coding, and deploying working Java applications isn't easy. Doing it in a predictable manner rapidly with an acceptable level of quality is even harder. In addition to having to understand what stakeholders want or the varying skills of team members or even the myriad web, data access, and utility frameworks one can choose from, you've got to actually manage the development process itself! .
The coding of requirements is challenging enough, but as anyone who's ever delivered a working application knows, in the grand scheme of things, that's one sliver of the development process--in fact, some may say that's the easiest part. Think about all the techniques and processes that aggregate up to produce a software application. First, you've got to figure out how to deliver the working application in a predictable manner. At a high level, this means three things: tracking changes to source code assets, keeping up with any uncovered issues, defects, or feature requests, and assembling the application in a reliable and repeatable manner.
Next, you're going to want to actually ensure the application under development actually works--ideally during development. This means writing tests early. Of course, this process is easier said than done. Although arguably there are few standard testing frameworks from which to chose, there is a cornucopia of associated tools that accelerate writing developer tests by addressing specific challenges.
What's more, as the code base grows, you'll probably want to understand what's being coded and how well it's being developed. Although tests cancertainly verify code functionality, you may also want lighter-weight tools that can report on various metrics, such as complexity, coding standards, or even the coverage of tests. ..
Of course, if you've got a mechanism for assembling your application in a repeatable and reliable manner, it makes sense to augment this process by running tests and even analysis tools. What's more, given that you want to produce working code quickly, it makes sense to assemble the application often--in fact, assembling it continuously facilitates discovering issues as they arise.
Finally, you're going to want to enable easy maintenance of the code base so that features can be added often--in the same rapid and repeatable manner that the application was built.
John has assembled what I think is the "A" list of tools and techniques that will help you meet each and everyone of the challenges above. In fact, John presents multiple choices in some cases, giving you the opportunity to decide which tool works best for you. Whether you decide to use Ant or Maven for delivering a working application in a predictable manner, TestNG or JUnit for early developer testing, PMD or FindBugs for code analysis, or CruiseControl or Luntbuild for Continuous Integration, this book addresses the fundamental techniques for effectively employing these tools (and a multitude of others as well).
Rapid development of Java applications (which have an acceptable level of associated quality) is still hard as ever; however, after reading John's magnum opus on the tools and techniques that ultimately enable predictability, confident, and accelerated delivery in a software development process, you'll find that designing, coding, and deploying high-quality Java applications rapidly just got a whole lot easier. ...
--Andrew Glover, President, Stelligent Incorporated
The coding of requirements is challenging enough, but as anyone who's ever delivered a working application knows, in the grand scheme of things, that's one sliver of the development process--in fact, some may say that's the easiest part. Think about all the techniques and processes that aggregate up to produce a software application. First, you've got to figure out how to deliver the working application in a predictable manner. At a high level, this means three things: tracking changes to source code assets, keeping up with any uncovered issues, defects, or feature requests, and assembling the application in a reliable and repeatable manner.
Next, you're going to want to actually ensure the application under development actually works--ideally during development. This means writing tests early. Of course, this process is easier said than done. Although arguably there are few standard testing frameworks from which to chose, there is a cornucopia of associated tools that accelerate writing developer tests by addressing specific challenges.
What's more, as the code base grows, you'll probably want to understand what's being coded and how well it's being developed. Although tests cancertainly verify code functionality, you may also want lighter-weight tools that can report on various metrics, such as complexity, coding standards, or even the coverage of tests. ..
Of course, if you've got a mechanism for assembling your application in a repeatable and reliable manner, it makes sense to augment this process by running tests and even analysis tools. What's more, given that you want to produce working code quickly, it makes sense to assemble the application often--in fact, assembling it continuously facilitates discovering issues as they arise.
Finally, you're going to want to enable easy maintenance of the code base so that features can be added often--in the same rapid and repeatable manner that the application was built.
John has assembled what I think is the "A" list of tools and techniques that will help you meet each and everyone of the challenges above. In fact, John presents multiple choices in some cases, giving you the opportunity to decide which tool works best for you. Whether you decide to use Ant or Maven for delivering a working application in a predictable manner, TestNG or JUnit for early developer testing, PMD or FindBugs for code analysis, or CruiseControl or Luntbuild for Continuous Integration, this book addresses the fundamental techniques for effectively employing these tools (and a multitude of others as well).
Rapid development of Java applications (which have an acceptable level of associated quality) is still hard as ever; however, after reading John's magnum opus on the tools and techniques that ultimately enable predictability, confident, and accelerated delivery in a software development process, you'll find that designing, coding, and deploying high-quality Java applications rapidly just got a whole lot easier. ...
--Andrew Glover, President, Stelligent Incorporated
加载中...
