Eclipse Community Forums: UML2 » Standalone: load profile from Papyrus models

Home » Modeling » UML2 » Standalone: load profile from Papyrus models

Standalone: load profile from Papyrus models [message #1777371]

Tue, 28 November 2017 19:02

Eclipse User

Hi, I have to parse some UML models created with Papyrus in a standalone application.
These models refer a (unregistered) UML profile stored in the same project as the models files (also same directory, actually).
When I try to load the models from outside Eclipse the profile application is lost: load is successful but when looking for stereotypes applied to the elements I cannot find them.
It seems like the resource loader is usable to deal with the way the profile is referenced.

I'm using the basic standard standalone setup (I hope):

ResourceSet set = new ResourceSetImpl();
UMLResourcesUtil.init(set);
set.getPackageRegistry().put(UMLPackage.eNS_URI, UMLPackage.eINSTANCE);
set.getResourceFactoryRegistry().getExtensionToFactoryMap().put(UMLResource.FILE_EXTENSION, UMLResource.Factory.INSTANCE);
Resource resource = set.getResource(URI.createFileURI(new File(umlModelFilename).getAbsolutePath()), true);
resource.load(null);
UMLResource umlResource = (UMLResource)resource;

By looking at the XMIs they references the profile as "/projectname/src/main/resources/the.profile.uml" (yes, that's a Maven structure, the standalone app is a Maven plugin...).
If I change that to "the.profile.uml" everything works just fine, I guess I'm just cheating the resource loader.
Anyway: which is the clean and correct way to deal with this situation?
Thanks.

Re: Standalone: load profile from Papyrus models [message #1777405 is a reply to message #1777371]

Wed, 29 November 2017 03:49

Eclipse User

Hi

You don't provide an adequate repro for what is probably a subtle issue, so I have to guess.

Maven does not reference "/projectname/src/main/resources/the.profile.uml". Your generator happens to use that form, possibly because the save occurred as part of an EMF application when the current directory was platform:/resource/anotherprojectname/... Although I would have expected EMF to use ../../ relative navigation. I'm probably guessing wrong.

Once you expect a reader to handle "/projectname/src/main/resources/the.profile.uml" you must make sure that it is resolved with respect to a current file the at applies the missing "platform:/resource" and then can locate it. Thios requires careful inuitialization possibly using EcorePlugin.ExtensionProcessor to analyze your classpath.

Since you actually wanted to resolve in the same folder you appear to have dug a deep hole, so rather than explain the ways out it would be better to not get into the hole in the first place. You give no clues as to what the value of "umlModelFilename" so it is hard to be more helpful. I suggest you formulate your problem as a standalone JUnit test to avoid any Maven-complexities. You can post the JUnit as a zipped project and then get a more informative answer.

Regards

Ed Willink

Re: Standalone: load profile from Papyrus models [message #1777431 is a reply to message #1777405]

Wed, 29 November 2017 06:01

Eclipse User

Ed, thanks for the reply.
I really do not know how to provide a standalone JUnit test without all the boilerplate (UML2 jars are not pushed in public Maven repos so I need to have them in the project and registers them locally, which makes a simple project with just a JUnit test huge). Suggestions are appreciated.

Anyway, Maven has nothing to do with "/projectname/src/main/resources/the.profile.uml" that is how the profile is referenced from the XMIs as saved from Papyrus (the src/main/resources is due to the fact that I'm using the standard Maven conventions for resource files).
Here is a simple example with a minimal foobar profile (two stereotypes extending UML::Class: Foo and Bar):

<?xml version="1.0" encoding="UTF-8"?>
<uml:Profile xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xmi:id="_mEFw4NTuEeeLGPq0HQs1xA" name="RootElement" metaclassReference="_nQn1cNTuEeeLGPq0HQs1xA">
  <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_t_h9cdTuEeeLGPq0HQs1xA" source="http://www.eclipse.org/uml2/2.0.0/UML">
    <contents xmi:type="ecore:EPackage" xmi:id="_t_ikgNTuEeeLGPq0HQs1xA" name="RootElement" nsURI="http:///schemas/RootElement/_t_h9cNTuEeeLGPq0HQs1xA/0" nsPrefix="RootElement">
      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_t_jLktTuEeeLGPq0HQs1xA" source="PapyrusVersion">
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_t_jLk9TuEeeLGPq0HQs1xA" key="Version" value="0.0.1"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_t_jLlNTuEeeLGPq0HQs1xA" key="Comment" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_t_jLldTuEeeLGPq0HQs1xA" key="Copyright" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_t_jLltTuEeeLGPq0HQs1xA" key="Date" value="2017-11-29"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_t_jLl9TuEeeLGPq0HQs1xA" key="Author" value=""/>
      </eAnnotations>
      <eClassifiers xmi:type="ecore:EClass" xmi:id="_t_ikgdTuEeeLGPq0HQs1xA" name="Foo">
        <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_t_ikgtTuEeeLGPq0HQs1xA" source="http://www.eclipse.org/uml2/2.0.0/UML" references="_n7VmYNTuEeeLGPq0HQs1xA"/>
        <eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_t_ikg9TuEeeLGPq0HQs1xA" name="baz" ordered="false" lowerBound="1">
          <eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/5.0.0/Types#//String"/>
        </eStructuralFeatures>
        <eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_t_ikhdTuEeeLGPq0HQs1xA" name="base_Class" ordered="false" lowerBound="1">
          <eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/5.0.0/UML#//Class"/>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xmi:type="ecore:EClass" xmi:id="_t_ikh9TuEeeLGPq0HQs1xA" name="Bar">
        <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_t_ikiNTuEeeLGPq0HQs1xA" source="http://www.eclipse.org/uml2/2.0.0/UML" references="_olfWoNTuEeeLGPq0HQs1xA"/>
        <eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_t_ikidTuEeeLGPq0HQs1xA" name="bam" ordered="false" lowerBound="1">
          <eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/5.0.0/Types#//String"/>
        </eStructuralFeatures>
        <eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_t_iki9TuEeeLGPq0HQs1xA" name="base_Class" ordered="false" lowerBound="1">
          <eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/5.0.0/UML#//Class"/>
        </eStructuralFeatures>
      </eClassifiers>
    </contents>
  </eAnnotations>
  <elementImport xmi:type="uml:ElementImport" xmi:id="_nQn1cNTuEeeLGPq0HQs1xA" alias="Class">
    <importedElement xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
  </elementImport>
  <packageImport xmi:type="uml:PackageImport" xmi:id="_mHylINTuEeeLGPq0HQs1xA">
    <importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/>
  </packageImport>
  <packageImport xmi:type="uml:PackageImport" xmi:id="_mHylIdTuEeeLGPq0HQs1xA">
    <importedPackage xmi:type="uml:Model" href="pathmap://UML_METAMODELS/UML.metamodel.uml#_0"/>
  </packageImport>
  <packagedElement xmi:type="uml:Stereotype" xmi:id="_n7VmYNTuEeeLGPq0HQs1xA" name="Foo">
    <ownedAttribute xmi:type="uml:Property" xmi:id="_pQBhYNTuEeeLGPq0HQs1xA" name="baz">
      <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>
    </ownedAttribute>
    <ownedAttribute xmi:type="uml:Property" xmi:id="_s6Af0dTuEeeLGPq0HQs1xA" name="base_Class" association="_s5_4wNTuEeeLGPq0HQs1xA">
      <type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type="uml:Stereotype" xmi:id="_olfWoNTuEeeLGPq0HQs1xA" name="Bar">
    <ownedAttribute xmi:type="uml:Property" xmi:id="_p9uU4NTuEeeLGPq0HQs1xA" name="bam">
      <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>
    </ownedAttribute>
    <ownedAttribute xmi:type="uml:Property" xmi:id="_tcHuYNTuEeeLGPq0HQs1xA" name="base_Class" association="_tcF5MNTuEeeLGPq0HQs1xA">
      <type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type="uml:Extension" xmi:id="_s5_4wNTuEeeLGPq0HQs1xA" name="E_Foo_Class1" memberEnd="_s6Af0NTuEeeLGPq0HQs1xA _s6Af0dTuEeeLGPq0HQs1xA">
    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_s6Af0NTuEeeLGPq0HQs1xA" name="extension_Foo" type="_n7VmYNTuEeeLGPq0HQs1xA" aggregation="composite" association="_s5_4wNTuEeeLGPq0HQs1xA"/>
  </packagedElement>
  <packagedElement xmi:type="uml:Extension" xmi:id="_tcF5MNTuEeeLGPq0HQs1xA" name="E_Bar_Class1" memberEnd="_tcHHUNTuEeeLGPq0HQs1xA _tcHuYNTuEeeLGPq0HQs1xA">
    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_tcHHUNTuEeeLGPq0HQs1xA" name="extension_Bar" type="_olfWoNTuEeeLGPq0HQs1xA" aggregation="composite" association="_tcF5MNTuEeeLGPq0HQs1xA"/>
  </packagedElement>
</uml:Profile>

the profile is stored as foobar/src/main/resources/foobar.profile.uml (foobar is the project root).
So far so good.
Now I use Papyrus to create a UML model (class diagram) referencing the profile (just a single Baz class with Foo stereotype applied). This is the resulting XMI stored as foobar/src/main/resources/foobar.uml:

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:RootElement="http:///schemas/RootElement/_t_h9cNTuEeeLGPq0HQs1xA/0" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xsi:schemaLocation="http:///schemas/RootElement/_t_h9cNTuEeeLGPq0HQs1xA/0 /foobar/src/main/resources/foobar.profile.uml#_t_ikgNTuEeeLGPq0HQs1xA">
  <uml:Model xmi:id="_TUoysNTvEeeLGPq0HQs1xA" name="RootElement">
    <packageImport xmi:type="uml:PackageImport" xmi:id="_TVoRMNTvEeeLGPq0HQs1xA">
      <importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/>
    </packageImport>
    <packagedElement xmi:type="uml:Class" xmi:id="_c5S4cNTyEeeLGPq0HQs1xA" name="Baz"/>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="_TU3cMNTvEeeLGPq0HQs1xA">
      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_TU4qUNTvEeeLGPq0HQs1xA" source="PapyrusVersion">
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_TU4qUdTvEeeLGPq0HQs1xA" key="Version" value="0.0.1"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_TU4qUtTvEeeLGPq0HQs1xA" key="Comment" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_TU4qU9TvEeeLGPq0HQs1xA" key="Copyright" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_TU4qVNTvEeeLGPq0HQs1xA" key="Date" value="2017-11-29"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_TU4qVdTvEeeLGPq0HQs1xA" key="Author" value=""/>
      </eAnnotations>
      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_TU4DQNTvEeeLGPq0HQs1xA" source="http://www.eclipse.org/uml2/2.0.0/UML">
        <references xmi:type="ecore:EPackage" href="/foobar/src/main/resources/foobar.profile.uml#_t_ikgNTuEeeLGPq0HQs1xA"/>
      </eAnnotations>
      <appliedProfile xmi:type="uml:Profile" href="/foobar/src/main/resources/foobar.profile.uml#_mEFw4NTuEeeLGPq0HQs1xA"/>
    </profileApplication>
  </uml:Model>
  <RootElement:Foo xmi:id="_eVCdsNTyEeeLGPq0HQs1xA" base_Class="_c5S4cNTyEeeLGPq0HQs1xA"/>
</xmi:XMI>

The trouble here is the references to the profile in the form of "/foobar/src/main/resources/foobar.profile.uml" (which, BTW, are translated by the URIConverter in the standalone setup as "file:/foobar/src/main/resources/foobar.profile.uml").
With this setup the stereotypes are lost: if I query the Baz class for stereotypes it say no one is applied.
As a side-note, since the application is a Maven plugin the working directory is foobar, the root of the project.

Re: Standalone: load profile from Papyrus models [message #1777434 is a reply to message #1777431]

Wed, 29 November 2017 06:21

Eclipse User

Hi

When you use Papyrus (inside Eclipse) you use the Eclipse OSGI support that ensures that platform:/resource and platform/plugin are virtual file locations. This works nicely for interchange between Eclipse applications.

However as soon as you move to standalone (JUnit or Maven) you lose the virtual root and file: is very rarely a good substitute. Much the easiest approach is to have all your model files in the same folder avoiding all folder qualifiers, else the same tree so that relative qualifiers work. As soon as you have two trees you are in trouble. For OCL, I developed GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.pivot\src\org\eclipse\ocl\pivot\internal\resource\StandaloneProjectMap.java that analyzes the classpath and initializes EMF registries so that the platform: virtual root is available. Subsequently the EcorePlugin.ExtensionProcessor evolved to do many, but not all, of the same things.

I strongly suggest that you use the UML getting started tutorials to become familiar with UML and JUnit before you add the additional but ultimately similar Maven complexity.

Regards

Ed Willink

Re: Standalone: load profile from Papyrus models [message #1777441 is a reply to message #1777434]

Wed, 29 November 2017 07:10

Eclipse User

Thanks Ed, I will give a look to your code.
Now I'm investigating where in the emf/uml2 code the profile is resolved and the actual file loaded. Any suggestion for a starting point?

However, let me point out that I do not have two trees, the profile file and the UML file are stored in the same directory (but this is not the project's root directory).
Also notice that is not up to me to use relative qualifiers because the qualifiers are put there by Papyrus when you apply a profile to a model (and I want people to use Papyrus to create their models so I have to live with that).

I also do not understand you suggestion to give a look at the getting started tutorials, I have no issues running my code from within Eclipse (as is the case for the tutorials) and I also have no issues with running my code from Maven, other than this specific profile resolution problem. And my JUnit code runs just fine from Maven too (yet again, apart from profile resolution).

Re: Standalone: load profile from Papyrus models [message #1777449 is a reply to message #1777441]

Wed, 29 November 2017 08:04

Eclipse User

Hi

You did not share a repo so you should not complain if my guesses miss the point.

I find that instrumenting the ResourceImpl constructor is a good start towards seeing what is going on.

Regards

Ed Willink

Re: Standalone: load profile from Papyrus models [message #1777477 is a reply to message #1777449]

Wed, 29 November 2017 10:01

Eclipse User

Ed Willink wrote on Wed, 29 November 2017 08:04

Hi

You did not share a repo so you should not complain if my guesses miss the point.

Ahah, you are right. it looks like I'm asking for guesses and complaining about the replies. It's only that I thought this was a very standard case, I'm just trying to use uml2 standalone with Papyrus models....

Ed Willink wrote on Wed, 29 November 2017 08:04

I find that instrumenting the ResourceImpl constructor is a good start towards seeing what is going on.

Will do as suggested.

Re: Standalone: load profile from Papyrus models [message #1777484 is a reply to message #1777477]

Wed, 29 November 2017 10:54

Eclipse User

Hello

I have a good experience with standalone loading of UML/Papyrus models with applied profiles, all my projects are built with maven, I use the maven directory structure ( src/main/resources), and have never encountered the problem you have.

I think that your problem boils down to the absolute URI reference from the model to the profile.

Quote:

form of "/foobar/src/main/resources/foobar.profile.uml"

I have never seen that before, specially if the model and the profile are in the same directory.

I just tested your small example (with Papyrus Neon in a maven project ) and this is what the model looks like in my workspace

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:RootElement="http:///schemas/RootElement/_t_h9cNTuEeeLGPq0HQs1xA/0" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xsi:schemaLocation="http:///schemas/RootElement/_t_h9cNTuEeeLGPq0HQs1xA/0 foobar.profile.uml#_t_ikgNTuEeeLGPq0HQs1xA">
  <uml:Model xmi:id="_X42ysNUZEeemb61hkonb3g" name="RootElement">
    <packagedElement xmi:type="uml:Class" xmi:id="_Nht4YNUcEeemb61hkonb3g" name="Baz"/>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="_rgxGENUcEeemb61hkonb3g">
      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_rgxGEtUcEeemb61hkonb3g" source="PapyrusVersion">
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_rgxGE9UcEeemb61hkonb3g" key="Version" value="0.0.1"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_rgxGFNUcEeemb61hkonb3g" key="Comment" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_rgxGFdUcEeemb61hkonb3g" key="Copyright" value=""/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_rgxGFtUcEeemb61hkonb3g" key="Date" value="2017-11-29"/>
        <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_rgxGF9UcEeemb61hkonb3g" key="Author" value=""/>
      </eAnnotations>
      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_rgxGEdUcEeemb61hkonb3g" source="http://www.eclipse.org/uml2/2.0.0/UML">
        <references xmi:type="ecore:EPackage" href="foobar.profile.uml#_t_ikgNTuEeeLGPq0HQs1xA"/>
      </eAnnotations>
      <appliedProfile xmi:type="uml:Profile" href="foobar.profile.uml#_mEFw4NTuEeeLGPq0HQs1xA"/>
    </profileApplication>
  </uml:Model>
  <RootElement:Foo xmi:id="_tTzxANUcEeemb61hkonb3g" base_Class="_Nht4YNUcEeemb61hkonb3g"/>
</xmi:XMI>

Notice the relative URI
Quote:

href="foobar.profile.uml#_mEFw4NTuEeeLGPq0HQs1xA"

that is then resolved properly by the ResourceSet.

So before going further, I will advise you to try to figure out how you ended up with an absolute URI in Papyrus.

Regards
German Vega

Re: Standalone: load profile from Papyrus models [message #1777489 is a reply to message #1777484]

Wed, 29 November 2017 11:38

Eclipse User

Hi German,
thanks a lot for sharing your experience and thanks a lot for trying my files in your environment.

It looks like if you apply the profile from the "New Papyrus Model" wizard (bottom of last screen) you get those weird "/foobar/src/main/resources/foobar.profile.uml" references.

If you create the model without profile and you apply it later you get the more friendly "foobar.profile.uml" references.

Hard to say if that's a bug or it's by design. From within Eclipse both references work just fine, maybe I could try asking to the Papyrus guys...

Re: Standalone: load profile from Papyrus models [message #1777491 is a reply to message #1777489]

Wed, 29 November 2017 11:48

Eclipse User

Hi

I suspect it's a Papyrus problem. If you have a repro it can be fixed.

EMF normally saves references using relative paths, so it often works very portably. Perhaps Papyrus has neglected to deresolve a URI with respect to its container.

Regards

Ed Willink

Re: Standalone: load profile from Papyrus models [message #1777513 is a reply to message #1777491]

Wed, 29 November 2017 15:41

Eclipse User

Hi

I confirm that the bug happens when applying the profile with the new model wizard.

I agrre with Ed that it is most probably a bug in Papyrus, because not only it generates an absolute URI, but additionally it doesn't have a scheme.

This works well when running on eclipse because the standard EMF URI converter normalizes scheme-less URIs to "platform:/resource" URIs.

But in the case of standalone execution, it normalizes scheme-less URIs to an absolute "file:" URI that is wrong most of the time

  /**
   * Returns the normalized form of the URI.
   * <p>
   * This implementation does precisely and only the {@link URIConverter#normalize typical} thing.
   * It calls itself recursively so that mapped chains are followed.
   * </p>
   * @param uri the URI to normalize.
   * @return the normalized form.
   * @see org.eclipse.emf.ecore.plugin.EcorePlugin#getPlatformResourceMap
   */
  public URI normalize(URI uri)
  {
    String fragment = uri.fragment();
    String query = uri.query();
    URI trimmedURI = uri.trimFragment().trimQuery();
    URI result = getInternalURIMap().getURI(trimmedURI);
    String scheme = result.scheme();
    if (scheme == null)
    {
      if (workspaceRoot != null)
      {
        if (result.hasAbsolutePath())
        {
          result = URI.createPlatformResourceURI(result.toString(), false);
        }
      }
      else
      {
        if (result.hasAbsolutePath())
        {
          result = URI.createURI("file:" + result);
        }
        else
        {
          result = URI.createFileURI(new File(result.toString()).getAbsolutePath());
        }
      }
    }

I think EMF does its best-effort to try to resolve the absolute scheme-less URI ... so the bug is mostly in the Papyrus wizard that loads the profile with a non-portable URI

Re: Standalone: load profile from Papyrus models [message #1777516 is a reply to message #1777513]

Wed, 29 November 2017 16:08

Eclipse User

Hi again Davide,

You mentioned that your application is a maven plugin, so you have access to the project name and the project root directory.

So I was thinking that, as a workaround, you can add an URI mapping to your resource set :

file:/<projectname>/ => file:/<absolute path to project root directory>/

I haven't tried it, but should work

Regards

German

Re: Standalone: load profile from Papyrus models [message #1777595 is a reply to message #1777516]

Thu, 30 November 2017 11:15

Eclipse User

German Vega wrote on Wed, 29 November 2017 16:08

Hi again Davide,
I haven't tried it, but should work

Very well possible but I see a lot of corner cases... waiting to know if that's a Papyrus issue I'm going to support only profiles not applied in the creation wizard.

[Updated on: Thu, 30 November 2017 18:54] by Moderator

Previous Topic:	Standalone program : error loading old model (ns=http://www.eclipse.org/uml2/2.1.0/UML)
Next Topic:	Connect StateInvariant to a State

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 17 06:24:15 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter