|Re: [mdt-papyrus.dev] Photon Work Description - Papyrus SDK|
Actually this page is supposed to be the starting point on a discussion about the SDK in Papyrus and the refactoring in general of the different features and the way they are distributed. Though I see now that marking it as a “declaration of intent” would have made this less confusing.
This has now been changed and this page can be viewed and the tasks discussed here .
For your first point: I agree with you that all the tools under the dev feature, for example the releng tools, are not supposed to be migrated under the SDK itself but, as mentioned before, there is indeed a growing need to distribute some of them, for example the test framework, in the main release of Papyrus to allow stable integrations. The dev folder indeed requires a specific platform but I think the point being made by the page is that it aggregates the full Papyrus target and that may be overkill, and the dev and toolsmith reflexion behind the features seem to overlap a great deal to me.
Therefore I do not think that the job will die, thought it will be renamed if it turns out that all that it does is to build the releng tools. That being said, and as mentioned by Benoit, this poses the question on the validity of letting those tools stay in the Papyrus’ repository itself and not migrating them in their own one.
For your second point: Yes that should be the case but I would see it under the new “sdk” feature myself, which could aggregated the toolsmith features as subfeatures to be installed separately if one only needs some of the tools provided in the sdk. I believe it was mentioned that way because the current sdk feature aggregates all the infra/core/uml features under it and is provided as is to the simrel train, a little more flexibility would allow a clearer cut between the provided features.
For the third point: This one is a little strange for me too, as the point of this work would be to allow an easier and more modular way to view Papyrus and display the parts as separate instances to be installed and worked with.
I hope this answers some of your questions, but if you still have some do not hesitate to participate in the wiki page or ask further questions,
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Remi Schnekenburger
I was reading the wiki page about Papyrus SDK, https://wiki.eclipse.org/Papyrus/Photon_Work_Description/Architecture_refactoring/Papyrus_SDK.
This page triggers some questions for me:
The developer plugins do not have the same platform as the one used for building Papyrus infra and UML, so I do not understand there why it should be deleted. The developer plugins may rely on components that are not required for Papyrus at runtime, as for example the UPR testing profile. The CBI integrator is also another example for not being required for infra & UML, so why should it be in the main target platform?
As far as I understand, the plan is to push the developer tools to the release train? Or was I mistaken?
I propose here to advertise a 4th feature in this refactoring, with the toolsmith feature, to distinguish users from the DSML toolsmiths.
Also, the infra and core features are already installable on their own, on which criteria is this proposal highlighting the infra/core?
So it is expected that the SDK will always be installed by default? I would find this solution not very usable, as these tools are not dedicated to be used and documented by everyone installing Papyrus. This would only confuse the end users of Papyrus as a UML modeling tool. I suppose also that the UML feature will be the one to be referenced as the main entry point in the release train or the toolsmith one if this feature is advertised ?
Senior Software Architect / General Manager
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516 R.C.S. EVRY
Back to the top