Hi Remi,
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 [1].
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,
Quentin
[1]
https://wiki.eclipse.org/Papyrus/Discussion/Architecture_refactoring/Papyrus_SDK
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Remi Schnekenburger
Envoyé : mardi 5 décembre 2017 14:18
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [mdt-papyrus.dev] Photon Work Description - Papyrus SDK
Hi,
This page triggers some questions for me:
deletion of the releng/dev folder, no need to specific target platform, since it includes already the main target platform
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?
We propose to restore naming convention for the Papyrus feature. It will be important also to hihglight the fact that we could also install Papyrus (core/infra) without Papyrus UML, that wy it could be pertinent
to distinguish:
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?
Verification
Check when installing Papyrus that we have the 3 main features.
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 ?
--
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516 R.C.S. EVRY
