Как организовать «проекты» и «решения» в Eclipse? - PullRequest
16 голосов
/ 26 сентября 2010

Мне сказали, что рабочее пространство Eclipse является эквивалентом решения Visual Studio. Но мне также сказали, что люди обычно используют одно рабочее пространство для всей своей работы. Верны ли эти явно противоречивые утверждения? Если да, то как нам создать и поддерживать эквивалент нескольких решений VS в Eclipse?

Во-вторых, в случае с VS я также проверяю файлы своего решения (.sln) в системе контроля версий. Соответственно, я должен или не должен проверять в папке .metadata рабочей области Eclipse?

Ответы [ 3 ]

10 голосов
/ 26 сентября 2010

Не думаю, что рабочее пространство Eclipse эквивалентно решению VS. В рабочем пространстве Eclipse хранится много метаинформации о проектах, их физическом расположении (возможно, внутри или вне папки рабочего пространства) и т. Д., А также даже параметры рабочего места. Не стоит загружать эту информацию в систему контроля версий, поскольку возможно, что другой разработчик использует другие физические местоположения для проектов и т. Д.

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

Другим способом является создание нескольких папок рабочего пространства, и вы можете использовать их в качестве альтернативы решениям. Недостаток этого подхода заключается в том, что если вы настраиваете IDE (например, с помощью «Предпочтений» или путем определения местоположений управления исходным кодом), эти настройки должны выполняться в каждой рабочей области. Эту проблему можно решить с помощью инструмента Workspace Mechanic (я не пробовал, но он может перенести эти настройки).

4 голосов
/ 26 сентября 2010

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

Eclipse ожидает, что открытые проекты связаны между собой.И при использовании менеджеров проектов, таких как Maven, один проект maven обычно делится на множество небольших проектов затмения.Лучше всего иметь отдельное рабочее пространство для проекта.Вторая причина заключается в том, что обычно вам нужно импортировать другой связанный проект, чтобы увидеть, как все делается, и это будет ужасный беспорядок, тогда как все это будет в одном рабочем пространстве.папка в источник контроля.Вы делаете только проекты внутри.Потому что вы и другие потом будете проверять проект только в своем рабочем пространстве.Но вопрос в том, следует ли вам фиксировать файл .project, потому что он персонализирован и затмевает конкретную версию, а такие вещи, как характер проекта (java, spring, maven nature и т. Д.), Может кто-нибудь настроить самостоятельно.Файлы .classpath в проекте должны быть зафиксированы в исходном элементе управления, поскольку они задают пути к классам, и его установка займет много времени.

1 голос
/ 10 мая 2015

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

...