В результате разработки модуля OperatorSelfService столкнулся с несколькими спорными вопросами. Вопросы перечислены в документации App-части, в секции "Доработки", в порядке приоритета. Прошу принять участие в их обсуждении. Ваше мнение важно!
Дискуссия порождена тем, что требует внести глобальные изменения в основные цели build.xml. Не хочется этого делать без предварительного обсуждения.
Ром, первое, что хочется сказать: ни из твоего заглавного поста, ни из документа непонятно, для чего это нужно, какие проблемы мы решаем.
Пока не будет понимания цели задачи, предполагаю, что не будет интереса и к её решению.
Насколько я понял с твоих слов, целью является повторное использование ранее разработанных приложений. Механизм повторного использования базируется на разрабатываемом тобой механизме наследования приложений.
Пока не готов говорить по техническим деталям, попробую позадавать какие-то вопросы, проясняющие идею и решение, возможно ответы на них будут полезны кому-то ещё. Наверное, эти ответы можно вычислить и по документу, но мне показалось, что для меня это не будет лёгкой прогулкой ;)
Несколько вопросов:
Приложение отличается от библиотеки наличием целого ряда труднонаследуемых элементов (в нашем случае - war, файлы свойств, конфигурационные файлы типа web.xml, ...).
Как предполагается с ними поступить ?
Можно перечислить конкретно, что предполагается наследовать кроме Java-классов приложения ?
Верно ли предположение, что наследование понимается только в смысле наследования GWT-модулей (inherits) аналогично наследованию модуля JepRia? Или не только ?
Last edit: Alexander Lapygin 2017-02-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Да, придется немного вникнуть в предметную область :) Поэтому разместил ссылку на документацию, без ее прочтения будет трудно разобраться.
Механизм наследования - стандарное GWT-наследование (inherits). Сборка библиотеки из прикладного модуля максимально аналогично сборке системной библиотеки JepRia.
Теперь по порядку к вопросу:
Вопрос первый:
Приложение отличается от библиотеки наличием целого ряда труднонаследуемых элементов (в нашем случае - war, файлы свойств, конфигурационные файлы типа web.xml, ...).
Как предполагается с ними поступить ?
Можно перечислить конкретно, что предполагается наследовать кроме Java-классов приложения ?
В результате сборки, в папке lib, создаются:
1. operatorselfservice.jar - содержит только java-исходники (пакеты client, shared, server) и файлы .gwt.xml.
2. operatorselfservice-resources.jar - содержит jsp, css и oss-config (специфика именно этого приложения, в общем случае не нужно). Все остальное из прикладного приложения отбрасывается.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Стало понятно, что механизмы, предлагаемые в решении, обусловлены невозможностью напрямую наследовать артефакты приложения.
Это естественно, поскольку они и не разрабатывались в расчёте на наследование.
Думаю, что JepRia-приложение можно изначально [при сборке] структурировать таким образом, чтобы [потенциально] наследуемые части приложения были оформлены в виде GWT-модулей.
Тогда наследование приложений сведётся к наследованию этих GWT-модулей, и никаких дополнительных механизмов не потребуется.
Last edit: Alexander Lapygin 2017-02-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
В результате разработки модуля OperatorSelfService столкнулся с несколькими спорными вопросами. Вопросы перечислены в документации App-части, в секции "Доработки", в порядке приоритета. Прошу принять участие в их обсуждении. Ваше мнение важно!
Дискуссия порождена тем, что требует внести глобальные изменения в основные цели build.xml. Не хочется этого делать без предварительного обсуждения.
Первоисточник: https://svn.code.sf.net/p/javaenterpriseplatform/svn/Module/OperatorSelfService/Trunk/Doc/App/AutoGen/index.html
Last edit: Roman Zakharov 2017-02-28
Ром, первое, что хочется сказать: ни из твоего заглавного поста, ни из документа непонятно, для чего это нужно, какие проблемы мы решаем.
Пока не будет понимания цели задачи, предполагаю, что не будет интереса и к её решению.
Насколько я понял с твоих слов, целью является повторное использование ранее разработанных приложений. Механизм повторного использования базируется на разрабатываемом тобой механизме наследования приложений.
Пока не готов говорить по техническим деталям, попробую позадавать какие-то вопросы, проясняющие идею и решение, возможно ответы на них будут полезны кому-то ещё. Наверное, эти ответы можно вычислить и по документу, но мне показалось, что для меня это не будет лёгкой прогулкой ;)
Несколько вопросов:
Приложение отличается от библиотеки наличием целого ряда труднонаследуемых элементов (в нашем случае - war, файлы свойств, конфигурационные файлы типа web.xml, ...).
Как предполагается с ними поступить ?
Можно перечислить конкретно, что предполагается наследовать кроме Java-классов приложения ?
Верно ли предположение, что наследование понимается только в смысле наследования GWT-модулей (inherits) аналогично наследованию модуля JepRia? Или не только ?
Last edit: Alexander Lapygin 2017-02-28
Да, придется немного вникнуть в предметную область :) Поэтому разместил ссылку на документацию, без ее прочтения будет трудно разобраться.
Механизм наследования - стандарное GWT-наследование (inherits). Сборка библиотеки из прикладного модуля максимально аналогично сборке системной библиотеки JepRia.
Теперь по порядку к вопросу:
В результате сборки, в папке lib, создаются:
1. operatorselfservice.jar - содержит только java-исходники (пакеты client, shared, server) и файлы .gwt.xml.
2. operatorselfservice-resources.jar - содержит jsp, css и oss-config (специфика именно этого приложения, в общем случае не нужно).
Все остальное из прикладного приложения отбрасывается.
Стало понятно, что механизмы, предлагаемые в решении, обусловлены невозможностью напрямую наследовать артефакты приложения.
Это естественно, поскольку они и не разрабатывались в расчёте на наследование.
Думаю, что JepRia-приложение можно изначально [при сборке] структурировать таким образом, чтобы [потенциально] наследуемые части приложения были оформлены в виде GWT-модулей.
Тогда наследование приложений сведётся к наследованию этих GWT-модулей, и никаких дополнительных механизмов не потребуется.
Last edit: Alexander Lapygin 2017-02-28
Обсудили устно с Сашей: web-jar будет объединен с jar, а log4j.properties перемещен отдельно в WEB-INF\lib.
Остался открытым первый вопрос о нескольких файлах .gwt.xml в одном app-модуле.
Last edit: Roman Zakharov 2017-03-01