작업 공간 (프로젝트, 응용 프로그램 (멀티 어셈블리 여부), 프로그램 언어, 대상 (웹 개발, 플러그인 등)을 사용하는 다양한 방법을보고 읽고 생각했습니다.) 여전히 최선의 접근법이 무엇인지 의심하고 있습니다.

어쨌든 정교하지만 페이지에 대한 긴 통찰력을 줄 수 있습니까?

이것은 많은 하위 질문과 관련이 있으며, 말해야 할 특정 하위 질문을 모두 모릅니다. 왜냐하면 일식 (및 작업 공간)의 모든 측면을 모릅니다. 나는 내가 찾고있는 것에 대한 예를 제시하려고 노력할 것이다.

• 무엇 때문에?
  
  • 이클립스 개발은 그것이 사용되었다는 것을 의미 했습니까?
  • 다른 사람 / 대부분의 사람들은 어떻게 생각합니까?
  • 어떻게 생각해?
  • ...?
• 왜?
  
  • 구성 충돌과 장점이 있습니까?
  • 파일 공간 이유가 있습니까?
  • 공연?
  • ...?

아, 그리고 다른 언어와 프로토콜을 사용하는 개발자의 최소 사용 사례에 대해 말하고 있으며 하나의 프로젝트 (예 : php, javascript 및 xml, 일부 프로젝트의 경우 C #, 여전히 java의 경우) 기타 등등.)

2012-11-27 편집 : 실수하지 마십시오. 나는 작업 공간의 사용을 의심하지 않습니다. 나는 누군가가 더 잘 생각할 수 있다면 그대로 사용하고 싶습니다. 그래서 "무엇을 위해?" 의미 : 가장 좋은 사용법은 무엇입니까? 그리고 왜?" 실제로 "무엇을 위해?"를 목표로합니다. 즉, 귀하의 답변에 대한 이유를 알려주십시오.

Java 세계에서 매우 불편하다고 느끼는 사람에 대한 내 비전을 알려 드리겠습니다.이 또한 귀하의 경우입니다.

그것은 무엇인가

작업 공간은 그룹화의 개념입니다.

1. (어떻게 든) 관련 프로젝트 세트
2. 이 모든 프로젝트와 관련된 일부 구성
3. Eclipse 자체의 일부 설정

이것은 Eclipse에 이러한 정보를 알려주는 디렉토리를 만들고 (내가 할 필요는 없으며, 당신을 위해 완료 된) 디렉토리를 만들어서 발생합니다. 이러한 파일을 저장할 폴더를 명시 적으로 지정하기 만하면됩니다. 이 폴더는 소스 코드를 넣는 위치와 같을 필요는 없습니다. 우선적으로는 그렇지 않습니다.

위의 각 항목을 탐색하십시오.

1. (어떻게 든) 관련 프로젝트 세트

Eclipse는 항상 특정 작업 공간과 관련하여 열린 것처럼 보입니다. 즉, 작업 공간 A에 있고 작업 공간 B 로 전환하기로 결정한 경우 (파일> 작업 공간 전환) Eclipse가 자체 닫히고 다시 열립니다. 작업 공간 A 와 연관되고 프로젝트 탐색기에 나타나는 모든 프로젝트 가 더 이상 나타나지 않으며 이제 작업 공간 B 와 연관된 프로젝트 가 나타납니다. 따라서 Eclipse에서 열려있는 프로젝트는 반드시 작업 공간과 관련이 있어야 합니다.

이것이 프로젝트 소스 코드가 작업 공간 안에 있어야한다는 것을 의미하지는 않습니다. 작업 공간은 어떻게 든 디스크에있는 프로젝트의 실제 경로와 관련이 있습니다 (아무도 알고 있습니까? 작업 공간 내부에서 성공하지 않고 프로젝트 경로를 가리키는 일부 파일을 검색했습니다).

이런 방식으로 프로젝트는 한 번에 둘 이상의 작업 공간에있을 수 있습니다. 따라서 작업 공간과 소스 코드를 분리하여 보관하는 것이 좋습니다.

2. 이 모든 프로젝트와 관련된 일부 구성

Java 컴파일러 버전 (예 : 1.7과 같은 것- 'version'이 여기서 단어인지 모르겠습니다)과 같은 것이 작업 공간 수준 구성이라고 들었습니다. 작업 공간에 여러 프로젝트가 있고 Eclipse 내부에서 컴파일하면 모든 프로젝트가 동일한 Java 컴파일러로 컴파일됩니다.

3. Eclipse 자체의 일부 설정

키 바인딩과 같은 일부 작업 영역 수준에도 저장됩니다. 따라서 ctrl + tab이 탭을 스마트하게 (스태킹하지 않고) 전환하도록 정의하면 현재 작업 공간에만 바인딩됩니다. 다른 작업 공간에서 동일한 키 바인딩을 사용하려면 (및 원한다고 생각합니다!) 작업 공간간에 내보내거나 가져와야하는 것처럼 보입니다 (그렇다면이 IDE는 정말 이상한 건물 위에 구축되었습니다). 여기에 링크가 있습니다.

또한 작업 공간이 서로 다른 Eclipse 버전간에 호환되는 것은 아닙니다. 이 기사 에서는 Eclipse 버전의 이름이 포함 된 작업 공간의 이름을 지정하도록 제안합니다.

더 중요한 것은 폴더를 작업 공간으로 선택하면 내부의 파일을 만지지 마십시오.

내가 그것을 사용하는 좋은 방법이라고 생각하는 방법

(실제로 이것을 작성하면서 이것을 잘 사용하는 방법을 모르겠습니다. 그래서 저는 답을 찾고있었습니다 – 여기에 모 으려고합니다)

1. 프로젝트 폴더를 만듭니다.
   /projects

2. 각 프로젝트에 대한 폴더를 작성하고 그 안에 프로젝트의 하위 프로젝트를 그룹화하십시오.
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. 작업 공간을위한 별도의 폴더를 작성하십시오.
   /eclipse-workspaces

4. 프로젝트의 작업 공간을 작성하십시오.
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

작업 공간의 요점은 일반적으로 응용 프로그램을 구성하는 관련 프로젝트 세트를 그룹화하는 것입니다. 작업 공간 프레임 워크는 eclipse.core.resources플러그인으로 제공되며 설계 상 당연히 의미가 있습니다.

프로젝트에는 특성이 있으며 빌더는 특정 프로젝트에 첨부되며 한 프로젝트에서 자원을 변경하면 동일한 작업 공간에있는 프로젝트의 실시간 컴파일 또는 기타 문제에서 볼 수 있습니다. 따라서 내가 제안하는 전략은 작업하는 프로젝트마다 다른 작업 공간이 있지만 일식에 작업 공간이 없으면 프로젝트 및 구성 모음에 대한 개념이 없으며 결국 IDE 도구입니다.

이것이 의미가 없다면 Net Beans 또는 Visual Studio가 어떻게 이것을 해결합니까? 같은 주제입니다. Maven은 좋은 예입니다. 관련 Maven 프로젝트 그룹을 작업 공간으로 체크 아웃하면 실시간으로 오류를 개발하고 볼 수 있습니다. 작업 공간이 아닌 경우 다른 제안을 하시겠습니까? RCP 응용 프로그램은 용도에 따라 다른 짐승이 될 수 있지만 진정한 IDE 의미에서 프로젝트의 작업 공간이나 컨텍스트보다 더 나은 솔루션이 무엇인지 알 수 없습니다. 그냥 내 생각 -던컨

기본적으로 작업 영역의 범위는 두 지점으로 나뉩니다.

첫 번째 포인트 (및 기본)는 자체 일식이며 설정 및 메타 데이터 구성 (플러그인 ctr)과 관련이 있습니다. 프로젝트를 작성할 때마다 eclipse는 모든 구성을 수집하여 해당 작업 공간에 저장하며, 동일한 작업 공간에 충돌하는 프로젝트가 존재하는 경우 일부 기능이 누락되거나 자체적으로 Eclipse의 안정성이 저하 될 수 있습니다.

그리고 두 번째 (2 차) 개발 전략의 관점에서 채택 할 수 있습니다. 기본 범위가 충족되고 마스터되면 프로젝트 관계 (라이브러리, 관점 ctr)와 관련하여 추가 조정이 필요한 경우 개발 습관 또는 가능한 언어 / 프레임 워크 "동작"에 따라 별도의 작업 영역을 시작할 수 있습니다. 예를 들어 DLTK는 별도의 케이지에 포함되어야하는 짐승입니다. 포럼에서 제대로 작동하지 않았기 때문에 많은 불만이 있었고 현재 해결책은 현재 작업 공간에서 동등한 플러그인의 설정을 정리하는 것이 었습니다.

개인적으로, 플러그인의 현재 상태와 함께 제공되는 알려진 문제와 관련된 별도의 작업 공간과 관련하여 언어 구분에 더 의존하고 있음을 알았습니다. 프로젝트를 만들 때 좌절감을 줄이려면 최소한의 숫자를 유지하는 것이 바람직합니다. 마지막으로, 로딩 속도와 성능은 관련없는 프로젝트로 인해 많은 (필요하지 않은) 플러그인이로드되면 발생할 수있는 문제입니다. 결론; 모든 것에 대한 해결책은 하나도 없으며, 문제를 해결하는 마스터 블루 프린트도 없습니다. 경험과 함께 성장하는 것이지만 적을수록 좋습니다!

몇 년 동안 Eclipse를 사용해 왔지만이 "답변"은 추측 일뿐입니다 (오늘 밤에 시도 할 것입니다). 그것이 존재하지 않기 때문에 분명히 나는 ​​틀렸다.

Oracle은 CMake를 사용하여 MySQL Connector C 소스 코드에 대한 Visual Studio "솔루션"을 생성합니다. 솔루션 내에는 개별적으로 또는 집합 적으로 (솔루션에 의해) 컴파일 될 수있는 "프로젝트"가 있습니다. 각 프로젝트에는 자체 makefile이 있으며 솔루션의 일부를 다른 프로젝트와 다른 설정으로 컴파일합니다.

마찬가지로 Eclipse Workspace가 관련 makefile 프로젝트 (Eclipse)를 보유 할 수 있기를 기대합니다. 마스터 프로젝트는 종속성이 다양한 고유 makefile 프로젝트를 "솔루션"을 빌드하기위한 사전 요구 사항으로 컴파일합니다. 내 폴더 구조는 @Rafael이 설명하는 것과 같습니다.

따라서 Workspaces를 사용하는 좋은 방법은 다른 프로젝트를 솔루션으로 결합하는 Visual Studio의 기능을 모방 하는 것입니다.