Сколько «Проектов Eclipse» считается слишком большим для одного реального проекта разработки?

Question

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

ПРИМЕЧАНИЕ: Мой проект в настоящее время содержит более 25 различных проектов Eclipse.

Answer 1

Мое общее правило: я создам новый проект для каждого компонента многократного использования. Так, например, если у меня есть отдельные изолированные функции, которые можно упаковать, например, в jar-файл, я бы создал новый проект, чтобы я мог самостоятельно собирать, упаковывать и распространять компонент.

Кроме того, если есть определенные проекты, в которые вам не нужно вносить частые изменения, вы можете создавать их только при необходимости и держать их «закрытыми» в затмении, чтобы сэкономить время на индексации и т. Д. Даже если вы считаете, что определенный компонент не может быть повторно использован, если он отделен от остальной части кода с точки зрения логики / проблем, которые могут быть вам полезны, просто выделив его. Иногда, казалось бы, определенный код может быть многократно использован в другом проекте или в будущей версии того же проекта.

Answer 2

Если в вашем проекте есть , то много подпроектов или модулей, необходимых для фактического составления окончательного артефакта, тогда пришло время взглянуть на что-то вроде Maven и настроить многомодульный проект. Это a) позволит вам работать с каждым модулем независимо, не беспокоясь об идеях, и позволит легко настроить ваш ide (и другие IDE) с помощью цели mvn eclipse:eclipse. Кроме того, при создании всего проекта верхнего уровня maven сможет извлечь из списка зависимостей, которые вы описали, какие модули должны быть собраны в каком порядке.

Вот быстрая ссылка через google и al ink на книгу Maven: The Definition Guide , в которой все будет объяснено более подробно в главе 6 (как только вы освоите основы) ).

Это также приведет к тому, что ваш проект не будет явно привязан к Eclipse. Способность строить независимо от ide означает, что любой Джо Шмо может прийти и легко работать с вашей базой кода, используя любые инструменты, в которых он / она нуждается.

Answer 3

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

Я большой поклонник использования многих проектов, я чувствую, что это «разбивает» большие вещи помимо того, что я могу сделать с пакетами, и помогает мне ориентироваться и ориентироваться.

Конечно, если вы разрабатываете подключаемые модули Eclipse, все равно будет проектом.

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

Answer 4

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

Answer 5

Создание банок для проектов, в которых вы не часто работаете. Это должно значительно уменьшить беспорядок. Если вы часто работаете над всеми проектами, то можете добавить цели в свою сборку, которые будут объединять в единое целое соответствующие проекты для вас, что сведет все в один файл, который вы затем сможете включить в путь к классам.

Answer 6

Это сложный вопрос, и ответы на него варьируются от одного проекта затмения до одного проекта затмения для каждого класса.

Мой итог:

1. Вы можете иметь слишком мало проектов, и никогда не слишком много (конечно, используйте автоматизация, например mvn eclipse: затмение)
2. Использование -Declipse.useProjectReferences = истина / ложь при использовании maven для переключения рабочего пространства режим кстати баночка и проект Зависимости
3. Используйте плагин mvn release для генерации последовательные выпуски (автоматический увеличение версии)
4. Несколько проектов дает вам независимая версия, которая чрезвычайно важно. Например. один разработчик может работать над новой версией модуль, пока вы все еще зависит от предыдущий и ты в какой-то Дык решили обновить до более новой версия (возможно, путем увеличения его версии в разделе зависимостей pom.xml). Или в другом сценарии, если один Проект содержит ошибку, которую вы понижаете к предыдущей версии.
5. Несколько проектов заставляют задуматься об архитектуре больше, чем если у вас есть только пакеты.
6. Несколько проектов обычно делают архитектурные проблемы очевидны больше чем если бы у вас был только один проект. Любой хотел бы прокомментировать это?
7. Никогда не знаешь, проецируешь ли ты развивается в OSGI / SOA / EDA, где вы нужно разделение.
8. Даже если вы на 100% уверены, что вы проекты будут развернуты как одна банка по-старому в одном JVM, это до сих пор не болит (мвн сборка плагин) чтобы иметь многократное затмение проекты для логически независимых кусочки кода

Кстати, проект, над которым я работаю, разделен на 24 проекта Eclipse.

Answer 7

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

Answer 8

На прежнем месте работы всего приложения было более +170 проектов. Хотя редко нужно было проверять все проекты локально, даже 30-40 проектов, постоянно находящихся в нашей области, делали переиндексацию и т.д. очень медленными.

Answer 9

Черт, у нас больше 100. Проекты ничего не стоят.