[doc] Update the shapes and ADR related to the publication of libraries

CHANGELOG.adoc

@@ -10,7 +10,8 @@
 - Add support to dynamically update representation description
 - Add loading indicators for long actions
 - Add impact analysis before tool execution
-- Add support for artifact publication from a project
+- Add support for the publication of libraries
+- Add support for the import of libraries
 - Improve image export
 - Add the current selection to the URL of the project workbench
 - Improve the customization of the navigation bar
@@ -19,7 +20,7 @@
 === Architectural decision records
 
 - [ADR-178] Add support of actions in table row menu
-- [ADR-179] Add support for artifact publication from a project
+- [ADR-179] Add support for regular commands in the command palette
 - [ADR-180] Add support for widget diagnostics provider in View-based Forms
 - [ADR-181] Improve the customization of the navigation bar
 

doc/adrs/179_add_support_for_regular_commands_in_the_command_palette.adoc

@@ -0,0 +1,28 @@
+= [ADR-179] Add support for regular commands in the command palette.
+
+Github issue: https://github.com/eclipse-sirius/sirius-web/issues/4428
+
+== Context
+
+We need to be able to provide backend commands to trigger some backend and frontend actions from the command palette.
+
+
+== Decision
+
+The current support for the search in the command palette should be accessible thanks to a dedicated command.
+This command will make the command palette switch its behavior to a search mode.
+In this search mode, the commands received by the backend will be used to update the selection of the frontend, just like today.
+
+On top of that, new commands will be available to execute some arbitrary behavior on the backend.
+Those commands may specify the identifier of a dialog to display when clicked by the end user.
+Those dialogs should be registered, probably thanks to an extension point, to be discovered by the command palette.
+
+The command that want to leverage those dialog may need to provide some additional parameters to the dialog.
+For example, two commands leveraging a publication dialog will need to indicate to said dialog which publication process to run.
+
+Those command may need to have support for an optional map of keys and values that will be given to the modal used after their execution.
+
+
+== Status
+
+Work in progress

doc/iterations/2025.2/add_support_for_the_import_of_libraries.adoc

@@ -0,0 +1,40 @@
+= Add support for the import of libraries
+
+== Problem
+
+Sirius Web need to provide an **in-application** way to import libraries that have been published by specifiers.
+
+== Key Result
+
+Sirius Web should provide a way for downstream applications to
+
+- Define commands to import librairies
+- Define the behavior of the command (how is the libraries imported)
+
+Note that multiple libraries may be imported at once.
+
+
+=== Acceptance criteria
+
+- It should be possible to copy a library published by a studio in another studio.
+- Backend tests should be used to validate that the import mechanism is working as expected
+
+== Solution
+
+Specifiers should be able to provide commands to let end users trigger an import process.
+In a similar fashion as the command for the publication, the command for the import should be able to display a dialog.
+A generic dialog to let end users import libraries should be provided.
+
+This dialog should display all the libraries published on the server.
+The end user should be able to select some libraries published and then select an action compatible with the selection.
+Depending on the project and the selected libraries, various actions may be available.
+
+If no action can be used for the project and the selected libraries then a message should be visible to let end users know that the set of selected libraries cannot be imported in the project.
+
+=== Cutting backs
+
+== Rabbit holes
+
+Nothing identified.
+
+== No-gos

doc/iterations/2025.2/add_support_for_the_publication_of_libraries.adoc

@@ -0,0 +1,89 @@
+= Add support for the publication of libraries
+
+== Problem
+
+Sirius Web doesn't provide an **in-application** way to publish libraries from a project.
+The current import/export mechanisms rely on generating an interchange format file (Json, XMI, SysML), and uploading such file in a project to import it.
+
+When exported models are used as shared reusable components, it is the responsibility of the stakeholders to:
+
+- Store the shared models in an external location
+- Ensure that every user is working on the same version of the shared model
+- Coordinate to export a new version when needed, and import it in all the dependent projects
+
+These processes are error-prone, and could be more controlled if they all happened inside the application.
+
+
+== Key Result
+
+Sirius Web should provide a way for downstream applications to 
+
+- Define their publication commands
+- Store published libraries in a provided data structure
+- View all libraries published on the server
+
+Note that the actual implementation of the publication process (i.e. what to publish from a given project) should be delegated to downstream applications. 
+We already have downstream projects that implement or want to implement different publication mechanisms:
+
+- Publish fragments of a model
+- Publish entire editing contexts
+- Publish multiple libraries from a single project
+
+This shape doesn't address the question of importing published libraries in a project. 
+A solution to this issue will be proposed in a complementary shape.
+
+
+=== Acceptance criteria
+
+- The support for studio should provide a command publishing all the domains and representations descriptions from a studio project.
+Each domain and each representation description should be published as a dedicated library.
+After the execution of the publication command of a studio, all the domains and representation descriptions should be visible in the libraries page.
+- Backend tests should be used to validate that this publication mecanism is working as expected
+
+
+== Solution
+
+Specifiers should be able to contribute new commands to the command palette.
+A command should also be able to indicate that it should open a specific dialog, pre-registered on the frontend command palette.
+
+A generic dialog to publish libraries should also be contributed in Sirius Web to let specifiers of downstream projects contribute publication workflow easily.
+This dialog should contain two textfields to let end users specify the version and the description to be used by the publication process.
+Sirius Web should also provide a GraphQL mutation for this dialog to trigger the execution of the publication process. 
+This mutation should ensure that the execution of the publication does not block the editing context event processor (some publication processes may take a long time to complete).
+
+Note that this new type of command is not restricted to artifact publication.
+They could be leveraged by downstream applications to perform any kind of behavior on a project.
+
+Downstream applications should be able to trigger the execution of a publication process from their own user interface (from the contextual menu in the explorer, from a custom tool in the diagram palette, etc).
+
+
+Sirius Web should provide some database table(s) to store published libraries. 
+Those tables should at least contain the following pieces of information for each published library:
+
+- identifier
+- project
+- serialized content
+- dependencies
+- version
+- description
+- date of creation
+- date of last modification
+
+We should keep in mind that one library published may be composed of multiple documents and that multiple libraries could be published from one document.
+Some libraries will also have a dependency to other libraries, we should be able to capture this information provided by the specifier from day one.
+Documents cannot be considered as the compulsory granularity used by an library.
+
+Finally, Sirius Web should provide a new page to let user see the libraries that have been published on the server. 
+This page will be accessible at `/libraries`, and it will contain a table with the information contained in the database.
+
+The business layer of Sirius Web should prevent the publication of two libraries with the same name and version on the server.
+
+=== Cutting backs
+
+- (Nice to have) downstream application can add custom properties on the published libraries.
+
+== Rabbit holes
+
+Nothing identified.
+
+== No-gos