Добрый день!
Давайте попробуем размотать клубок с конца.
Конечный продукт, разработанный на платформе RadixWare и разворачиваемый у клиента, представляет собой "пирог" из слоев.
Каждый слой содержит набор модулей, которые в свою очередь содержат в себе различные дефиниции (классы, сущности, перечисления, формы и т.п.).
В целом слой можно рассматривать как логически сгруппированное множество бизнес-объектов, которые вместе призваны решать какой-то набор конечных задач.
Слой может базироваться на других слоях (другими словами, иметь базовые слои). Базовые слои, в свою очередь, тоже могут базироваться на каких-то других, и т.д.
Таким образом, образуется иерархия слоев. В самом низу этой иерархии всегда находится слой org.radixware (собственно, платформа).
При этом разные части этой иерархии разрабатываются разными вендорами (как минимиум, есть вендор платформы, и вендор конечного продукта).
Давайте рассмотрим пример. Для простоты ограничимся предположением, что каждый слой в "пироге" будет иметь ровно один базовый слой.
Допустим, Вы решили разработать продукт DearProduct.
Вы берете RadixWare Manager, создаете репозиторий, и загружаете в специальную ветку репозитория дистрибутив платформы.
Загрузка дистрибутива в общем случае означает, что вы получили какую-то иерархию уже готовых слоев.
Дальше у вас есть варианты - разворачивать этот дистрибутив как готовый продукт (собственно, так работают конечные клиенты),
либо вести на базе данного дистрибутива какую-то свою разработку (т.е. разрабатывать собственные слои поверх слоев из дистрибутива).
Сразу оговоримся, что не смотря на то, что дистрибутив может содержать несколько слоев, ровно один из них является "верхним", и этот слой
в некотором смысле идентифицирует дистрибутив ("верхний" слой прямо или косвенно зависит от всех остальных слоев дистрибутива, при этом от него в дистрибутиве
не зависит никто).
System Products In Use в RadixWare Manager имеет реальный смысл для варианта, когда Вы - конечный клиент. В этой настройке вы указываете URI верхних слоев, которые хотите разворачивать.
В типичном случае, когда вы получаете один продукт от одного вендора, это ровно один URI верхнего слоя полученного вами дистрибутива. (это 99% случаев. в теории, возможно разворачивать комбинацию дистрибутивов (продуктов) от разных вендоров, но это экзотика и мы ее опустим).
А если Вы не конечный клиент, а разработчик, Вам необходимо выбрать для себя URI слоя, который вы будете разрабатывать. Это Ваш Base Development URI.
В случае разработки рекомендуется в качестве System Products In Use указать Base Development URI. Но это не строгое требование, скорее "для красоты".
Пусть Ваш Base Development URI будет com.dearproduct.
Технически, вы можете разрабатывать в своем репозитории несколько слоев, но среди них должен быть один com.dearproduct, а остальные должны прямо или косвенно от него зависеть.
У такой схемы есть свой Use-Case, но о нем позднее.
Дальше вы при помощи правого клига по дистрибутиву платформы отправляете его в разработку. По сути, это действие скопирует слой платформы в вашу папку trunk - т.е. каталог, в которм
вы должны вести разработку. Дальше вы можете сделать чекаут этого каталога, открыть дизайнер, начать разрабатывать свои слои. Базовые слои у вас будут отображаться в режиме Read Only.
Дальше когда-нибудь Вы сделаете релиз, далее по релизу сформируете дистрибутив (он будет содержать уже два слоя - org.radixware и com.dearproduct, верхний - com.dearproduct),
и этот дистрибутив отдадите своим клиентам.
Предлагаю изучить описанную модель разработки как базу, далее будем двигаться исходя из Ваших вопросов.