gwt несколько модулей без избыточного кода

Question

Я пытаюсь найти способ избавить избыточную компиляцию и js от кода GWT клиента. Проблема в том, что у них есть несколько сайтов EntryPoint и массивная модель, которая компилируется для каждого модуля. Мы говорим о 30 модулях GWT и точках входа, каждый из которых компилирует весь пакет модели приложения отдельно. На мой 8-ядерный монстр требуется около 15 минут, чтобы GWT скомпилировать этого зверя. И да, компиляция параллельна и использует все ядра (вряд ли может перемещать мышь в Ubuntu :))

Чтобы изменить архитектуру на один модуль, на самом деле это не вариант. Не существует способа совместного использования унаследований между модулями? Модули не обязательно такие большие, но проблема в том, что все наследования скомпилированы избыточно для каждого модуля. Это, конечно же, имеет негативные последствия для конечного пользователя, так как каждая страница в основном должна загружать всю модель-js снова и снова.

Согласно

http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevGuideModuleXml

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

Любые советы высоко оценены!

Answer 1

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

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

Вы можете использовать code-splitting, поэтому ваши модули будут EntryPoints вместо RunAsyncCallbacks, и каждый модуль будет скомпилирован в один фрагмент js, который будет загружен асинхронно.

Обратите внимание, что вы будете включать один и тот же фрагмент javascript на всех страницах, и это будет загружать другие фрагменты в зависимости от страницы.

Преимущества этого решения много:

• У вас есть только один процесс компиляции. Это может занять много времени, но наверняка потребуется меньше, чем компиляция всех модулей отдельно, поскольку избыточный код будет скомпилирован один раз.
• Вы можете поддерживать различные .gwt.xml, один для продолжения разработки отдельных модулей со своим собственным EntryPoint, а другой без EntryPoint, который будет наследоваться вашим супермодулем.
• После компиляции первый фрагмент, загруженный (общий для всех приложений), будет очень маленьким, и он будет кэшироваться только один раз, поэтому все приложения будут загружаться очень быстро.
• Многие из кода, разделяемого модулями (gwt-core, jre и т. Д.), Могут перейти к первому фрагменту и будут использоваться всеми модулями, уменьшая конечный загруженный размер каждого приложения.
• Это готовое решение, gwt-компилятор отлично выполняет разделение кода, слияние общего кода с промежуточными модулями и добавление методов для асинхронного загрузки фрагментов при необходимости.
• Java-экосистема обеспечивает модульные приложения (зависимости, maven и т. Д.).

В противном случае, если вы хотите получить отдельные модули, способ их компиляции - это то, что вы на самом деле делаете: выполнение компилятора gwt один раз на модуль (и перестановка). Тем не менее, вы можете улучшить время компиляции, имея непрерывный кластер интеграции, например Jenkins, и выполнение заданий параллельно или используя более грубую силу (память, процессор, ...).

Answer 2

Как вы, вероятно, знаете, что GWT скомпилирует каждый модуль в один большой файл JavaScript и оптимизирует все, основываясь на всей доступной информации обо всем во всем модуле. Вот почему вам нужно скомпилировать все для каждого модуля.

Одним из решений может быть создание одного большого модуля, но используйте code splitting, аналогичный структуре модуля. Чем вы не получите один очень большой монолитный файл JavaScript, но «модули» загружаются по мере необходимости.

Вы пытались скомпилировать с меньшим количеством местных рабочих, вместо использования всех возможных доступных ядер? У меня были лучшие результаты с локальным набором, установленным на 4 (даже на 6-ядерном компьютере).