ELTE-Soft / txtUML

Textual, eXecutable, Translatable UML
http://txtuml.inf.elte.hu
Eclipse Public License 1.0
26 stars 9 forks source link

Not all required Papyrus components are installed #117

Closed devaigergely81 closed 8 years ago

devaigergely81 commented 9 years ago

The v020 update site was created using the manual patch we agreed on in #6. This can install txtUML on a clean Eclipse. However, after visualization, the Papyrus diagrams have no color, and state machine animation is also not working.

If Papyrus is installed manually (either before or after the txtUML installation), everything works fine.

The suspected cause is, that the txtUML installation does not trigger the installation of all necessary Papyrus components.

For this reason, the install guide of v020 asks the users to manually install Papyrus.

gerazo commented 8 years ago

We are close to pop up an automatic update site creation (Mars and Maven based) as well which will handle this problem.

gerazo commented 8 years ago

I believe that https://github.com/ELTE-Soft/txtUML/pull/156 will solve the problem once and for all.

gerazo commented 8 years ago

I find it shocking that it is still not working with the new update site. Moka is explicitly referenced as an update site and is also a dependency. Is it something else missing?

devaigergely81 commented 8 years ago

Moka was correctly installed already in v020. The problem is that only those Papyrus plugins are installed that are explicitly needed for the functioning of our plugins. So installation and use of txtUML never fails because of missing plugins. The problem is that further Papyrus plugins are needed to normally color diagrams and shape the init state as a circle instead of a sqare, for example. Diagram animation fails, because the Papyrus coloring functionality is missing at all, and not because Moka would be missing. If we install Papyrus after txtUML, the problems get solved without touching the Moka installation.

kmate commented 8 years ago

I am thinking on an alternate solution, where our full update site is a composite site, and papyrus+moka+etc.. is only referenced from its original repository. Then we don't have to include transitive dependencies in our own generated update site, which contains xtxtuml only. We may also add those features as dependencies to achieve a full installation of thoose components and avoid the problems mentioned in the previous comment. The only complication is that currently there is no tool to automatically derive a composite site definition from a target definition, which could make the process easier. However, the target definition will change very slowly - usually three times a year, when a new eclipse version or a service release comes out. So I think then it is acceptable to adjust the composite site definition to the actual target definition by hand, which is not even a hard task... I will make some experiments to see whether this idea could work.

kmate commented 8 years ago

I made some improvements on branch minimal-update-site.

  1. I disabled the transitive dependency inclusion, which results in a very small update site (under 2 megabytes).
  2. As Moka is not included in the default Mars repository, I made an Ant script that modifies the update site assembled by tycho at the end of the build. It inserts the associate sites specified under associate.sites.properties. Currently it only contains the Papyrus Extra update site.
  3. The txtUML feature is changed to depend not only on specific plugins, but on whole features. It solves the installation problems mentioned above.

The new update site zip can be downloaded from the working directory of Jenkins job txtUML-minimal-update-site.

gerazo commented 8 years ago

Wow, thanks

gerazo commented 8 years ago

Works fine.