[The Architecture of Open Source Applications] Eclipse
Bài đăng này đã không được cập nhật trong 3 năm
Bài viết sau dịch từ cuốn sách The Architecture of Open Source Applications.
Kiến trúc của ứng dụng mã nguồn mở
Các kiến trúc sư xem xét hàng nghìn tòa nhà trong quá trình học tập của họ, và tham khảo nhận xét được viết bởi các chuyên gia trong ngành. Ngược lại, hầu hết các lập trình viên chỉ hiểu một vài chương trình - đa số là những chương trình họ tự viết ra, và không bao giờ học hỏi những chương trình tốt đã được tạo ra. Kết quả là, họ lặp lại lỗi của mình hoặc của ai đó, thay vì phát triển dựa trên thành công của những người khác.
Mục tiêu của cuốn sách này là thay đổi điều đó. Trong cuốn sách này, tác giả của 25 ứng dụng mã nguồn mở sẽ giải thích cách cấu trúc của những phần mềm đó cũng như tại sao nó có kiến trúc như vậy. Đâu là thành phần chính của chương trình? Đâu là cách mà các thành phần tương tác với nhau? Những nhà phát triển học được điều gì khi phát triển ứng dụng? Để trả lời câu hỏi đó, những cộng tác viên của cuốn sách này (cũng chính là những kỹ sư phát triển ứng dụng mà nguồn mở) sẽ cung cấp cho chúng ta hiểu biết sâu sắc về cách làm của họ.
Nếu bạn là một lập trình viên mới vào nghề, và muốn biết những người đồng nghiệp có nhiều kinh nghiệm hơn mình nghĩ gì, cuốn sách này sẽ là nơi bạn bắt đầu. Nếu bạn là một lập trình viên trung bình hoặc đã có nhiều năm kinh nghiệm, và muốn xem cách mà những người khác giải quyết các bài toán khó khăn, cuốn sách này cũng có thể giúp bạn.
Chương 7. Eclipse
Phát triển phần mềm dựa trên kiến trúc của các mô-đun là một công việc cực kỳ khó khăn. Quản lý một lượng lớn mã nguồn được viết bởi một cộng đồng đa dạng cũng là công việc hết sức khó khăn. Với Eclipse, chúng tôi đã cố gắng đạt được cả 2 điều đó. Tháng 6 năm 2010, Nền tảng Eclipse cho ra đời Helios, phiên bản với 39 dự án và 490 kỹ sư phát triển từ hơn 40 nước trên thế giới cùng nhau làm việc dựa trên nền tảng ban đầu. Vậy đâu là mục tiêu ban đầu của kiến trúc Eclipse? Nó đã phát triển như thế nào? Làm cách nào để kiến trúc của một ứng dụng có thể lôi kéo được một cộng đồng lớn nhà phát triển? Hãy cũng quay lại thời điểm ban đầu.
Ngày mồng 7 tháng 11 năm 2001, một dự án mã nguồn mở tên gọi Eclipse 1.0 được phát hành. Tại thời điểm đó, Eclipse được mô tả là một môi trường phát triển tích hợp (IDE), cho tất cả và không có gì cụ thể. Mô tả này không nhằm vào đối tượng cụ thể nào cả, bởi tầm nhìn kiến trúc của Eclipse không dừng lại ở một tập các công cụ, mà là một khung phát triển (framework); một framework được tách biệt bởi các mô-đun và có thể mở rộng được. Eclipse cung cấp một nền tảng được xây dựng dựa trên các thành phần tách biệt (component-based platform) đóng vai trò nền móng cho việc xây dựng các công cụ cho lập trình viên. Kiến trúc có thể mở rộng này cho phép cộng đồng phát triển có thể xây dựng ứng dụng dựa trên nền tảng sẵn có, cũng như mở rộng để đi xa hơn so với phiên bản ban đầu.
Hình mẫu của một lập trình viên phát triển ứng dụng mã nguồn mở, từ trước đến nay luôn là một người dễ thông cảm, sẵn sàng làm việc đêm khuya để sửa lỗi và bổ sung thêm những tính năng mới, chỉ để thỏa mãn đam mê của họ. Ngược lại, nếu bạn nhìn về những ngày đầu của Eclipse, một trong những dòng code đầu tiên được viết bởi IBM dựa trên công cụ có sẵn lúc bấy giờ là VisualAge (một IDE ra đời từ những năm 80 thế kỷ trước). Những kỹ sư đầu tiên của Eclipse là thành viên của một dự án thuộc IBM mang tên Object Technology International(OTI). Những lập trình viên này được trả lương làm toàn bộ thời gian cho dự án mã nguồn mở này, bao gồm trả lời các câu hỏi trong nhóm thảo luận, báo lỗi phần mềm và phát triển chức năng mới. Một tổ chức bao gồm các nhà đầu tư phát triển phần mềm đã được tạo ra nhằm mở rộng ứng dụng này. Các thành viên ban đầu là Borland, IBM, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, và TogetherSoft.
Bằng việc đóng góp công sức của mình cho sự phát triển của ứng dụng, các công ty sẽ có quyền cung cấp sản phầm thương mại dựa trên Eclipse. Nó cũng giống với cách mà các tập đoàn đóng góp cho nhân hệ điều hành Linux bới họ muốn các nhân viên của mình cải thiện cho sản phẩm mà chính họ đang sử dụng cho các mục đích thương mại. Vào đầu năm 2004, tổ chức Eclipse Foundation được lập ra để quản lý và mở rộng cộng đồng đang lớn mạnh của Eclipse. Đây là một tổ chức phi lợi nhuận, được đầu tư bởi chính các thành viên và quản lý bởi một ban điều hành riêng. Giờ đây, cộng đồng Eclipse đã mở rộng ra với khoảng 170 công ty thành viên và khoảng 1000 lập trình viên.
Ban đầu, mọi người biết đến Eclipse như là 1 bộ phát triển phần mềm (SDK). Nhưng ngày nay, nó thực sự đã vượt trên điều đó rất nhiều. Đến tháng 7 năm 2010, có 250 dự án phát triển đa dạng dưới sự quản lý của eclipse.org. Đã có những công cụ hộ trợ lập trình C, C++, PHP, dịch vụ web, công cụ phát triển và hơn nữa. Mỗi dự án được bổ sung vào top-level project (TLP), được quản lý bởi ủy ban quản lý phần mềm, bao gồm các thành viên nhiều năm kinh nghiệm, có trách nhiệm xác định hướng kỹ thuật cũng như mục tiêu phát hành.
Phạm vi của chương này sẽ dừng lại ở sự phát triển trong kiến trúc của Eclipse SDK với dự án Eclipse và Runtime Equinox. Bởi Eclipse có một lịch sử lâu đời, chúng ta sẽ chỉ tập trung vào phiên bản ban đầu của Eclipse, và các phiên bản 3.0, 3.4 và 4.0.
7.1. Phiên bản ban đầu của Eclipse
Đầu thế kỷ 21, có rất nhiều công cụ phát triển phẩn mềm dành cho lập trình viên, nhưng rất ít trong số đó có thể cùng hoạt động. Eclipse hình thành để có thể cung cấp một nền tảng mã nguồn mở, cho sự ra đời của các công cụ có khả năng quản lý nhiều chức năng cho lập trình viên. Nó giúp các lập trình viên tập trung vào việc tạo ra sản phẩm, hơn là lo lắng về việc tương tác với hệ thống tập tin (file system), cập nhần phần mềm và kết nối đến kho mã nguồn của chương trình. Eclipse nổi tiếng nhất có lẽ là bởi Java Development Tool (JDT). Mục đích của nó là xây dựng một công cụ tuyệt vời mà từ đó mọi người có thể thấy được và tạo nên công cụ cho các ngôn ngữ khác.
Trước khi tìm hiểu sâu vào kiến trúc của Eclipse, chúng ta hãy cùng nhìn Eclipse SDK dưới cái nhìn của lập trình viên. Sau khi khởi động ứng dụng và lựa chọn môi trường làm việc, chúng ta sẽ thấy được hình ảnh của Eclipse. Trong đó, phần view (chỉ nhìn) và editor (chỉnh sửa) được thiết lập cho công cụ đang được lựa chọn.
Phiên bản ban đầu của Eclipse SDK dựa trên 3 thành phần chính, tương ứng với 3 dự án liên quan: Nền tảng (Platform), công cụ phát triển Java (JDT - Java Development Tools) và Môi trường phát triển Plug-in (PDE - Plug-in Development Environment).
7.1.1 Platform - Nền tảng
Nền tảng Eclipse được viết bởi Java và cần máy ảo Java (Java VM) để có thể chạy được. Nó được xây dựng từ những phần chức năng nhỏ gọi là plugins. Plugin là thành phần cơ bản trong kiến trúc cấu thành của Eclipse. Một plugin đơn giản là 1 tập tin JAR trong đó chứa bản ghi mô tả chính nó, các thành phần phụ thuộc của nó và cách nó được sử dụng, mở rộng. Bản ghi này khi khởi tạo được đặt tên là plug-in.xml nằm ngay tại thư mục chứa plugin. Công cụ phát triển Java cung cấp plugin cho phát triển Java. Môi trường phát triển Plugin cung cấp các công cụ cho việc phát triển plugin nhằm mở rộng Eclipse. Plugin của Eclipse được viết bằng Java nhưng cũng có thể chứa các tập tin không phải code, như các file HTML đóng vai trò tài liệu công bố trên mạng. Mỗi plugin có 1 class riêng đóng vai trò khởi tạo (class loader). Plugins có thể mô tả sự phụ thuộc đến các plugin khác thông qua câu cú pháp requires trong khai báo plugin.xml. Nhìn vào tập tin plugin.xml của plugin org.eclipse.ui, bạn có thể thấy tên và phiên bản cũng như các thành phần nó cần dùng đến từ plugin đó.
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id="org.eclipse.ui"
name="%Plugin.name"
version="2.1.1"
provider-name="%Plugin.providerName"
class="org.eclipse.ui.internal.UIPlugin">
<runtime>
<library name="ui.jar">
<export name="*"/>
<packages prefixes="org.eclipse.ui"/>
</library>
</runtime>
<requires>
<import plugin="org.apache.xerces"/>
<import plugin="org.eclipse.core.resources"/>
<import plugin="org.eclipse.update.core"/>
: : :
<import plugin="org.eclipse.text" export="true"/>
<import plugin="org.eclipse.ui.workbench.texteditor" export="true"/>
<import plugin="org.eclipse.ui.editors" export="true"/>
</requires>
Nhằm khuyến khích các lập trình viên xây dựng ứng dụng trên nền tảng Eclipse, cần có một cơ chế cho phép đóng góp vào nền tàng Eclipse, cũng như cho phép nền tảng Eclipse chấp nhận đóng góp đó. Để đạt được điều đó, Eclipse sử dụng thành phần mở rộng (extensions) và điểm mở rộng (extension points), một thành phần khác của mô hình Eclipse. Khi sử dụng, bạn được phép xác định thành phần mà bạn cho phép người khác sử dụng khi viết extensions của họ, qua đó giới hạn các thành phần có thể được sử dụng bởi extensions bên ngoài plugin của bạn. Nó cũng cung cấp thông tin bổ sung về tài nguyên có thể dùng bên ngoài plugin, khác với cách đưa tất cả các method và class thành dạng công khai(public). Các plugin được đem ra sử dụng chung, được coi như là các API công khai public API. Những phần khác được coi như riêng tư(private). Để có thể viết 1 plugin đóng góp cho một thành phần trên menu của thanh công cụ Eclipse(Eclipse toolbar), bạn có thể sử dụng actionSets trong plugin org.eclipse.ui.
<extension-point id="actionSets" name="%ExtPoint.actionSets"
schema="schema/actionSets.exsd"/>
<extension-point id="actionSets" name="%ExtPoint.commands"
schema="schema/commands.exsd"/>
<extension-point id="actionSets" name="%ExtPoint.contexts"
schema="schema/commands.exsd"/>
<extension-point id="actionSets" name="%ExtPoint.decorators"
schema="schema/decorators.exsd"/>
<extension-point id="actionSets" name="%ExtPoint.dropActions"
schema="schema/dropActions.exsd"/>
Nếu muốn tạo 1 extension đóng góp cho org.eclipse.ui.actionSet, bạn có thể thiết lập như sau:
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id="com.example.helloworld"
name="com.example.helloworld"
version="1.0.0">
<runtime>
<library name="helloworld.jar"/>
</runtime>
<requires>
<import plugin="org.eclipse.ui"/>
</requires>
<extension point="org.eclipse.ui.actionSets">
<actionSet
label="Example Action Set"
visible="true"
id="org.eclipse.helloworld.actionSet">
<menu
label="Example &Menu"
id="exampleMenu">
<separator name="exampleGroup">
</separator>
</menu>
<action
label="Example Action"
icon="icons/example.gif"
tooltip="Hello, Eclipse world"
class="com.example.helloworld.actions.ExampleAction"
menuPath="exampleMenu/exampleGroup"
toolbarPath="exampleGroup"
id="org.eclipse.helloworld.actions.ExampleAction">
</action>
</actionSet>
</extension>
</plugin>
Khi Eclipse được khởi động, nó tự động tìm đến thiết lập plugin mà bạn cài thêm, lưu toàn bộ thiết lập đó trong bộ nhớ(memory). Extension points và các extensions liên quan được kết nối thông qua tên của chúng. Bản thiết lập được lưu trong bộ nhớ sẽ được kết nối với API được cung cấp bởi Eclipse platform. Thiết lập đó được lưu lại trong ổ đĩa, cho phép thông tin có thể mở lại nhanh chóng khi Eclipse được khởi động lại. Tất cả thiết lập của plugins được lưu lại trong bộ nhớ ngay khi khởi động Eclipse, nhưng chúng không được đưa vào hoạt động cho đến khi code chính thức được sử dụng. Cách tiếp cận này được gọi là lazy activation. Nhờ cách tiếp cận này mà việc khởi tạo plugin của bạn không ảnh hưởng quá nhiều đến hiệu năng của Eclipse, bởi các classes chỉ được khởi tạo khi chúng thực sự cần thiết. Ví dụ, plugin đóng góp cho org.eclipse.ui.actionSet sẽ không bao giờ được khởi tạo cho đến khi bạn chọn mục mới trên thanh menu.
Sau đây là mã nguồn sinh ra item mới cho thanh menu:
package com.example.helloworld.actions;
import org.eclipse.jface.action.IAction;
import org.eclipse.jsface.viewers.ISelection;
import org.eclipse.ui.IWorkbenchWindow;
import org.eclipse.ui.IWorkbenchWindowActionDelegate;
import org.eclipse.jface.dialogs.MessageDialog;
public class ExampleAction implements IWorkbenchWindowActionDelegate {
private IWorkbenchWindow window;
public ExampleAction() {
}
public void run(IAction action) {
MessageDialog.openInformation(
window.getShell(),
"org.eclipse.helloworld",
"Hello, Eclipse architecture world"
);
}
public void selectionChanged(IAction action, ISelection selection) {
}
public void dispose() {
}
public void init(IWorkbenchWIndow window) {
this.window = window;
}
}
Khi người dùng lựa chọn item mới trên thanh menu, Eclipse sẽ gửi yêu cầu đến plugin đã tạo ra extension point này. Plugin sẽ bắt đầu công việc đóng góp cho Eclipse. Khi plugin này được gọi đến, hàm khởi tạo của class ExampleAction bắt đầu chạy. Vì lựa chọn trên thanh menu đã thay đổi, nên một hộp thoại (dialog) được tạo ra với nội dung "Hello, Eclipse architecture world".
Kiến trúc có thể mở rộng là một trong những chìa khóa dẫn đến thành công của hệ sinh thái Eclipse. Các công ty, cá nhân có thể phát triển plugins của riêng họ, có thể phát hành nó dạng mã nguồn mở hoặc bán nó dưới phương diện thương mại.
Một trong những khái niệm quan trọng nhất của Eclipse là: Tất cả đều là plugin (Everything is a plugin). Dù là plugin được khởi tạo từ đầu của Eclipse, hay được bạn viết ra, nó luôn là các class đầu tiên của ứng dụng. Hình 7.3 cho thấy một loạt các chức năng được cung cấp dưới dạng plugins trong phiên bản đầu tiên của Eclipse.
Workbench là một trong những thành phần giao diện (UI) được biết đến nhiều nhất của Eclipse, nó cung cấp kiến trúc của cách mà Eclipse hiển thị trên màn hình máy tính của người dùng. Workbench bao gồm phối cảnh (perspectives), danh sách (views), và công cụ chỉnh sửa (editors). Editors tương thích với loại tập tin, nên khi editor được khởi tạo, Eclipse sẽ chọn đúng editor cho tập tin đó. Một ví dụ của view là problems view (các vấn đề), trong đó chỉ ra các lỗi, cảnh báo đối với mã nguồn. Editors cùng với views tạo nên perspective, cung cấp công cụ cho người dùng theo một thệ thống có tổ chức.
Eclipse workbench được xây dựng trên nền tảng Standard Widget Toolkit (SWT), JFace trong đó SWT có rất nhiều cải tiến. Các thành phần trong đó được phân loại thành gốc (native) và mô phỏng(emulated). Một công cụ gốc sự dụng các lời gọi đến hệ điều hành và tạo ra các thành phần giao diện như danh sách, nút bấm. Tương tác đối với các thành phần này sẽ được hệ điều hành xử lý. Một công cụ mô phỏng tạo nên các thành phần tách biệt với hệ điều hành, quản lý chuột, bản phím, vẽ,.. và các chức năng riêng biệt khác, không phải làm theo hệ điều hành. Mỗi thiết kế đều có điểm mạnh và điểm yếu.
Công cụ gốc được xem như là "pixel perfect" (hoàn hảo đến từng điểm). Các công cụ này có bề ngoài giống như những thành phần tương tự trong các ứng dụng khác của hệ điều hành. Hệ điều hành thường thay đổi thiết kế, màu sắc của các công cụ này, cũng như thêm nhiều tính năng. Và các công cụ gốc sẽ được cập nhật tự động, miễn phí. Tuy nhiên, không may mắn là, các công cụ gốc thường rất khó để khởi tạo, bởi cách khởi tạo chúng bên trong hệ điều hành là rất khác biệt so với ứng dụng hiện tại, dẫn tới sự thiếu thống nhất trong thiết kế và ứng dụng không thể mang đến các máy khác nhau một cách dễ dàng.
Các công cụ mô phỏng, hoặc là cố gắng tạo ra một thiết kế của riêng nó, hoặc cố gắng mô phỏng giao diện và tính năng của công cụ sẵn có trong hệ điều hành. Điểm mạnh của chúng so với các công cụ sẵn có là nó rất linh hoạt (mặc dù công cụ sẵn có gần đây như Windows Presentation Framework (WPF) cũng rất linh hoạt). Bởi mã nguồn khởi tạo các công cụ này là một phần của bộ công cụ, chứ không phải bó buộc vào hệ điều hành, các công cụ này có thể được tạo ra và hoạt động theo bất cứ kiểu cách nào. Các ứng dụng được tạo bởi công cụ mô phỏng rất dễ để di chuyển. Tuy nhiên, các công cụ mô phỏng thế hệ đầu tiên lại có tiếng xấu. Chúng quá chậm và không thực sự mô phỏng được chức năng mà hệ điều hành cung cấp, biến chúng thành công cụ khác hoàn toàn so với các ứng dụng hiện tại. Ví dụ, Smalltalk-80 đã từng rất dễ để nhận biết, bởi cách dùng các thành phần của nó. Người dùng nhận ra rằng có một tứng dụng đang chạy gọi là Smalltalk program và nó làm hỏng giao diện của các ứng dụng Smalltalk.
Không giống như ngôn ngữ lập trình khác như C hay C++, phiên bản đầu tiên của Java được xây dựng với thư viện native Abstract Window Toolkit (AWT). AWT có quá nhiều giới hạn, lỗi, thiếu thống nhất và có giá trị rất thấp. Ở Sun và một vài nơi khác, bởi AWT có quá nhiều lỗi, một bộ công cụ sẵn có trở nên vô dụng. Để giải quyết vấn đề này, Swing ra đời. Nó là một bộ công cụ mô phỏng với đầy đủ chức năng cần thiết.
Khoảng năm 1999, OTI sử dụng Java để tạo ra một sản phẩm tên là Visual Micro Edition. Phiên bản đầu tiên của VisualAge Micro Edition sử dụng Swing với kinh nghiệm của OTI với Swing đã không thể thực hiện được. Phiên bản đầu tiên của Swing có quá nhiều lỗi, tốn bộ nhớ và thời gian cũng như tài nguyên phần cứng, khiến cho phần cứng thời đó không đủ sức mạnh đáp ứng được yêu cầu về hiệu năng. OTI đã thành công trong việc xây một bộ công cụ gốc cho Smalltalk-80 và các ứng dụng khác được xây dựng bởi Smalltalk. Phiên bản này được sử dụng cho phiên bản đầu tiên của SWT. VisualAge Micro Edition và SWT đã thành công và SWT được coi như là lựa chọn tự nhiên khi bắt đầu với Eclipse. Việc sử dụng SWT chứ không phải Swing đã phân chia cộng đồng Java ra làm hai. Tuy nhiên, cuối cùng thì Eclipse đã thành công và việc sử dụng SWT tách biệt nó với những chương trình Java khác. Eclipse đặt được hiệu năng cần thiết, hoàn hảo đến từng pixel và có một câu nói đầy ngụ ý, "I can't belivew it's a Java program." (Tôi không thể tin được nó là một chương trình Java).
Phiên bản đầu tiên của Eclipse chạy trên Linux, Window. Năm 2010, Eclipse hoạt động trên rất nhiều nền tảng khác nhau. Một lập trình viên có thể viết ứng dụng trên một nền tảng nhất định, và thiết lập để nó chạy trên hàng tá nền tảng khác nhau. Xây dựng một bộ công cụ cho Java là một công việc mệt ỏi trong thời gian đó, nhưng các thành viên trong cộng đồng Eclipse tin rằng điều đó đáng giá để cung cấp một trải nghiệm tốt cho ứng dụng của họ. Điều đó vẫn còn đúng đến bây giờ, khi mà có hàng triệu dòng code phát triển dựa trên SWT.
JFace nằm trên cùng của SWT, cung cấp công cụ cho các thao tác giao diện cơ bản. Giống như SWT, nó được thiết kế để có thể chạy trên nhiều hệ điều hành khác nhau. Tuy nhiên, nó hoàn toàn là Java và không chứa bất cứ dòng code nào thuộc về nền tảng gốc.
Nền tảng Eclipse cũng cung cấp một hệ thống giúp đỡ cho phép tương tác với người dùng, xây dựng trên tập các thành phần thông tin nhỏ gọi là chủ đề (topics). Một topic bao gồm nhãn (label), và liên kết đến nơi lưu giữ nó. Nơi lưu giữ topic có thể là một tập tin HTML, một tập tin XML với các link liên quan. Topics được nhóm lại trong mục lục (table of content - TOCs). Có thể xem topics là lá, và TOCs là cành trong một tổ chức. Để bổ sung thông tin giúp đỡ vào ứng dụng của mình, bạn có thể đóng góp cho org.eclipse.help.toc, giống như ví dụ org.eclipse.platform.doc.isv.plugin.xml sau đây.
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<!-- ============================================== -->
<!-- Define primary TOC -->
<!-- ============================================== -->
<extension
point="org.eclipse.help.toc">
<toc
file="toc.xml"
primary="true">
</toc>
<index path="index"/>
</extension>
<!-- ============================================== -->
<!-- Define primary TOC -->
<!-- ============================================== -->
<extension
point="org.eclipse.help.toc">
<toc
file="topics_Guide.xml">
</toc>
<toc
file="topics_Reference.xml">
</toc>
<toc
file="topics_Porting.xml">
</toc>
<toc
file="topics_Questions.xml">
</toc>
<toc
file="topics_Samples.xml">
</toc>
</extension>
</plugin>
Apache Lucene được sử dụng để lập bảng chỉ mục và tìm kiếm tài liệu giúp đỡ online. Ở phiên bản đầu tiên của Eclipse, tài liệu giúp đỡ online được quản lý bởi Tomcat. Thêm nữa, bằng việc bổ sung chức năng giúp đỡ ngay bên trong ứng dụng Eclipse, bạn có thể sử dụng một phần của plugin giúp đỡ để khởi tạo một server chạy độc lập.
Eclipse cũng cung cấp một nhóm hỗ trợ để tương tác với mã nguồn, tạo ra các bản vá cũng như thực hiện các tác vụ chung. Workspace cung cấp một bộ các tập tin, thông tin chỉ mục nơi lữu giữ công việc của bạn trong hệ thống file. Eclipse cũng cung cấp công cụ kiểm thử, phát hiện lỗi cho code Java, cũng như thư viện cho việc xây dựng công cụ kiểm tra cho các ngôn ngữ khác nhau.
Một trong những mục tiêu của dự án Eclipse là khuyến khích mã nguồn mở và các khách hàng muốn thương mại hóa ứng dụng mở rộng nó cho phù hợp với yêu cầu của họ, và một trong nhưng cách để khuyến khích điều đó là cung cấp một bộ API ổn đinh. Một API có thể coi như một bản hợp đồng kỹ thuật, miêu tả rõ ràng cách hoạt động của ứng dụng của bạn. Nó có thẻ được coi như là một hợp đồng mang tính xã hội. Trong dự án Eclipse, câu thần chú là: "API is forever" (API mãi mãi). Do vậy, khi xây dựng một API, bạn cần xem xét thật chắc chắn, cẩn thận, để nó có thể sử dụng mãi mãi. Một API ổn định là một hợp đồng giữa khách hàng và nhà cung cấp. Bản hợp đồng đó đảm bảo rằng khách hàng có thể tin tưởng vào nền tảng Eclipse và các API được phổ biến trong một thời gian dài, mà không cần phải lo việc chỉnh sửa ứng dụng của họ. Một API tốt là một API đủ linh hoạt để có thể cho phép cách thực hiện của nó được cải tiến.
7.1.2 Java Development Tools (JDT) - Công cụ phát triển Java
JDT cung cấp công cụ chỉnh sửa cho Java, hỗ trợ tái cấu trúc code, phát hiện lỗi, trình dịch và công cụ build ứng dụng. Trình dịch cũng được dùng cho việc phân tích nội dung, di chuyển giữa các thành phần và các chưng năng chỉnh sửa khác. Java SDK không được phân phối cùng với Eclipse, nên người dùng có quyền chọn SDK nào mình muốn cài đặt. Tại sao đội phát triển JDT lại tách trình dịch ra khổi Eclipse? Bởi họ có một
trình dịch được đóng góp bởi VisualAge Micro Edtition. Họ lập kế hoạch xây dựng công cụ lên trên trình dịch, cho nên việc chỉ viết trình dịch sẽ dẫn đến một số quyết định khó khăn. Cách tiếp cận này cũng cho phép những người phát triển JDT cung cấp các extension points cho việc mở rộng trình dịch. Thật khó khăn nếu trình dịch là một ứng dụng chạy dòng lệnh được cung cấp bởi một tổ chức thứ 3.
Xây dựng trình dịch của riêng họ cung cấp một chơ chế cho việc tăng cường số lượng các builder bên trong IDE. Builder cung cấp hiệu năng tốt, bởi chúng chỉ là một tập tinh được biên dịch lại theo các thành phần phụ thuộc. Làm cách nào mà builder hoạt động? Khi bạn tạo một dự án bên trong Eclipse, bạn tạo tài nguyên bên trong khu vực làm việc và lưu giữ các tập tin của bạn. Builder nằm trong Eclipse nhận các tập tin .java làm đầu vào và tạo tập tin .class là đầu ra. Thông qua trạng thái build, builder sẽ biết loại tập tin nào đang nằm trong hệ thống, và cách chúng liên kết với nhau. Trạng thái build được cung cấp bởi cho builder nhờ trình dịch, mỗi khi một tập tin mã nguồn được biên dịch. Khi mã nguồn bị xóa, file class cũng bị xóa. Khi có file mới, hoặc file bị thay đổi, chúng được đưa vào hàng đợi. File trong hàng đợi được biên dịch và kiểm tra với class xem có bất kỳ thay đổi về cấu trúc hay không. Ví dụ, thay đổi phương thức, thêm hoặc xóa phương thức. Nếu toàn bộ cấu trúc bị thay đổi, một class hoàn toàn mới sẽ được lưu vào thư mục. Trạng thái build sẽ được cập nhật ngay lập tức. Quá trình này được lặp đi lặp lại với tất cả các tập tin trong hàng đợi. Nếu có một lỗi biên dịch, chương trình sẽ tạo ra một dấu hiệu cho lỗi này. Qua từng năm, công cụ mà JDT cung cấp mở rộng một cách nhah chóng, đi kèm với các phiên bản mới của trình thực hiện Java.
7.1.3 Plug-in Development Environment (PDE) - Môi trường phát triển Plugin
PDE cung cấp công cụ cho phát triển, xây dựng, triển khai và kiểm thử plugin, và các thành phần khác được sử dụng để mở rộng Eclipse. Bởi Eclipse plugins là thành phần mới của Eclipse mà không có một hệ thống nào có thể truyển đổi mã nguồn sang plugins, cho nên đội ngũ phát triển PDE đã viết một thành phần gọi là PDE Build nhằm kiểm tra các thành phần phụ thuộc của Plugin và sinh ra đoạn mã Ant để khởi tạo thành phần có chức năng xây dựng plugin.
Phần 7.2 và 7.3 sẽ được dịch trong các bài viết tiếp theo (bow)
Quan điểm cá nhân
Lời đầu tiên, với một lập trình viên mới vào nghề như tôi, Eclipse thực sự là một phần mềm quá sức! Trước đây mới chỉ có hiểu biết về 1 vài phiên bản Eclipse cho Java hay C++, đến nay tôi mới biết ngay từ đầu Eclipse đã được phát triển để có thể mở rộng như bây giờ. (baiphuc)
Tác giả cuốn sách không đề cập đến mức thiết kế class, mà ở đây là ở mức cao hơn, plugin. Không có quá nhiều điều để rút ra từ chương sách này về chi tiết kỹ thuật, chủ yếu là cách nghĩ và cách làm của tác giả.
All rights reserved
