Ответ 1

Весь смысл рабочей области состоит в объединении набора связанных проектов, которые обычно составляют приложение. Рамка рабочего пространства сводится к плагину eclipse.core.resources, и, естественно, дизайн имеет смысл.

Проекты имеют натуру, строители привязаны к конкретным проектам и при изменении ресурсов в одном проекте вы можете видеть в компиляции в реальном времени или других проблемах в проектах, находящихся в одном и том же рабочем пространстве. Таким образом, стратегия, которую я предлагаю, имеет разные рабочие области для разных проектов, над которыми вы работаете, но без рабочей области в eclipse не было бы понятия коллекции проектов и конфигураций, и в конце концов это инструмент IDE.

Если нет смысла спрашивать, как Net Beans или Visual Studio обращается к этому? Это та же тема. Maven - хороший пример, проверка группы связанных проектов maven в рабочей области позволяет вам разрабатывать и видеть ошибки в реальном времени. Если бы не рабочее пространство, что бы вы предложили? Приложение RCP может быть другим зверем в зависимости от того, для чего оно используется, но в истинном смысле IDE. Я не знаю, что было бы лучшим решением, чем рабочее пространство или контекст проектов. Просто мои мысли. - Дункан

Ответ 2

Я предоставлю вам свое видение того, кто чувствует себя очень неудобно в мире Java, который, как я полагаю, тоже ваш случай.

Что это такое

Рабочее пространство представляет собой концепцию группировки:

• набор (как-то) связанных проектов
• некоторая конфигурация, относящаяся ко всем этим проектам
• некоторые настройки для самого Eclipse

Это происходит, создавая каталог и помещая его в него (вам не нужно это делать, это сделано для вас) файлы, которым удается сообщить Eclipse эти данные. Все, что вам нужно сделать, это выбрать папку, в которую будут помещаться эти файлы. И эта папка не обязательно должна быть одинаковой, если вы поместите свой исходный код - предпочтительнее этого не будет.

Изучение каждого элемента выше:

• набор (как-то) связанных проектов

Кажется, что Eclipse всегда открывается в связи с определенным рабочим пространством, то есть, если вы находитесь в рабочей области A и решили переключиться на рабочую область B (File > Switch Workspaces), Eclipse закроется и снова откроется. Все проекты, связанные с рабочей областью A (и появляющиеся в Project Explorer) больше не появятся, и теперь появятся проекты, связанные с рабочей областью B. Таким образом, кажется, что проект, открытый в Eclipse, ДОЛЖЕН быть связан с рабочей областью.

Обратите внимание, что это не означает, что исходный код проекта должен находиться внутри рабочей области. Рабочее пространство каким-то образом будет иметь отношение к физическому пути ваших проектов на вашем диске (кто-нибудь знает, как? Я заглянул в рабочую область, ища какой-то файл, указывающий на пути к проектам, без успеха).

Таким образом, проект может находиться внутри более чем одного рабочего пространства за раз. Таким образом, кажется хорошим сохранить рабочее пространство и исходный код.

2. некоторая конфигурация, относящаяся ко всем этим проектам

Я слышал, что что-то вроде версии компилятора Java (например, 1,7, например, я не знаю, является ли здесь "версия" ), это конфигурация уровня рабочей области. Если у вас есть несколько проектов внутри вашей рабочей области и скомпилировать их внутри Eclipse, все они будут скомпилированы с одним и тем же компилятором Java.

3. некоторые настройки для самого Eclipse

Некоторые вещи, такие как ваши привязки клавиш, также хранятся на уровне рабочей области. Итак, если вы определяете, что вкладка ctrl + будет переключаться на вкладки интеллектуальным способом (не укладывая их в стек), это будет привязано только к вашей текущей рабочей области. Если вы хотите использовать ту же привязку клавиш в другой рабочей области (и я думаю, что вы хотите!), Кажется, что вам нужно экспортировать/импортировать их между рабочими пространствами (если это правда, эта IDE была построена поверх некоторых действительно странных помещений). Вот ссылка на это.

Также кажется, что рабочие пространства не обязательно совместимы между различными версиями Eclipse. В этой статье указано, что вы называете свои рабочие пространства, содержащие имя версии Eclipse.

И, что более важно, как только вы выбираете папку для своего рабочего пространства, не прикасайтесь ни к одному файлу внутри, либо у вас есть какие-то проблемы.

Как я думаю, это хороший способ использовать его

(на самом деле, поскольку я пишу это, я не знаю, как использовать это в хорошем смысле, поэтому я искал ответ, который я пытаюсь собрать здесь)

• Создайте папку для своих проектов:
  /projects

• Создайте папку для каждого проекта и сгруппируйте подпроекты проектов внутри нее:
  /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

• Создайте отдельную папку для ваших рабочих областей:
  /eclipse-workspaces

• Создайте рабочие пространства для своих проектов:
  /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Ответ 3

В основном область рабочего пространства разделена на две точки.

Первая точка (и первичная) - это затмение сама и связано с настройками и настройками метаданных (плагин ctr). Каждый раз, когда вы создаете проект, eclipse собирает все конфигурации и сохраняет их в этой рабочей области, и если каким-то образом в одном и том же рабочем пространстве присутствует конфликтный проект, вы можете потерять некоторые функциональные возможности или даже стабильность его затмения.

И второй (вторичный) момент стратегии развития, который можно принять. После того, как основной охват будет выполнен (и освоен), и для дальнейших корректировок в отношении отношений проекта (например, библиотеки, перспективы ctr) потребуется инициировать отдельное рабочее пространство (-ы), основанное на привычках развития или возможных "поведениях" языка/фреймворка. DLTK для примеров - это зверь, который должен содержаться в отдельной клетке. Множество жалоб на форумах для него перестало работать (правильно или вообще не было), и предлагаемое решение состояло в том, чтобы очистить настройки эквивалентного плагина от текущей рабочей области.

Лично я обнаружил, что я больше склоняюсь к языковому различию, когда речь идет о отдельных рабочих пространствах, которые имеют отношение к известным проблемам, которые возникают с текущим состоянием плагинов. Я предпочитаю хранить их в минимальных количествах, поскольку это приводит к меньшему разочарованию, когда проекты становятся... много и контроль версий - это не единственная версия, которую вы держите в своих проектах. Наконец, скорость загрузки и производительность - это проблема, которая может возникнуть, если загрузится много (ненужных) плагинов из-за появления нерелевантных проектов. Нижняя линия; нет ни одного решения для каждого, ни одного синего шрифта, который решает проблему. Это то, что растет с опытом, Меньше, хотя!