diff --git a/CHANGELOG.adoc b/CHANGELOG.adoc index c5b71818e2..29f1614140 100644 --- a/CHANGELOG.adoc +++ b/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 diff --git a/doc/adrs/179_add_support_for_artifact_publication_from_a_project.adoc b/doc/adrs/179_add_support_for_artifact_publication_from_a_project.adoc deleted file mode 100644 index fca5a41a83..0000000000 --- a/doc/adrs/179_add_support_for_artifact_publication_from_a_project.adoc +++ /dev/null @@ -1,72 +0,0 @@ -= [ADR-179] Add support for artifact publication from a project - -== Context - -We need to be able to find all the available workflows and execute one. - - -== Decision - -Sirius Web should provide record and interfaces similar to the examples below: - -```java -public record ProjectWorkflow( - @NotNull String id, - @NotNull String label -) {} - -public interface IProjectWorkflowProvider { - List getProjectWorkflows(UUID projectId); -} - -public interface IProjectWorkflowHandler { - /* - * Can use the nature of the project to figure out if the workflow is relevant - */ - boolean canHandle(String projectWorkflowId); - - /* - * I'm not providing the editing context here on purpose to let the specifier load the snapshot of the - * data from the database in order NOT to block the editing context event processor. - */ - void handle(ICause cause, String projectWorkflowId, UUID projectId); -} -``` - -It will allow Sirius Web to provide the following GraphQL API to retrieve and execute workflows: - -``` -type Project { - workflows: ProjectsWorkflowsConnection! -} - -type ProjectsWorkflowsConnection { - edges: [ProjectWorkflowEdge!]! - pageInfo: PageInfo! -} - -type ProjectWorkflowEdge { - node: ProjectWorkflow! -} - -type ProjectWorkflow { - id: ID! - label: String! -} - -type Mutation { - executeProjectWorkflow(input: ExecuteProjectWorkflowInput!): ExcecuteProjectWorkflowPayload! -} - -union ExecuteProjectWorkflowPayload = ErrorPayload | SuccessPayload - -input ExecuteProjectWorkflowInput { - id: ID! - projectId: ID! - projectWorkflowId: ID! -} -``` - -== Status - -Work in progress diff --git a/doc/adrs/179_add_support_for_regular_commands_in_the_command_palette.adoc b/doc/adrs/179_add_support_for_regular_commands_in_the_command_palette.adoc new file mode 100644 index 0000000000..7569ad098d --- /dev/null +++ b/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 diff --git a/doc/iterations/2025.2/add_support_for_artifact_publication_from_a_project.adoc b/doc/iterations/2025.2/add_support_for_artifact_publication_from_a_project.adoc deleted file mode 100644 index 1f8af749fe..0000000000 --- a/doc/iterations/2025.2/add_support_for_artifact_publication_from_a_project.adoc +++ /dev/null @@ -1,83 +0,0 @@ -= Add support for artifact publication from a project - -== Problem - -Sirius Web doesn't provide an **in-application** way to publish artifacts 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 application to - -- Define their publication _workflow_ -- Store published artifacts in a provided data structure - -Note that the actual implementation of the publication workflow (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 artifacts from a single project - -This shape doesn't address the question of importing published artifacts in a project. -A solution to this issue will be proposed in a complementary shape. - -=== Acceptance criteria - -- The support for studio should provide a workflow publishing all the domains and representations descriptions from a studio project. -Each domain and each representation description should be published as a dedicated artifact. -After the execution of the workflow of a studio, all the domains and representation descriptions should be visible in the artifact page. -- Backend tests should be used to validate that this publication mecanism is working as expected - - -== Solution - -Sirius Web should provide a menu to view the various workflows and run one. -A new button will be availble in the navigation bar to open a dialog containing all the workflows of the project. -The user will be able to click on one workflow to run it. -For that a GraphQL query will be available to retrieve all the workflows of the project. - -Sirius Web should also provide a GraphQL mutation to trigger the execution of a project workflow. -This mutation should ensure that the execution of the workflow does not block the editing context event processor (some workflows may take a long time to complete). - -Note that this workflow support 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 workflow 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 artifacts. -Those tables should at least contain the following pieces of information for each published artifact: - -- identifier -- serialized content -- dependencies -- version -- description -- date of creation -- date of last modification - -We should keep in mind that one artifact may be composed of multiple documents and that multiple artifacts could be published from one document. -Some artifacts will also have a dependency to other artifacts, 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 artifact. - -Finally, Sirius Web should provide a new page to let user see the artifacts that have been published by a project. -This page will be accessible at `projects/projectId/artifacts`, and it will contain a table with the information contained in the database, filtered for the selected project. - -=== Cutting backs - -- (Nice to have) downstream application can add custom properties on the published artifacts. - -== Rabbit holes - -Nothing identified. - -== No-gos diff --git a/doc/iterations/2025.2/add_support_for_the_import_of_libraries.adoc b/doc/iterations/2025.2/add_support_for_the_import_of_libraries.adoc new file mode 100644 index 0000000000..b885c744de --- /dev/null +++ b/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 diff --git a/doc/iterations/2025.2/add_support_for_the_publication_of_libraries.adoc b/doc/iterations/2025.2/add_support_for_the_publication_of_libraries.adoc new file mode 100644 index 0000000000..017b54f657 --- /dev/null +++ b/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