Splitting profiles into multiple emfprofile_diagram files.

[JP]

Hi there. Let me congratulate you on EMF profiles, it's a great idea, and I believe it will be very useful for a broad audience.

I am just starting to play with them.

What I am now trying to do is to create a more elaborated profile, which I need to split between several emfprofile_diagram files.

I define all theses files within the same EMF_Profile project (I had to copy-paste emfprofile_diagram files and delete all its elements to create new profile definitions, as no wizard is currently available to create one from scratch).

The stereotypes in the root profile reference stereotypes from the other profiles from within its properties.

However, by doing this, the profiles is never registered and, therefore, can't be applied.

I tried adding the different emfprofile_diagram files to the build properties, to no avail.

Is there a way to do this?, perhaps defining each profile in its own project?, or it is currently unfeasible?

Thanks in advance for you answer.

Regards,

              JP

[jpsilva...@gmail.com]

Nevermind, I managed to make it work.

If you want to apply the different profiles independently, while still defining them within the same project, you may add each one in the extension point declaration in plugin.xml:

  <extension point="org.modelversioning.emfprofile.profile">

     <profile profile_resource="XXX.emfprofile_diagram"/>

     <profile profile_resource="AnotherXXX.emfprofile_diagram"/>

  </extension>

Regards,

             JP

[Philip Langer]

Hi,

sorry for the delay... thanks a lot for your nice feedback!

Good to hear that you managed to address your problem. That is exactly the solution I was going to propose. Currently there is no user interface to allow creating and having more than one profile per profile project, but it can be done manually as you pointed out!

Don't hesitate to answer any additional questions! We also appreciate any further feedback, issue reports, and feature requests!

Best wishes,

Philip

[jpsilva...@gmail.com]

Thanks for your answer, Philip.

Just one further question. 

I'm trying to reference instances of a metamodel (I am planning to use a model as a library of instances) from within a profile, to be able to specify the actual specific values of all properties.

However, this is being causing me problems (the profile doesn't show up as a registered profile in runtime workspaces, I can not see the model instances from my profile application even though I load the resource in the editor, etc.).

Is this feasible?

I am trying to use these mode instances to completely specify a different set of property values which usually go together, instead of having to specify them for each profile application.

Would you suggest an alternative approach?

Thanks in advance,

                            JP

[Philip Langer]

Hi again,

yes, it should be possible to reference model elements from profile applications (we did that already in some projects). Basically, therefore you would need to add EReferences to your Stereotypes; once this is done, a stereotype application should be able to refer to a model element conforming to the respective eType of the EReference. The referenced model element is set in the properties view as usual. This model element can theoretically be located in the annotated model, in the profile application model, or in any other model (you'd have to load an additional resource in your editor though). With the new version of EMF Profiles it is also possible to add model elements that are contained by stereotype applications; that is, the stereotype has a containment reference to an EClass and then you can add a contained model element to a stereotype application by right-clicking the stereotype application in the profile application view.

When your profile doesn't show up in the registered profile view, this is most likely due to validation errors. Only valid profiles show up there, so please try to validate your profile and see if there are any violations in your profile diagram.

Let me know if you have any further issues or questions!

Best wishes,

Philip

[jpsilva...@gmail.com]

Hi Philip, thanks again for your answer.

The approaches you suggest are great.

Th first one is the one I was trying out, but I believe it was a problem of the class I placed the EReference to. I will check that.

The second suggestion is very promising, I don't know which is best in my case, but I liked your idea.

On the registered profiles issue, the profile validates and appears in the current workspace's registered profiles view. 

It just doesn't appear in the runtime's registered profiles view. All MM from which it depends should be present there (as they are in the workspace), so I don't know what's going wrong.

Is not a big thing, as I can use the profile in my workspace.

Regards,

             JP

[Philip Langer]

My answers are inline...

On Thursday, April 18, 2013 10:22:57 AM UTC+2, jpsilva...@gmail.com wrote:

Hi Philip, thanks again for your answer.

The approaches you suggest are great.

Th first one is the one I was trying out, but I believe it was a problem of the class I placed the EReference to. I will check that.

The second suggestion is very promising, I don't know which is best in my case, but I liked your idea.

Well, the typical use case for the second approach (having containment references) is when you want to store more complex data in a stereotype application instead of primitive data tagged values only, whereas this data still "belongs" to the stereotype application; that is, when the stereotype application is deleted the complex data within the stereotype should be deleted as well. The first approach is more useful when you want to link stereotype applications not only to the model element to which the stereotype is applied but also to other model elements either in the annotated or any other model, whereas these model elements exist independently from the stereotype application.

On the registered profiles issue, the profile validates and appears in the current workspace's registered profiles view. 

It just doesn't appear in the runtime's registered profiles view. All MM from which it depends should be present there (as they are in the workspace), so I don't know what's going wrong.

Is not a big thing, as I can use the profile in my workspace.

Ah, I see. With runtime's registered profiles view, you mean you have an Eclipse instance ("host") where you have a profile project and you start an Eclipse application out of this Eclipse instance and, in this instance, the profile (of the host Eclipse instance profile project) doesn't show up in the registered profiles view? Actually, that should work... maybe a reason why this is not working out for you is the reference to "external" metaclasses that you have imported; how are the metaclasses referenced in the profile_diagram file (best way is to check when you have a look at the XMI)? Are the metaclasses referenced through namespace URI only? Or through platform or file URIs? In case of platform or file URIs, I guess that the referenced metaclasses cannot be resolved in the runtime Eclipse instance. If they are referenced through namespace URIs only and the namespaces are correctly registered in the EPackage registry of the runtime Eclipse instance, this should work, but maybe there is a bug around the BundleProfileProvider. In this case, it would be great if you could file an issue with a sample that causes the bug; then we can look into that.

Hope that helps!

Philip

[Juan Pedro Silva Gallino]

Exactly that, Philip, you nailed.

I had just found the cause myself also.

I had to import the profile to my runtime Eclipse Application to realize that I had imported the referenced classes from the workspace and not ass registered metaclasses.

Everything seems to work fine now, so I guess BundleProfileProvider is not buggy. ;-)

Thanks for your help!

2013/4/18 Philip Langer <p.la...@gmail.com>

--

El contenido de esta comunicación es estrictamente CONFIDENCIAL y se dirige exclusivamente al destinatario, estando protegido por el secreto profesional. Si recibe este e-mail por error, se ruega lo devuelva urgentemente al remitente. Gracias. Según la LO15/1999 de 13 de diciembre, de protección de datos de carácter personal, sus datos serán tratados con absoluta confidencialidad, siendo únicamente cedidos a terceros, cuya intervención sea necesaria para satisfacer las necesidades pactadas. Tiene Vd. el derecho de acceder a ellos, modificarlos o cancelarlos dirigiéndose a: Juan Pedro Silva Gallino, ETSIT de Telecomunicación, Avda. Complutense, s/n, Edificio B, B-324, 28040, Madrid

The information contained in this communication is strictly CONFIDENTIAL and is exclusively intended for the addressee, being professional confidentiality. If you receive this e-mail by mistake, please re send it urgently to the sender. Thank you. As set by law 15/1999 December 13, regarding personal information protection , your own personal information will be handled with complete confidentiality, and will be only shared with third parties when necessary to satisfy the terms agreed. You have the right to access, modify and cancel them contacting:  Juan Pedro Silva Gallino, ETSIT de Telecomunicación, Avda. Complutense, s/n, Edificio B, B-324, 28040, Madrid, (Spain).

AVISO: La comunicación por correo electrónico presenta riesgos de pérdida de información y de acceso no autorizado. Entendemos que existe conformidad para el uso del correo electrónico por todo aquel que lo utilice en las comunicaciones con el Dr. Juan Pedro Silva Gallino.

WARNING: The use of e-mail has risks of information loss and of unauthorised access. We assume that conformity to the use of e-mail is granted by anyone using it as means of comunication with Dr. Juan Pedro Silva Gallino.

[Juan Pedro Silva Gallino]

Philip, what is causing the issu is precisely what you said: when referencing metaclasses, although imported through registered namespaces, the href is saved in the profile as a platform URI (e.g., href="/NRL_SecurityOntology/model/nrl_SecurityOntology.ecore#_tOdhsKKxEeKsGLMxtzQWtA") instead of a namespace URI.

Would you like me to send you my profiles and model instances?

Cheers,

               JP

2013/4/18 Philip Langer <p.la...@gmail.com>

[Philip Langer]

Hi again,

ok, that shouldn't be! Maybe this is a bug.

How did you load the metaclasses that were causing the problems? Did you use the context menu action "Import metamodel element..."? Did you select an already registered EPackage?

I just tested tihs with the most current version in the develop branch by importing Ecore's EClass and there the href only was the namespace-based URI (no platform URI)... but still it might be a bug.

Thanks for the info and best wishes,

Philip

[Juan Pedro Silva Gallino]

Philip, I just recreated the following steps and I can confirm the issue:

1) Create and Ecore (meta) model, set the desired namespace, create some classes.

2) Open the ATL perspective.

3) In the Project Explorer, right-click on the ecore model, select "Register Metamodel". 

4) On the same Eclipse instance ("host") and workspace, create a new EMF Profile project.

5) Open the profile diagram, define a new stereotype.

6) Right-click on the diagram, select "Import Metamodel Element"

7) Select the namespace that was set on step 1.

8) Select any of the defined classes.

9) Select "Extension" from the profile diagram Palette, and make your stereotype an extension of the class defined in the metamodel.

10) Save your profile.

11) Open your profile with a text editor.

12) Search for the "target" tag within your  "extensions" tag. 

13) The value of the "href" property is a workspace relative path, not a namespace-based URI.

I am running version 1.0.0 of EMF Profiles' Edit and Editor plugins, and version 1.1.0 of EMF Profiles' Model plugin, all this on an Eclipse Modeling Juno win 64 bits.

Regards,

                  JP

[Philip Langer]

Thanks a lot for this detailed report! I'll look into that on the weekend and let you know if it is solvable easily!

Thanks again and best wishes,

Philip

[Juan Pedro Silva Gallino]

Your welcome, Philip.

Don't worry about it, there is no rush for me (enjoy your weekend!).

I can change the reference by hand, no problem.

I reported it as you may consider changing this for your next release.

Regards,

                  JP

2013/4/19 Philip Langer <p.la...@gmail.com>

[Philip Langer]

Hi Juan Pedro,

I opened an issue on that matter and committed a fix. See https://code.google.com/a/eclipselabs.org/p/emf-profiles/issues/detail?can=2&q=35&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&id=35

As commented there, I'm not sure whether I found a good solution, but it should work now for your use case.

Have a nice weekend,

Philip

[Juan Pedro Silva Gallino]

Thanks very much, Philip.

I hope is ok for everyone, and there is no need to change it back.

Regards,

             JP

2013/4/20 Philip Langer <p.la...@gmail.com>