반응형

자바를 프로그래밍하기 위한 툴은 다양하다.
처음 학교에서 수업을 받을 땐, 메모장으로 'Hello, Java' 프로그램을 만들어 프로그래밍을 시작했다.
그리고 Command Prompt에서 javac와 java 명령어로 직접 컴파일 했었다.

그 이후에 Edit plus로 프로그래밍했었고, 더 이후에는 JBuilder를 썼다.
지금은 Eclipse를 쓰고 있다. 현재 많은 자바 프로그래머들이 Eclipse를 쓰고 있다.
이클립스는 자바 개발을 편리하게 할 수 있도록 통합개발환경(IDE)와 Plug-in을 제공한다.
이클립스는 무료로 다운로드가 가능하고, 다운로드 받은 후 압축을 풀면 바로 사용할 수 있다.

<이클립스 다운로드>
1. 이클립스 다운로드 싸이트에 접속한다.
   

http://www.eclipse.org/downloads/

    다양한 버전의 이클립스가 있다. 그 중에서 본인에게 적합한 버전을 클릭한다.
    연습용 자바 프로그래밍을 위해서라면, Eclipse IDE for Java Developers를 선택한다.

2. Eclipse downloads - mirror selection 페이지에서 스크롤을 내리면 미러 싸이트를 선택할 수 있다. 
    만약 인터넷이 느려 도중에 끊길 우려가 있다면 토렌트로 다운받는다.
    그렇지 않으면 2개의 한국 미러 싸이트 중 하나를 클릭한다.   

3. [Korea, Republic Of] 미러 중 하나를 클릭하여 다운 받는다.
    2011년 3월 기준으로 이클립스 helios 버전을 다운로드 받을 수 있다.

4. 다운로드가 완료되면 원하는 위치에 압축을 풀면 된다. 따로 설치가 필요없이 압축만 풀면 바로 실행할 수 있다.

5. 압축을 해제한 폴더 안에 eclipse.exe 파일이 있다. 이를 더블클릭하여 실행한다.
   바탕화면에 바로가기를 만들어 사용하면 편리하다.
   Send to (보내기) -> Desktop (create shortcut) (바탕화면 (바로가기 만들기))

6. 이클립스를 실행하면 이클립스 로고 화면이 나오고 Workspace를 설정하는 대화상자가 열린다.
   본인의 프로젝트 위치를 설정한 후, OK (확인) 버튼을 클릭한다.
   Workspace는 추후 변경할 수 있다.

   JVM terminated. Exit code=-1
   ......
   간혹 이런 에러가 발생할 수 있다.
   Windows XP에서 Ganymede 버전을 사용할 때 이런 에러가 발생했었다.
   이클립스 폴더에서 eclipse.ini 파일의 옵션을 수정하면 해결된다. (-Xmx를256m로 수정)
   참고로 Helios 버전은 -Xms40m -Xmx384m 로 되어있다.

7. 처음에는 Welcome 화면이 나타나며, 아래는 기존에 작업하던 패키지가 열린 화면이다.

이제 새로운 프로젝트/패키지/클래스를 생성하여 프로그래밍을 하면 된다.
즐프하길......

반응형
 
반응형
자바 프로그래밍을 위해 Eclipse를 사용하고 있다.
이클립스 사용에 대해서도 포스팅을 할 예정이지만 그 전에 공식적인 FAQ를 보고 넘어갈 생각이다.

출처 : http://wiki.eclipse.org/index.php/Eclipse_FAQs

<Contents>
1 Part I -- The Eclipse Ecosystem
  1.1 The Eclipse Community
  1.2 Getting Started
  1.3 Java Development in Eclipse
  1.4 Plug-In Development Environment
2 Part II -- The Rich Client Platform
  2.1 All about Plug-ins
  2.2 Runtime Facilities
  2.3 Standard Widget Toolkit (SWT)
  2.4 JFace
  2.5 Generic Workbench
  2.6 Perspectives and Views
  2.7 Generic Editors
  2.8 Actions, Commands, and Activities
  2.9 Building Your Own Application
  2.10 Productizing an Eclipse Offering
3 Part III -- The Eclipse IDE Platform
  3.1 Text Editors
  3.2 Help, Search, and Compare
  3.3 Workspace and Resources API
  3.4 Workbench IDE
  3.5 Implementing Support for Your Own Language
  3.6 Java Development Tool API


Part I -- The Eclipse Ecosystem

The Eclipse Community

Eclipse has taken the computing industry by storm. The download data for the Eclipse Software Development Kit (SDK) is astounding and a true ecosystem is forming around this new phenomenon. In this chapter we discuss what Eclipse is and who is involved in it and give you a glimpse of how large a community has put its weight behind this innovative technology.
 
An open source project would be nothing without a supporting community. The Eclipse ecosystem is a thriving one, with many research projects based on Eclipse, commercial products that ship on top of Eclipse, lively discussions in newsgroups and mailing lists, and a long list of articles and books that address the platform. The following pages will give you a roadmap of the community, so that you will feel more at home as you come to wander its winding streets.

 

Getting Started

Eclipse can be seen as a very advanced Java program. Running Eclipse may sound simple—simply run the included eclipse.exe or eclipse executable—yet in practice, you may want to tweak the inner workings of the platform. First, Eclipse does not come with a Java virtual machine (JVM), so you have to get one yourself. Note that any version later than Eclipse 3.0 needs a 1.4-compatible Java runtime environment (JRE), and the Java 5 JRE is recommended for Eclipse version 3.3.

To use Eclipse effectively, you will need to learn how to make Eclipse use a specific JRE. In addition, you may want to influence how much heap Eclipse may allocate, where it loads and saves its workspace from, and how you can add more plug-ins to your Eclipse installation.


This chapter should get you going. We also included some FAQs for plug-in developers who have already written plug-ins and want to get started with plug-in development for Eclipse 3.0.


Java Development in Eclipse


The topic of how to use Eclipse for typical Java development is beyond the scope of this FAQ list. We focus more on the issues Eclipse users may run into when developing new plug-ins for the platform. Also, as a plug-in developer, you need to be familiar with the ways in which Eclipse is used. To achieve seamless integration with the platform, your plug-in must respect common usage patterns and offer the same level of functionality that users of your plug-in have come to expect from the platform. This chapter focuses on user-level issues of interest to plug-in developers as users or as enablers for other users of the platform.

For a comprehensive guide to using Eclipse, refer to other books such as The Java Developer’s Guide to Eclipse (Addison-Wesley, 2003).


Plug-In Development Environment

This book is all about extending the Eclipse Platform. The main instrument for extending the platform is a plug-in. Plug-ins solidify certain crucial design criteria underlying Eclipse. Special tooling has been developed as part of Eclipse to support the development of plug-ins. This set of plug-ins is called the Plug-in Development Environment; or PDE. The PDE tools cover the entire lifecycle of plug-in development, from creating them using special wizards to editing them to building them to launching them to exporting and sharing them.

This chapter describes the mechanics of plug-in development, such as creating plug-ins, features, and update sites, and introduces the PDE tooling. We go into much more depth about what plug-ins are in later FAQs. If you want to jump ahead, we suggest that you first visit FAQ What is a plug-in?.



Part II -- The Rich Client Platform


All about Plug-ins


Part I discussed the Eclipse ecosystem: how to run it, how to use it, and how to extend it. In this chapter, we revisit the topic of plug-ins and lay the groundwork for all plug-in development topics to be discussed in later chapters. This chapter answers questions about the core concepts of the Eclipse kernel, including plug-ins, extension points, fragments, and more. All APIs mentioned in this chapter are found in the org.eclipse.core.runtime plug-in.


Runtime Facilities


Above, we already discussed most of the basic functionality of the org.eclipse.core.runtime plug-in. This chapter covers the remaining facilities of Eclipse Platform runtime: APIs for logging, tracing, storing preferences, and other such core functionality. These various services, although not strictly needed by all plug-ins, are common enough that they merit being located directly alongside the Eclipse kernel. In Eclipse 3.0, this plug-in was expanded to add infrastructure for running and managing background operations. This chapter answers some of the questions that may arise when you start to use this new concurrency infrastructure.


Standard Widget Toolkit (SWT)

One of the great success stories of the Eclipse Platform has been the overwhelming groundswell of support for its windowing toolkit, SWT. This toolkit offers a fast, thin, mostly native alternative to the most common Java UI toolkits, Swing and Abstract Windowing Toolkit (AWT). Religious debates abound over the relative merits of Swing versus SWT, and we take great pains to avoid these debates here. Suffice it to say that SWT generates massive interest and manages to garner as much, if not more, interest as the Eclipse Platform built on top of it.

The popularity of SWT has forced us to take a slightly different approach with this chapter. The SWT newsgroup was created in July 2003 and since then has generated an average of 136 messages every day. In this book, we could not even scratch the surface of the information available there. Although we could present the illusion of completeness by answering a couple dozen popular technical questions, we would not be doing the topic justice. Instead, we focus on answering a few of the higher-level questions and providing as many forward pointers as we can to further information on SWT available elsewhere. A benefit of SWT’s popularity is the wealth of Web sites, discussion forums, books, and other forms of documentation out there. Thus, although we won’t be able to answer all SWT questions, we hope at least to steer you to the resources that can. However, a handful of questions are asked so often that we can’t resist answering them here.


JFace

JFace is a Java application framework based on SWT. The goal of JFace is to provide a set of reusable components that make it easier to write a Java-based GUI application. Among the components JFace provides are such familiar GUI concepts as wizards, preference pages, actions, and dialogs. These components tend to be the bits and pieces that are integral to the basic widget set but are common enough that there is significant benefit to drawing them together into a reusable framework. Although its heritage is based on a long line of frameworks for writing IDEs, most of JFace is generally useful in a broad range of graphical desktop applications. JFace has a few connections to classes in the Eclipse runtime kernel, but it is fairly straightforward to extract JFace and SWT for use in stand-alone Java applications that are not based on the Eclipse runtime. JFace does not make use of such Eclipse-specific concepts as extensions and extension points.
 


Generic Workbench

This chapter covers FAQs relating to the generic workbench and its APIs. Workbench is the term used for the generic Eclipse UI. Originally the UI was called the desktop, but because Eclipse was a platform primarily for tools rather than for stationery, workbench was deemed more suitable. In Eclipse 3.0, tools are no longer the sole focus, so the term Rich Client Platform, is starting to creep in as the term for the generic, non-tool-specific UI. After all, people don’t want to play mine sweeper or send e-mails to Mom from such a prosaically named application as a workbench. A rich client, on the other hand, is always welcome at the dinner table.

Many of the important workbench concepts, such as editors, views, and actions, generate enough questions that they deserve their own chapters. This chapter focuses on general questions about integrating your plug-in with the various extension hooks the workbench provides.


Perspectives and Views


This chapter answers questions about two central concepts in the Eclipse Platform UI. Perspectives define the set of actions and parts that appear in a workbench window and specify the initial size and position of views within that window. Views are the draggable parts that make up the bulk of a workbench window’s contents. This chapter does not deal with any specific perspectives or views, but with questions that arise when you implement your own perspectives and views.
 


Generic Editors

In Eclipse, editors are parts that have an associated input inside a workbench window and additional lifecycle methods, such as save and revert. This chapter answers questions about interacting with editors and about writing your own editors, whether they are text based or graphical. See Chapter 15 for a complete treatment of questions about writing your own text-based editors.


Actions, Commands, and Activities


This chapter answers questions about creating menu bars, context menus, and tool bars and the actions that fill them. A variety of both declarative and programmatic methods are available for contributing actions to the Eclipse UI and for managing and filtering those actions once they have been defined. This chapter also discusses the various ways to execute the long-running tasks that can be triggered by menu and toolbar actions.

Actions are currently considered to be inferior to commands. The following information about actions is still left here to help people which are still using actions. If you can you should use commands.



Building Your Own Application


Prior to the introduction of RCP, most of the Eclipse community was focused on developing plug-ins for a particular Eclipse application called the workbench. Eclipse, however, has always supported the ability to create your own stand alone applications based on the Eclipse plug-in architecture. Eclipse applications can range from simple headless programs with no user interface to full-blown IDEs. In Eclipse 3.0, the platform began a shift toward giving greater power and flexibility to applications built on the Eclipse infrastructure. This chapter guides you through the process of building your own Eclipse application and explores some of the new Eclipse 3.0 APIs available only to applications.


Productizing an Eclipse Offering


In this chapter, we look at turning an Eclipse configuration into a product. When an Eclipse product is created, the anonymous collection of plug-ins takes on application-specific branding, complete with custom images, splash screen, and launcher. In creating your own product, you typically also need to write an installer and uninstaller and consider how your users will obtain and upgrade your product.



Part III -- The Eclipse IDE Platform


Text Editors


The most important purpose of an IDE is to browse and edit code. Therefore, perhaps even more than any other IDE platform, the Eclipse editor framework has grown into a highly evolved, flexible, easy-to-use, and easy-to-extend environment for editing program source files. In this chapter, we look at what support exists for writing editors and how easy it is to plug them into the Eclipse IDE platform.


Help, Search, and Compare


Admittedly, this chapter covers a number of unrelated components in the Eclipse Platform. They have in common the fact that each is designed as an independent plug-in that can be added to any Eclipse-based application. Although they are at home mostly in IDE applications, these plug-ins can also be inserted into RCP applications when help, search, or compare facilities are needed.


Workspace and Resources API


A program is never written in isolation but instead depends on other code, icons, data, and configuration files. An extendable IDE should provide access to wherever these artifacts are stored. In Eclipse, the artifacts are referred to as resources and are stored in a workspace. The FAQs in this chapter show how resources are managed in a workspace and what API is available to control and track their lifecycle.


Workbench IDE


The remaining plug-ins in the Eclipse Platform are truly oriented toward writing development tools. This chapter covers elements of the Eclipse IDE workbench, found in the org.eclipse.ui.ide plug-in. This plug-in includes most of the standard platform views, such as Navigator, Tasks, Problems, Properties, and Bookmark. We also take a quick look at advanced topics, such as writing repository clients and debuggers.


Implementing Support for Your Own Language


Through its JDT project, Eclipse has strong support for Java development, such as editing, refactoring, building, launching, and debugging. Likewise, the C development tools (CDT) project aims for similar support for writing C/C++ code. This chapter discusses some of the issues to address when you have your own language and want to host it in Eclipse for writing programs and plug-ins. We look at the various ways of integrating with Eclipse: from no integration to a fully integrated language development environment. To structure our discussion, we take a closer look at eScript, an experimental script language developed especially for this book. As is the case for all examples described in this book, you can find eScript on this book’s CD-ROM or Web site (http://eclipsefaq.org).


Many questions have been addressed in other FAQs in this book and may be somewhat repetitive. However, if you are planning to implement support for your own programming language, this chapter might serve well as a comprehensive overview of how to approach this big task.


Any classification of integration of a new programming language with Eclipse is somewhat arbitrary. We have identified the following degrees of integration of a new programming language, such as eScript, with Eclipse:

  • Phase 1—Compiling code and building projects. To obtain full integration with Eclipse in the area of compilation of programs and build processes for your own language, follow the various steps outlined in the FAQs below.
  • Phase 2—Implementing a DOM. The DOM is an in-memory structural representation of the source code of a program written in your language. Using the structural information contained in the DOM, all kinds of analysis and refactoring tools can be built.
  • Phase 3—editing programs. After writing a compiler, a builder, and a DOM, you are ready to consider all the individual steps to build the ultimate Eclipse editor for your language.
  • Phase 4—Adding the finishing touches. To give your language IDE a professional look, follow the steps outlined in the FAQs below.


If you carefully observe these four phases, you will find that the visual aspects of your language IDE happen late in the process. You will have to do some legwork before you are able to get to the pretty parts. We recommend patience and restraint. Time spent in phases 1 and 2 will be well spent, and once you get to phase 3 and 4, you will be grateful that you followed all the steps we outlined.


Java Development Tool API


From the outset, Eclipse has been used to develop Eclipse itself. The plug-ins that make up Eclipse are written in Java, and the concept of self-hosting has propelled the JDT to their current maturity level. When you are writing your plug-ins, you will also spend considerable time inside the JDT. A full coverage of JDT’s functionality is way beyond the scope of the list of FAQs in this chapter; however, we do focus on topics that are directly related to writing plug-ins and discuss aspects of JDT that warrant a discussion about how they are implemented rather than used.

It is important to realize that JDT itself has been written as a set of plug-ins and receives no special support from the platform. JDT represents a wealth of knowledge and is by far the most elaborate and advanced set of plug-ins in Eclipse. It is definitely worth spending some time to observe how JDT extends the platform and how its own extension points and API have been designed. It is likely that your plug-ins will deploy very similar patterns of extensions, extendibility, and reuse.


Finally, the JDT is a useful set of plug-ins in its own right, but it has also been carefully designed for extension by other plug-ins. By having a published API, it is easy to create new Java projects, generate Java source code, manage Java builds, inspect and analyze Java projects, and implement special refactorings. Refer to Help > Help Contents > JDT Plug-in Developer Guide for extensive documentation and tutorials describing the extension points and API published by JDT. For a comprehensive guide to Java development using Eclipse, see the Java Developers Guide to Eclipse (Addison-Wesley, 2003).

 

반응형
 

블로그 이미지

주야양

소소한 일상에 대한 기록

카테고리

Juyayang's hiStory (492)
[가상화폐(암호화폐)] (114)
[정보] (29)
[리뷰] (7)
[여행] (72)
[취미] (37)
[공부] (23)
[결혼] (18)
[임신 및 출산] (86)
[육아] (34)
[KOICA] (41)
[일상 생활] (20)
[자료실] (7)