Как организовать "проекты" и "решения" в Eclipse?
Мне сказали, что рабочее пространство Eclipse является эквивалентом решения Visual Studio. Но мне также сказали, что люди обычно используют одну рабочую область для всей своей работы. Правильны ли эти противоречивые утверждения? Если да, то как мы тогда создаем и поддерживаем эквивалент нескольких решений VS в Eclipse?
Во-вторых, в случае VS я также проверяю файлы своих решений (.sln) на исходный элемент управления. Соответственно, следует ли мне или мне не проверять папку рабочей области Eclipse.metadata?
Ответы
Ответ 1
Я не думаю, что рабочее пространство Eclipse эквивалентно решению VS. Рабочее пространство Eclipse хранит много метаинформации о проектах, их физическом местоположении (возможно, в папке рабочей области или за ее пределами) и т.д. И даже настройках рабочего места. Не рекомендуется загружать эту информацию в исходный контроль, так как возможно, что другой разработчик использует другие физические местоположения для проектов и т.д.
В Eclipse существует аналогичная концепция для решений (аналогичная, не эквивалентная): наборы проектов. Это всего лишь графический интерфейс для группировки ваших проектов в группы. Эти наборы не могут выполняться вместе и видны только в навигаторе проекта.
Другой способ - создать несколько папок рабочей области, и вы можете использовать их в качестве альтернативы решениям. Недостатком этого подхода является то, что при настройке среды IDE (например, с помощью настроек или путем определения местоположений управления версиями) эти настройки должны выполняться в каждой рабочей области. Эта проблема может быть решена с помощью инструмента Механизм рабочего пространства (я его не пробовал, но он может переносить эти настройки).
Ответ 2
Основная причина, по которой лучше для меня иметь отдельное рабочее пространство для одного проекта, это производительность и ясность. Со многими проектами в пределах одной рабочей области вам придется закрыть другие из-за общих классов классов для поддержки редактора. Редактор использует classpath всех проектов для поддержки контента, поиска иерархии классов и т.д.
Eclipse предполагает, что открытые проекты связаны. И при использовании менеджеров проектов, таких как Maven, один проект maven обычно делится на множество небольших проектов eclipse. Это просто лучшая практика иметь отдельное рабочее пространство для проекта. Вторая причина заключается в том, что обычно вам нужно импортировать другой связанный проект, чтобы увидеть, как все сделано, и это будет ужасный беспорядок, а затем все это в одном рабочем пространстве.
Вы определенно не должны фиксировать папку .metadata в исходном элементе управления. Вы выполняете только проекты внутри. Потому что вы и другие затем проверите проект только в своем собственном рабочем пространстве. Но возникает вопрос, следует ли вам перенести файл .project, потому что он персонализировал и затмевал версию, и что-то вроде природы проекта (java, spring, maven nature и т.д.) Может кто-нибудь настроить сам. Файлы .classpath в проекте должны быть привязаны к исходному элементу управления, поскольку они задают пути к классам, было бы очень много времени, чтобы снова настроить его.
Ответ 3
Вы можете группировать свои проекты в разных рабочих местах или в определенной рабочей области. Non может быть вредным, если вы правильно управляете своими настройками.
