Eclipse Workspaces: зачем и почему?

133

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

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

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

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

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

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

eclipse workspace е-мотив
источник
14
Я до сих пор не понимаю. Очевидно, это имеет смысл для людей, которые уже знают, для чего , и им трудно понять, что это не очевидно для всех остальных.
Рафаэль Эйнг
Я тоже не понимаю, и я не согласен со всем ниже *, а также не является полным (без ссылок). Почему я еще не принял ответ. * Конечно, там, где это не мнение или личная практика. Я понял.
e-motiv
Я попытался ответить на него, это не очень хороший ответ, но я думаю, что смогу развить его,
Рафаэль Эйнг

Ответы:

43

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

Что это

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

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

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

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

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

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

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

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

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

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

  1. некоторые настройки для самого 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

Рафаэль Эйнг
источник
1
Я признаю, что последний раздел нуждается в пояснениях. Что такое подпроект, если не сам проект? Как эти подпроекты компенсируют использование в разных рабочих областях без использования всего родительского проекта? Сначала мне нужно выяснить это, чтобы улучшить ответ.
Рафаэль Эйнг
2
Этот ответ вносит свой вклад в весь вопрос. Тем не менее, он немного ориентирован на папку, а также пропускает некоторые ссылки и аргументы. Тем не менее, это информативно. Вздох, эти ответы становятся трудными, так как все они вносят свой вклад, и я начинаю думать, что никогда не смогу принять один ответ. Надеюсь, здесь никто не фанат, и мы оставим это без принятого ответа?
e-motiv
Привет @ RU-Bn. Я не заинтересован в этом. Я просто хотел бы объяснить, что такое рабочая область Eclipse, чтобы быть уверенным, что я ее знаю.
Рафаэль Эйнг 06
Эй, я не имел в виду этот последний вопрос ни к кому конкретно. Это было в общем. Возможно я должен был написать это как комментарий сверху.
электронный мотив
@ RU-Bn, конечно, я не воспринял это неправильно. Может, я просто плохо себя выразил.
Рафаэль Эйнг 09
37

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

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

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

Дункан Кребс
источник
1
Но спасибо за ответ. Это имеет смысл, и, по крайней мере, я знаю, как это должно быть. Не могли бы вы побаловать меня более подробной информацией и, возможно, ссылкой (на eclipse) о вашем первом предложении?
e-мотив
5
Я не согласен с тем, что «суть рабочего пространства состоит в том, чтобы сгруппировать набор связанных проектов вместе, которые обычно составляют приложение». Предположим, я разрабатываю два приложения. Должно ли у меня быть два рабочих пространства? Как раздражает! Все настраиваемые перспективы, привязки клавиш, автотекст и другие настройки привязаны к рабочей области. Мне придется воссоздавать их каждый раз, когда я начинаю новое приложение! На мой взгляд, у вас должно быть два рабочих пространства: dev и последний выпущенный. В рабочей области вы создаете РАБОЧИЙ НАБОР для каждого приложения. Вот как предполагается использовать рабочие пространства и рабочие наборы.
Джон Хенкель
2
Джон, что вы делаете, если в вашей рабочей области два приложения, например, приложения RCP, для каждого из которых требуется разная целевая платформа или другой уровень соответствия компилятору java Если ваши приложения не требуют одинаковой конфигурации во время выполнения, в результате чего два приложения находятся в одно рабочее пространство вызовет проблемы. Я понимаю, что у вас есть общий набор предпочтений, которые вы хотите использовать, поэтому есть функция экспорта / импорта предпочтений, чтобы вы могли настраивать новые рабочие пространства и импортировать свои организации или личные предпочтения и другие настройки.
Дункан Кребс
1
Интересный момент @JohnHenckel! Хотя с рабочими наборами у меня были проблемы. Кажется, они работают только с некоторыми функциями eclipse, хотя я думаю, вы все можете установить их вручную (как я сделал вчера с представлением задач, которое дало мне все задачи из всех проектов). Можете ли вы сделать то же самое для библиотечных функций, автозаполнения, существующих методов и т. Д.? Меня также интересует, как вы используете рабочие наборы. @DuncanKrebs, я не знал функции импорта / экспорта настроек. Спасибо! Это решает большую часть того, как использовать рабочие пространства. Спасибо вам обоим. И не переставайте приводить аргументы / идеи!
E-мотив
1
Я только что перешел на затмение. Раньше я использовал новую концепцию операционной системы, называемую «папкой». Папка - это место в моей файловой системе, где я размещаю проект. Он может иметь подпапки оттуда. Вы даже можете поместить несколько папок связанных проектов в одну родительскую папку. Итак, что бы я делал без Eclipse? Я бы использовал папку, простой текстовый редактор, а также компилировал и запускал из командной строки. Итак, ваш ответ, похоже, предполагает, что мы все должны просто знать, насколько полезны «рабочие пространства», но, возможно, вам следует ознакомиться с «папкой».
Габриэль Стейплз
3

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

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

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

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

Лазарос Космидис
источник
Что вы подразумеваете под DTLK?
Когда вы отказались от текстового редактора в пользу IDE, исходный диск - это удобство автозаполнения и просмотр ваших библиотек (и документов), чтобы, по крайней мере, избежать синтаксических ошибок. Ни при каких обстоятельствах вы не поставите под угрозу эту функциональность.
Лазарос Космидис
1

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

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

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

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

pbyhistorian
источник