disdis / closureplatform Goto Github PK

Не могу запустить пример с использованием GSS миксинов.

1. Файл 3-typography.gss определяет миксин

@defmixin large() {
  font-size: 2em; /* 30px */
  line-height: 1.4667em; /* 44px */
  margin-top: 0.7333em;
  margin-bottom: 0em;
}

.large {
  @mixin large();
}

Файл 5-main.gss пытается использовать этот миксин

h1 {
    @mixin large();
}

Полный пример см. https://gist.github.com/xasima/5338461

При вызове серии cd tools && ./clean.sh && ./compile.templates.sh генерируется ошибка. При этом порядок обработки GSS файлов (судя по логу Scan) - правилен.

------== Scan GSS files ==------
   found './../themes/default/gss/2-typography.gss'
   found './../themes/default/gss/0-definitions.gss'
   found './../themes/default/gss/5-main.gss'
------== GSS ==------
------== SOY ==------
   Compiling SOY....Compiler internal error: com.google.common.css.compiler.ast.CssMixinNode cannot be cast to com.google.common.css.compiler.ast.CssDeclarationNode
java.lang.ClassCastException: com.google.common.css.compiler.ast.CssMixinNode cannot be cast to com.google.common.css.compiler.ast.CssDeclarationNode
        at com.google.common.css.compiler.passes.DisallowDuplicateDeclarations.enterRuleset(DisallowDuplicateDeclarations.java:64)
        at com.google.common.css.compiler.ast.DefaultVisitController$VisitRulesetState.doVisit(DefaultVisitController.java:762)
        at com.google.common.css.compiler.ast.DefaultVisitController.startVisit(DefaultVisitController.java:1762)
        at com.google.common.css.compiler.passes.DisallowDuplicateDeclarations.runPass(DisallowDuplicateDeclarations.java:75)
        at com.google.common.css.compiler.passes.PassRunner.runPasses(PassRunner.java:142)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.parseAndPrint(DefaultCommandLineCompiler.java:106)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.compile(DefaultCommandLineCompiler.java:94)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.execute(DefaultCommandLineCompiler.java:129)
        at com.google.common.css.compiler.commandline.ClosureCommandLineCompiler.executeJob(ClosureCommandLineCompiler.java:293)
        at com.google.common.css.compiler.commandline.ClosureCommandLineCompiler.main(ClosureCommandLineCompiler.java:366)
.ERROR
OK

При сборке модулей soy.create.modules (выполнение gcmodule.jar): на стадии выполнения calcdeps.py, скрипт собирает отсортированный список зависимостей..

Было замечено, когда длина строки со списком зависимостей превышает 65.000 символов, питоновский буфер вывода переполняется и скрипт не отрабатывает.
В моем случае так получается, когда проект имеет очень длинный путь, и в проекте содержится чуть больше 500 js файлов. Длина строки получается 90к+.

Подскажите, пожалуйста, можно ли как нибудь поправить этот баг?

В основной на сегодняшний момент документации (http://habrahabr.ru/post/162261/) как и в поставляемом в репозитории примере (шаблоне приложения, boilerplate) упоминается о поддержке модулей.

Более того, в процессе обработки tools/gcmodule/config.cfg генерируется webUI/js/module/default/ru/moduleinfo.js, содержащий карту closure модулей.

То есть выглядит так, словно closure модули действительно генерируются.

С другой стороны, нигде не упоминается (не используется) классическое управление модулями, а именно

1. оповещение родительского модуля о загрузке

// This tells the module manager that the 'settings' module has been loaded;
// otherwise, the module manager will assume that loading has timed out and it
// will try again.
goog.module.ModuleManager.getInstance().setLoaded('settings');

2. разбиение модуля на части выполняемая (sample.js, то что у вас есть как, например, page.index.js) и загрузочная (sample_init.js). Последняя как раз и занимается подгрузкой (через goog.net.BulkLoader или <script/>) основного модуля.

Поэтому требуется пояснение, что ваш код берет на себя (с т.з. ModuleManager), как оформлять (как нюансы с т.з. сборки) полноценные closure модули, интегрируемые через ModuleManager.

Подправить c относительных на абсолютные пути в блоке MODULE_URI moduleinfo.js файла (в RELEASE режиме)

см. #4

Хочу уточнить, поддерживаются ли require / provide в gss файле при компиляции в DEBUG режиме?

Например, есть 4-grid.gss

@provide grid;
@require typography;

, который в свою очередь зависит от 3-typography.gss

@provide typography;

Однако при обработке cd tools && ./clean.sh && ./compile.templates.sh генерируется ошибка о невозможности найти typography

------== SOY ==------
   No changed files
   found './../themes/default/gss/2-typography.gss'
   found './../themes/default/gss/3-grid.gss'
------== GSS ==------
   Compiling GSS...Missing provide for: typography in ./../themes/default/gss/3-grid.gss at line 2 column 1:
@require typography;
^

1 error(s)

.ERROR

build.soy.properties содержит единственную папку, в которой предполагается поиск soy для их последующей компиляции

soy.tools.dir=./tools
soy.theme.dir=./themes

Желательно иметь возможность указывать несколько папок для поиска и компиляции soy файлов.

soy.tools.dir=./tools
soy.theme.dir=./themes
soy.soy.dir=./WebUI/js/other_not_dependent-on-theme_framework_that_contains_soy

Например, relief фреймворк, написанный на Google Closure, содержит внутри себя нескомпилированный soy файл. В настоящий момент приходиться отдельно компилировать такие soy файлы.