Community
Participate
Working Groups
Use of UML in a standalone environment used to be a nightmare. Then UMLResourcesUtil.init changed the situation and it became comparatively easy. SysML users, particularly those using other tools such as Acceleo are encountering a very similar nightmare. There should be a SysMLResourcesUtil.init emulating Eclipse UML2, or possibly a SysMLStandaloneSetup.doSetup emulating Xtext that makes initialization trivial.
Irritated by yet another user falling foul of this, I thought I'd take a shot at it, but as usual as a casual SysML user I'm defeated when I try to install SysML. There is no SysML in the SimRel repo and Papyrus doesn't install it. Googling gives http://download.eclipse.org/modeling/mdt/papyrus/components/sysml14/ but that refuses to install with my Photon version of Papyrus... Please ensure that SysML is easily installable from SimRel. If SysML is not bundled within Papyrus, I expect to find it by typing SysML as the filter text for an uncategorised listing of http://download.eclipse.org/releases/photon which is where I find Papyrus. (I give up on trying to develop a SysMLResourcesUtil.init.)
Hi Ed, SysML 1.4 was extracted from the Papyrus contribution to simrel (the main reasons were to provide release outside the train and the many regular api breaks in Papyrus core) You may install it from the Eclipse Market Place on Oxygen 3.3.0 (you may also install it on an oxygen package from update site but it won't install on photon due to api break) I guess that, this discussion is coming from https://www.eclipse.org/forums/index.php/t/1091946/ With this github repo as example https://github.com/pipsoft/AcceleoIssueWithInvalids Adding a SysMLResourcesUtil.init seems a good idea. I tried to setup an example with acceleo using https://wiki.eclipse.org/Acceleo/Maven#Maven_Tycho_build with a template using SysML 1.4, but I got this exception in the build Caused by: java.lang.ExceptionInInitializerError at org.eclipse.papyrus.sysml14.modelelements.internal.impl.ModelelementsPackageImpl.init (ModelelementsPackageImpl.java:188) at org.eclipse.papyrus.sysml14.modelelements.ModelelementsPackage.<clinit> (ModelelementsPackage.java:69) at org.eclipse.papyrus.sysml14.portsandflows.internal.impl.PortsandflowsPackageImpl.init (PortsandflowsPackageImpl.java:218) at org.eclipse.papyrus.sysml14.portsandflows.PortsandflowsPackage.<clinit> (PortsandflowsPackage.java:72) at org.eclipse.papyrus.sysml14.deprecatedelements.internal.impl.DeprecatedelementsPackageImpl.init (DeprecatedelementsPackageImpl.java:138) at org.eclipse.papyrus.sysml14.deprecatedelements.DeprecatedelementsPackage.<clinit> (DeprecatedelementsPackage.java:69) at org.eclipse.papyrus.sysml14.constraintblocks.internal.impl.ConstraintblocksPackageImpl.init (ConstraintblocksPackageImpl.java:125) at org.eclipse.papyrus.sysml14.constraintblocks.ConstraintblocksPackage.<clinit> (ConstraintblocksPackage.java:69) at org.eclipse.papyrus.sysml14.blocks.internal.impl.BlocksPackageImpl.init (BlocksPackageImpl.java:232) at org.eclipse.papyrus.sysml14.blocks.BlocksPackage.<clinit> (BlocksPackage.java:69) at org.eclipse.papyrus.sysml14.allocations.internal.impl.AllocationsPackageImpl.init (AllocationsPackageImpl.java:132) at org.eclipse.papyrus.sysml14.allocations.AllocationsPackage.<clinit> (AllocationsPackage.java:70) at org.eclipse.papyrus.sysml14.activities.internal.impl.ActivitiesPackageImpl.init (ActivitiesPackageImpl.java:178) at org.eclipse.papyrus.sysml14.activities.ActivitiesPackage.<clinit> (ActivitiesPackage.java:67) at org.eclipse.papyrus.sysml14.impl.sysmlPackageImpl.init (sysmlPackageImpl.java:123) at org.eclipse.papyrus.sysml14.sysmlPackage.<clinit> (sysmlPackage.java:66) So I guess there is something fishy in initialization, I will look into it.
(I needed the Photon version) The exceptions look familiar. If packages are initialized in the wrong order bad things can happen. GenModel tries to create inter package dependencies but these can loop. Even EMF can get itself in a mess all by itself, and so EMF has a very judiciously placed self initialization. SysMLResourcesUtil.init should carefully sequence from most primitive to most complex. I was thinking about the UMLResourcesUtil.init/SysMLResourcesUtil.init analogy and decided it is dangerous. UML is fairly stable, the core is very stable, so the UML2 project has successfully created a family of load-converters from UML X to Y where Y > X but not vice-versa. SysML appears to be much less stable and so pretending that there is only one SysML may be a mistake. I suggest being very explicit about each SysML distribution being independent (and able to co-exist) until at least two sub-versions after 2.0. There is therefore no need for SysMLResourcesUtil.init to have contentType magic for 1.3/1.4/2.0; let the user invoke ....sysml14/utilities/SysMLResourcesUtil.init. Conversion between 1.3/1.4/2.0 can be performed by genuine M2M's even if the coding is pure Java.
