Eclipse: следует ли создавать рабочее пространство для каждого проекта?


80

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

Единственные проблемы, которые я заметил до сих пор, - это экспорт JAR, у меня есть возможность включать исходные файлы из других проектов, что, похоже, может стать беспорядочным.


Я обнаружил, что для меня хорошо использовать рабочее пространство для каждой ветки исходного кода. Если вам нужно, чтобы в одной ветке было несколько мест, было бы полезно разместить их в разных рабочих областях.
Thorbjørn Ravn Andersen

Ответы:


29

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

Поскольку каждый проект может иметь несколько рабочих наборов, а рабочий набор окон может быть любой комбинацией рабочих наборов, таким способом довольно легко увидеть только то, что вы хотите в любой момент времени.


Если бы это был я, я бы выбрал этот ответ как правильный. Так легко просто отфильтровать вещи, используя рабочие наборы окон, ничего не ломая и не создавая рабочие пространства здесь и там. Это поможет вам увидеть только актуальные проекты и сосредоточиться только на том, что вам нужно.
Steelmonkey 01

28

Я создаю рабочие пространства Eclipse вокруг продуктов, потому что для меня продукт может иметь несколько проектов внутри них, например, когда основные библиотеки скомпилированы в одну банку в проекте, это используется другими проектами.

Что касается производственной среды, вам нужно, чтобы продукты работали в разных структурах каталогов, и в этом случае они были бы намного чище. А в eclipse рабочая область создает каталог с именем рабочей области. Итак, создавайте рабочие пространства на основе продукта / приложения, а не одного или нескольких проектов внутри них.


1
Вы добавляете все рабочее пространство в систему управления версиями в качестве одного корневого начального импорта / возврата?
Zombies

4
Обычно мы не добавляем рабочие области или файлы проекта eclipse в систему управления версиями, а добавляем только код проекта и ресурсы. Цель здесь в том, чтобы до тех пор, пока исходный код компилируется и работает в системе ночной сборки, разработчик может настраивать свое рабочее пространство по своему усмотрению.
omermuhammed

1
А что насчет обновления Eclipse? Вы создаете новое рабочее пространство и импортируете проект? (Может быть, это должен быть новый вопрос ...) Я спрашиваю, потому что у меня возникли проблемы после обновления с Indigo, Helio, Juno, теперь Kepler, и поэтому создайте новое рабочее пространство для каждого. Очень неудобно.
dfdumaresq

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

6

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

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


6

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


3

Я бы использовал отдельные рабочие области для разных «групп» проектов. Например, вы можете объединить основной проект приложения и проект модульного тестирования в одной рабочей области.


Интересно ... Я фактически поместил исходную папку модульного теста в тот же проект.
Zombies

@Zombies: Например, у меня есть проект Android и проект Android Test в одной рабочей области. Для тестового проекта просто нужна ссылка на реальное приложение.
Брайан Денни

3

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


Хорошая мысль, я рискую все таким образом испортить. Это почти как живая дышащая экосистема кода.
Zombies

2
Вы используете контроль версий, не так ли?
meriton

Может быть, для некоторых подойдет. Широкополосная связь в Австралии на десять лет отстает от «развитого» мира ...
Джон,

6
Для контроля версий вам не нужен доступ в Интернет, особенно если вы используете какую-то распределенную систему, например git или mercurial.
Плохой сектор

3

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

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

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


1
Это и мой подход. У меня есть только одно рабочее пространство для всех моих Java-проектов. Некоторые из них зависят от других проектов, так что это удобно, и у меня есть рабочие наборы для каждого из них. Тем не менее, я обычно закрываю те, с которыми не работаю активно - это делает вещи более управляемыми.
elduff

3

У нас есть ситуация, когда у нас есть несколько проектов, некоторые в ветвях, что, откровенно говоря, слишком непрактично, чтобы держать в одном рабочем пространстве, - а рабочие наборы - это шутка. К сожалению. Также при наличии открытых проектов, которые вы не используете, их можно случайно выбрать из меню завершения и т. Д. Вероятность ошибок.

По-настоящему отличной функцией для нас стало добавление Team -> Project Sets (я считаю, в Eclipse 3.3), поскольку это позволило нам иметь один файл, описывающий множество проектов, составляющих все приложение, который можно импортировать в Eclipse с помощью Team -> Импорт. Нужен данный проект? Извлеките его из CVS, найдите внутри него файл projectSet.psf и импортируйте ЭТО.

Это доказало, что у нас это хорошо работает.


Обратите внимание, что с тех пор мы перешли на maven, что значительно упрощает управление несколькими взаимосвязанными проектами.
Торбьёрн Равн Андерсен

3

У меня есть одно рабочее пространство для каждого типа проекта. Пример: обычная Java, веб-приложение, Python и т. Д.

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


2

У меня все свои проекты в одной рабочей области, и я использую рабочие наборы для управления ими.


1

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


1

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


В OSX любой пакет приложений, открытый с помощью команды open (как это делает Finder), разрешит только один запущенный экземпляр. Однако при запуске из командной строки Eclipse.app/Contents/MacOS/eclipse вы можете запустить несколько копий
мммммм

1

Мне нравится использовать несколько отдельных рабочих пространств (которые различаются в зависимости от типа проекта), которые импортируют проекты из разных мест. Легко перемещать вещи, не создавая тонны похожих рабочих мест. Хорошо работает и с моим SCM.


1

Зависит от того, над сколькими проектами вы работаете? Если вы работаете над несколькими проектами, я бы использовал одно и то же рабочее пространство, потому что, если вы используете несколько, вы легко можете забыть, что где и что, по крайней мере, может быть неприятно. Однако я всегда использую разное рабочее пространство для разных языков программирования, поэтому его менее запутать, когда вы находитесь в рабочем пространстве JAVA, вы думаете, что JAVA: D

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.