이클립스 워크스페이스:무엇 때문에 그리고 왜?

이클립스 워크스페이스:무엇 때문에 그리고 왜?

Workspaces를 사용하는 다양한 방법(프로젝트별, 애플리케이션별(다중 자산화 여부에 관계없이), 프로그램 언어별, 대상별(웹 개발, 플러그인 등)을 보고 읽고 생각해 보았는데, 여전히 최선의 접근 방식이 무엇인지 의문입니다.

이것에 대해 페이지 길이가 아닌 상세한 통찰력을 줄 수 있는 사람이 있습니까?

예를 들어, 여기에는 많은 하위 질문이 포함되어 있으며, Eclipse(및 Workspaces)의 모든 측면을 알지 못하기 때문에 제가 물어봐야 할 모든 하위 질문을 알지 못하지만, 제가 찾고 있는 것에 대한 예를 들어보겠습니다.

• 뭐 때문이지요?
• Eclipse 개발팀은 이 제품이 무엇에 사용될 것으로 예상했습니까?
  • 다른/대부분의 사람들은 어떻게 생각합니까?
  • 당신은 어떻게 생각하나요?
  • ... ?
• 왜요?
• 구성 충돌과 장점 공유가 있습니까?
• 파일 공간에 대한 이유는 무엇입니까?
• 퍼포먼스?
• ... ?

저는 한 프로젝트에서 반드시 모든 언어와 프로토콜을 사용하는 것은 아니지만 다른 언어와 프로토콜을 사용하는 개발자의 최소 사용 사례에 대해 말하고 있습니다(예: 일부 프로젝트의 경우 Pphp, Javascript 및 XML, 다른 프로젝트의 경우 C#, 다른 프로젝트의 경우 Java 및 SQL 등).

2012-11-27 편집: 오해하지 마세요.저는 워크스페이스의 사용을 의심하지 않습니다. 저는 그냥 원래대로 사용하거나 다른 사람이 더 좋게 생각한다면 사용하고 싶습니다.그래서 "무엇을 위해?"는 다음을 의미합니다.무엇이 가장 좋은 용도입니까?그리고 "왜?"는 실제로 "무엇 때문에?"를 목표로 합니다. 다시 말해, 당신의 대답에 대한 이유를 말해주세요.

자바 세계에서 매우 불편함을 느끼는 사람에 대한 저의 비전을 제시하겠습니다. 이것도 여러분의 경우라고 생각합니다.

그것이 무엇인지

워크스페이스는 함께 그룹화하는 개념입니다.

1. 일련의 관련 프로젝트
2. 이 모든 프로젝트와 관련된 일부 구성
3. Eclipse 자체에 대한 일부 설정

이 작업은 디렉토리를 만들고 디렉토리 안에 이러한 정보를 Eclipse에 알려주는 파일을 넣음으로써 수행됩니다.명시적으로 파일을 저장할 폴더를 선택하기만 하면 됩니다.그리고 이 폴더는 소스 코드를 넣는 곳과 같을 필요가 없습니다. 우선적으로 그렇지 않습니다.

위의 각 항목 탐색:

1. 일련의 관련 프로젝트

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

이것은 프로젝트 소스 코드가 작업 영역 내에 있어야 한다는 것을 의미하지 않습니다.워크스페이스는 디스크에 있는 프로젝트의 물리적 경로와 관련이 있습니다(방법을 아는 사람?).작업 공간 내부에서 프로젝트 경로를 가리키는 일부 파일을 검색했지만 성공하지 못했습니다.

이렇게 하면 프로젝트가 한 번에 두 개 이상의 작업 공간 안에 있을 수 있습니다.따라서 작업 공간과 소스 코드를 분리하는 것이 좋습니다.

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

자바 컴파일러 버전(예: 1.7)과 같은 것이 작업 공간 수준의 구성이라고 들었습니다.워크스페이스 내에 여러 프로젝트가 있고 Eclipse 내에 컴파일하면 모든 프로젝트가 동일한 Java 컴파일러로 컴파일됩니다.

3. Eclipse 자체에 대한 일부 설정

키 바인딩과 같은 일부 항목은 작업 공간 수준에서도 저장됩니다.따라서 ctrl+탭이 탭을 쌓지 않고 스마트하게 전환하도록 정의하면 탭은 현재 작업영역에만 바인딩됩니다.다른 작업 공간에서 동일한 키 바인딩을 사용하려면(원하는 것 같습니다!) 작업 공간 간에 키 바인딩을 내보내거나 가져와야 합니다(만약 그렇다면 이 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 도구입니다.

말이 안 되는 경우 NetBeans 또는 Visual Studio에서 이 문제를 해결하는 방법을 물어보십시오.같은 주제입니다.메이븐이 좋은 예입니다. 관련 메이븐 프로젝트 그룹을 워크스페이스로 체크아웃하면 실시간으로 오류를 개발하고 볼 수 있습니다.작업 공간이 아니라면 무엇을 더 제안하시겠습니까?RCP 애플리케이션은 용도에 따라 다른 용도로 사용될 수 있지만, 진정한 IDE 의미에서는 작업 공간이나 프로젝트 컨텍스트보다 더 나은 솔루션이 무엇인지 모르겠습니다.내 생각뿐이야 - 던컨

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

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

그리고 두 번째(2차적) 개발 전략을 채택할 수 있습니다.기본 범위가 충족되고(숙여됨) 프로젝트 관계에 대한 추가 조정이 필요한 경우(라이브러리, 관점 cr 등), 개발 습관 또는 가능한 언어/프레임워크 "행동"에 따라 별도의 작업 공간을 시작하는 것이 적절할 수 있습니다.예를 들어 DLTK는 별도의 케이지에 포함되어야 하는 짐승입니다.포럼에서 작동이 중단되거나 전혀 작동하지 않는다는 불만이 많이 제기되고 있으며, 제안된 해결책은 현재 작업 공간에서 해당 플러그인의 설정을 정리하는 것이었습니다.

개인적으로, 저는 플러그인의 현재 상태와 관련된 알려진 문제와 관련된 별도의 작업 공간과 관련하여 언어 구별에 더 기울어 있다는 것을 알게 되었습니다.프로젝트가 진행될 때 좌절감이 덜하기 때문에 최소한으로 유지하는 것이 좋습니다.풍부한 버전과 버전 제어만이 프로젝트를 유지하는 유일한 버전은 아닙니다.마지막으로 로드 속도와 성능은 관련이 없는 프로젝트로 인해 많은 (불필요한) 플러그인이 로드되는 경우 발생할 수 있는 문제입니다.중요한 것은 모든 문제를 해결할 수 있는 해결책이 하나도 없고, 문제를 해결할 수 있는 마스터 Blueprint도 없다는 것입니다.경험과 함께 성장하는 것이지만, 적은 것이 더 많습니다!

수년 동안 Eclipse를 사용했지만, 이 "답변"은 추측일 뿐입니다(오늘 밤 시도해 보겠습니다).만약 그것이 존재하지 않는 것으로 투표된다면, 분명히 제가 틀렸습니다.

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

마찬가지로, 저는 이클립스 워크스페이스가 다양한 고유한 메이크파일 프로젝트를 "솔루션" 구축의 전제 조건으로 컴파일하는 마스터 프로젝트와 관련된 메이크파일 프로젝트(이클립스)를 보유할 수 있기를 바랍니다.(내 폴더 구조는 @Rafael이 설명하는 것과 같습니다.)

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

프로젝트를 구성하기 위한 기능일 뿐입니다.Eclipse 설계자들은 Eclipse에 대한 글로벌 설정을 피하려고 노력했고 작업 공간에 배치하기로 결정했습니다.각 Eclipse 앱은 각 작업 공간 설정에 따라 달라집니다.그것은 좋은 결정입니까?아닌 것 같아요.유연성이 부족합니다.글로벌 설정을 피할 수 있다고 기대한 것은 순진한 것이었습니다.단일 프로젝트를 가질 수 없습니다(이클립스 디자이너에게는 놀라운 일이 될 수 있지만 꽤 자주 발생합니다).하지만 여전히 작동합니다.많은 사람들이 그것을 사용합니다.때때로 그들은 고통받지만 더 자주 모든 것이 괜찮습니다.

언급URL : https://stackoverflow.com/questions/13552266/eclipse-workspaces-what-for-and-why