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

Во всяком случае, можете ли вы подробно разобраться в этом, но не на всю страницу?

Это включает в себя множество подвопросов, так сказать, и я не знаю всех конкретных подвопросов, которые я должен задать, потому что я не уверен, что не знаю всех аспектов затмения (и рабочих пространств), но Попробую привести пример того, что ищу:

• Зачем?
  
  • Что означало, что разработка Eclipse должна была использоваться?
  • Что думают другие / большинство людей?
  • Что вы думаете?
  • ...?
• Зачем?
  
  • Существуют ли конфликты конфигурации и совместное использование достоинств?
  • Какие-либо причины файлового пространства?
  • Производительность?
  • ...?

О, и я говорю о минимальном сценарии использования для разработчика, который использует разные языки и протоколы, и НЕ обязательно все из них в одном проекте (например, php, javascript и xml для некоторых проектов, C # для других, java и SQL для еще другие и т. д.)

Редактировать 2012-11-27: не поймите меня неправильно. Я не сомневаюсь в использовании рабочих пространств, я просто хочу использовать его так, как оно должно быть, или иначе, если кто-то посчитает это лучше. Так "зачем?" означает: что лучше всего использовать? И почему?" на самом деле нацеливается на «зачем?», другими словами: скажите мне причины вашего ответа.

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

Что это

Рабочая область - это концепция группировки:

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

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

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

1. набор (каким-то образом) связанных проектов

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

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

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

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

Я слышал, что что-то, например, версия компилятора Java (например, 1.7, например, - я не знаю, является ли слово «версия» здесь словом), является конфигурацией уровня рабочей области. Если у вас есть несколько проектов в вашей рабочей области, и вы скомпилируете их внутри 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плагину, и, естественно, по дизайну имеет смысл.

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

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

Обычно объем рабочего пространства (-ей) делится на две части.

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

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

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

Хотя я использовал Eclipse в течение многих лет, этот «ответ» - только предположение (которое я собираюсь попробовать сегодня вечером). Если за это проголосуют за существование, то, очевидно, я ошибаюсь.

Oracle использует CMake для создания «решения» Visual Studio для своего исходного кода MySQL Connector C. В рамках Решения находятся «Проекты», которые могут быть скомпилированы индивидуально или коллективно (Решением). Каждый проект имеет свой собственный make-файл, компилирующий свою часть решения с настройками, которые отличаются от других проектов.

Точно так же я надеюсь, что рабочая область Eclipse может содержать мои связанные проекты make-файла (Eclipse) с основным проектом, зависимости которого компилируют различные проекты с уникальным make-файлом в качестве предварительных условий для создания его «решения». (Моя структура папок будет такой, как описывает @Rafael).

Поэтому я надеюсь, что хорошим способом использования Workspaces будет эмуляция способности Visual Studio объединять разнородные проекты в решение.