Correct project structure

MinimaJack commented 9 years ago

../
./src/main/_1c/
./src/main/_1c/DataProcessors/Ob1/ManagerModule.bsl
./src/main/_1c/DataProcessors/Ob1/ObjectModule.bsl
./src/main/resources/
./src/test/_1c/...

почему отошли от стандарта?

1C-Company commented 9 years ago

@MinimaJack мы анализируем различные варианты структуры проекта. текущий вариант не является окончательным

MinimaJack commented 9 years ago

@1C-Company Нормальная ситуация создать "описание проблемы", что бы видеть текущие проблемы и не задавать вопросы несколько раз. Чем больше написано проблем - тем лучше вам же.

ghost commented 9 years ago

@1C-Company мы со своей стороны тоже проводили анализ корректной структуры на основе выгрузки в файлы:

то что у нас получалось: https://bitbucket.org/Shenja/elementaltrade/src/b909046bfff26ff60bca54c8af738e8a02aab2fa/src/?at=master есть еще пробы пера http://habrahabr.ru/post/248303/ и соответственно пример https://github.com/elisy/ssl

По итогам анализа была даже зарегистрирована ошибка платформы за номером 10119794 - связанная с длинной имени файла если НЕ использовать каталоги.

Надеюсь данная информация будет полезна.

1C-Company commented 9 years ago

@MinimaJack все верно, вместе мы сделаем продукт лучше.

@allustin Спасибо за информацию!

ghost commented 9 years ago

@1C-Company когда мы анализировали структуру хранения конфигураций в исходных файлах мы исходили из того, что самое главное в исходных файлах (то есть цель) - это обеспечить удобное объединение (merge) и удобное разрешение конфликтов (resolve conflicts) при коллективной разработке

То есть сделать так, чтобы можно было использовать git-flow в качестве системы управления коллективного владения исходным кодом.

ключевым здесь виделась возможность удобного http://git-scm.com/docs/git-cherry-pick - это одна из повседневных задач - когда в финальном релизе конфигурации должна оказаться только часть функционала (отдельный коммит) из соседних веток.

Поэтому в идеале - объект метаданных: это НЕ один файл формата XML, YAML, а комплект файлов.

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

То есть - для правильного выбора хранения структуры проекта необходимо обеспечить конфликт в коллективной разработке и посмотреть - каким образом структура проекта адаптирована под автоматическое разрешение конфликтов которое встроено сейчас во все известные SCM (системы владения исходными кодами).

P.S. Плюс надо понимать - что тот же git адаптирован под небольшие помещение в большом количестве файлов и НЕ очень любит исходники с большими файлами, а наоборот - много маленьких файлов.

enik-ua commented 9 years ago

Есть предложение воспроизвести иерархическую структуру, как в дереве конфигурации.

wwall commented 9 years ago

не стоит. длина имени файла - не резиновая....

MinimaJack commented 9 years ago

идея воспроизвести иерархическую структуру вполне нормальная ТУТ все хорошо выглядит. Единственно - переименовать:

Report / БалансДвиженияДенег /БалансДвиженияДенег.xml

в

Report / БалансДвиженияДенег /index.xml (mdo)

Имя папки - синоним, одинаковые папки не создать, как и синонимов не прописать. скопировал -> переименовал папочку -> готово, новый отчет; не надо лезть внутрь для манипулирования именами файлов.

ghost commented 9 years ago

Новость прошла по Зазеркалью - http://v8.1c.ru/o7/201507xml/index.htm

1C-Company commented 9 years ago

Реализована иерархическая структура проекта и не только. Дальше будем смотреть на сколько удобно с ней работать. Комментарии приветствуются =)

посмотреть можно здесь - https://releases.1c.ru/version_files?nick=DevelopmentTools10&ver=1.1.0.203

бранч https://github.com/1C-Company/dt-demo-configuration/tree/ctp-1.1.0

ghost commented 9 years ago

спасибо уже пробуем - новость прошла официальными каналами http://www.1c.ru/news/info.jsp?id=20494

artbear commented 9 years ago

бранч https://github.com/1C-Company/dt-demo-configuration/tree/ctp-1.1.0

@1C-Company Похоже, что EDT и 1С используют разные версии иерархической выгрузки конфигурации :)

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

Скачал 1С 8.3.7.1633, выполнил штатную иерархическую выгрузку нашего открытого продукта xUnitFor1C, получил следующие расхождения:

1 Модули объектов при типовой выгрузке 1С выгружаются как

DataProcessors\xddTestRunner\Ext\ObjectModule.bsl
у Вас показана структура DataProcessors/ПроведениеДокументов/ObjectModule.bsl

т.е. 1С создает ненужный каталог Ext и выгружает туда модуль. В этом каталоге будет всего один файл. В данном случае у Вас удобнее структура, чем у типовой выгрузки 1С.

2 Макеты выгружаются еще дальше

"Reports\ТестовыйОтчетСКДДляСравнениеСЭталоном\Templates\ОсновнаяСхемаКомпоновкиДанных\Ext\Template.xml
У Вас Reports/ДинамикаПродаж/Templates/ОсновнаяСхемаКомпоновкиДанных/Template.dcs

В данном случае и у Вас, и у штатной выгрузки 1С структура не так удобна. Опять один каталог на один файл.

3 Что интересно, у штатной выгрузки 1С хмл-файлы описания макетов находятся в одном каталоге :)

DataProcessors\xddTestRunner\Templates\Макет.xml
DataProcessors\xddTestRunner\Templates\ОтчетТестирования.xml

Вопросы:

Как Вы совмещаете 2 вида выгрузки - EDT и 1С ?
Зачем так далеко укладывать файлы, которые все уникальны и их можно положить в один общий каталог? Фактически мы только удлиняем путь к файлам и затрудняем использование различных инструментов, например, инструментов для просмотра код-ревью и т.п.

ИМХО 1С в своем стремлении сделать все иерархически пошла слишком далеко, часть файлов удобно положить в одном общем каталоге (я про макеты и модули объектов)

В нашем открытом продукте https://github.com/xDrivenDevelopment/v83unpack этой проблемы нет. Например, модуль лежит на верхнем уровне выгрузки объекта, макеты лежат в одном каталоге

1C-Company / dt-demo-configuration

Correct project structure #2