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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой итог:

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

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