Как настроить общую исходную папку для 3 проектов (модулей) в IntelliJ IDEA?

#actionscript-3 #intellij-idea #flash-builder #shared-libraries #multiple-projects

#actionscript-3 #intellij-idea #flash-builder #общие библиотеки #несколько проектов

Вопрос:

У меня была такая настройка проекта в Adobe Flash Builder: (попытался проиллюстрировать это как можно лучше)

введите описание изображения здесь

По сути, GameProj и TitleProj компилируются в свои собственные SWFS. У каждого из них есть своя конкретная исходная папка (src-nameofproject), а также ссылка на общую папку, используемую LoaderProj.

Кроме того, GameProj также ссылается на некоторые классы в TitleProj, поэтому он также связывает исходный путь с собственной исходной папкой Title (в данном случае src-title).

Затем LoaderProj настраивается так, чтобы он «встраивал» gameproj.swf и titleproj.swf в виде байтовых массивов, которые он загружает во время выполнения (с Loader.loadBytes() помощью)

Но теперь мне интересно, как я могу настроить этот сложный сценарий с несколькими проектами в IntelliJ IDEA?

Я попытался импортировать рабочую область Flash Builder в IntelliJ, но когда я пытаюсь настроить параметры структуры проекта, он продолжает сообщать мне о конфликтах исходных папок между модулями.

Как я могу это обойти? Как я могу скомпилировать ее таким же образом?

Комментарии:

1. вы читали это: jetbrains.com/idea/webhelp /… ?

2. У меня также была похожая проблема, когда я переключился с Flash Builder на IntelliJ, решаемая путем добавления нескольких модулей в один и тот же проект (Файл-> Новый модуль, модуль импорта) или просто добавления нескольких конфигураций сборки.

Ответ №1:

Извините, это не фактический ответ на ваш вопрос, а скорее переформулировка вашей проблемы: я на самом деле не вижу причин для компиляции двух разных swf-файлов и встраивания их в третий, если LoaderProj.swf действительно является единственным swf-файлом, который вы используете в конце?

Включая одни и те же исходные папки src, src-title в несколько swf-файлов, вы перекомпилируете 2 или 3 раза одни и те же классы. Это стоит вам больше времени компиляции, больше компиляций (3 вызова) и более сложный проект, больший размер в конечном swf-файле, несколько определений одних и тех же классов, которые могут быть не синхронизированы, если вам когда-нибудь случится внедрить старую версию вложенных swf-файлов, и это может переопределить или не переопределить кореньопределения swf в зависимости от ApplicationDomain, в который вы загружаете вложенные swfs.

Кроме того, вы добавляете накладные расходы на декодирование swf во время выполнения при загрузке встроенного swf из bytearrays и занятие памяти для дублированных определений общих классов.

Я бы предпочел упростить и напрямую скомпилировать LoaderProj.swf со всеми исходными папками и заменить Loader.loadBytes() простыми экземплярами. new GameProjMainClass; или new TitleProjMainClass; (замените фактическими текущими основными классами ваших подпроектов)

настройка нескольких swf-файлов могла бы быть актуальной, если бы они не были встроены в один и тот же конечный swf-файл и загружались по требованию, но здесь, похоже, вы получаете худшее из обоих миров (встраивание одного swf-файла во все, что вам нужно, против динамической загрузки swf)

Комментарии:

1. Да, я согласен на 100% с вашими предложениями. Просто я не могу начать изменять способ настройки проектов (даже если это означает придерживаться дрянного варианта).). Я думаю, что причина индивидуально скомпилированных SWF-файлов и скомпилированного в них избыточного байт-кода исходного пути заключается в том, что каждый SWF-файл можно тестировать индивидуально (и быстрее), вместо того, чтобы каждый раз запускать игру с экрана заголовка.

2. Я понимаю, что это может быть связано с какой-то статической переменной или быстрой заменой перед запуском игры, чтобы сказать «currentGameState = новая игра», и как только все это будет протестировано, сбросьте его обратно на «новый TitleScreen». Но нам не так повезло с нашей настройкой! 🙁