Разделить Java-проект по зависимости build.xml - PullRequest
0 голосов
/ 17 мая 2011

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

EDIT:

Я обнаружил файлы Manifest * .MF, связанные с каждым файлом сборки, в которых указаны Main-Class и Class-Path. Из Class-Path я могу определить, какие JAR-файлы необходимы для каждого нового проекта. Это оба приложения, которые запускают только свои соответствующие основные классы, поэтому, если я определяю зависимые классы основного класса, я определяю классы, которые мне нужны в новом проекте.

Вот мой текущий план для этого:

  1. Скопируйте старый проект в новый проект
  2. Удалите неиспользуемые файлы сборки, файлы MANIFEST * .MF и неиспользуемые файлы JAR на основе манифеста
  3. Удалить неиспользуемые основные файлы на основе манифеста
  4. Используйте встроенную функциональность IntelliJ, чтобы вручную просматривать файлы и методы, проверять, есть ли на них ссылки в любом месте, и удалять их 1 на 1, если это не так.

Полагаю, шаг 4 можно улучшить ...

UPDATE:

Я уже закончил разделять свои проекты. В итоге я использовал IntelliJ «Анализ зависимостей ...» (в 10.0.3 он находится в меню «Анализ»). Для тех из вас, у кого есть этот инструмент, он ищет только зависимости на 1 глубину по умолчанию, поэтому помните об этом и при необходимости установите большую глубину. Затем вы можете выделить основные классы, и он покажет вам все файлы, от которых зависят эти классы, до заданной вами глубины. В моем случае один из основных файлов одного подпроекта ссылался на основной файл другого подпроекта, поэтому, удалив эту одну зависимость, я смог удалить более 65 файлов в качестве зависимостей.

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

1 Ответ

1 голос
/ 17 мая 2011
  • Зависимости:
    Вы можете создать 2 проекта, каждый из которых ссылается на все исходные фляги (зависимости) исходного проекта.На данный момент вы имеете в виду некоторые ненужные банки в обоих проектах.Затем вы можете использовать инструменты, предложенные здесь , чтобы обнаружить эти ненужные файлы jar и удалить их в каждом проекте.

  • Ресурсы (например, файлы конфигурации xml):
    Возможно, естьЕсть какие-то инструменты, но я не знаю.Надеюсь, у вас не так много конфигурационных файлов и т. Д., И если это так, ручное копирование, вероятно, самый быстрый способ.

...