Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Mekugi

Pages: [1]
1
Found workaround for ~/.p4scc: setting the file in read-only mode allows to get some traces:

  • add -f package.xml
    package.xml #1 - opened for add
  • fstat -Olhp
    {1 additional argument(s) suppressed}
  • edit package.xml
    package.xml - can't edit (already opened for add)
  • fstat -Olhp
    {1 additional argument(s) suppressed}

Unfortunately, the output of fstat is not logged.

It looks like the submit command is not sent.

2
In sequence diagrams, it looks like it is not possible to bind the return value of a message to an enumeration attribute with EA 12.0.

For example:

typedef enum {
  VALUE1,
  VALUE2
} MyEnum;

MyEnum getMyEnum(void);

In the sequence diagram, some actor calls getMyEnum(), which returns VALUE1.

Although it is possible to specify the return value VALUE1 in the message dialog, I did not find a syntax to link it to the actual attribute value in MyEnum, so that if VALUE1 is renamed in MyEnum, the diagram gets automatically modified (the same way as if the method name itself was modified).


3
There is a settings file to activate P4SCC logs in ~/.p4scc, but it looks like EA (or maybe P4SCC itself) is systematically rewriting the file with "LogFile=no"  :(

4
Bugs and Issues / P4SCC issue: Configuration of package into p4scc failing
« on: February 10, 2016, 06:35:54 pm »
Using EA 12.0, I am trying to configure a package into version control using P4SCC.

- The Version Control settings look ok
- The Version Control and XMI Filename in the Package Control Options dialog look ok
- The P4SCC popup to select the location in the depot is ok (overlays are being used)
- The file is properly marked for addition in the Perforce pending changelist

But the file is not submitted and the configuration fails with a popup reading "File was not added".
Unfortunately, there are no traces in System Output window.

What is puzzling is that the file is actually in the Perforce changelist, so it shows that the configuration is not completely wrong.
Does anyone know of a way to investigate (e.g. increase log verbosity or find logs anywhere else)?

5
General Board / Re: Relative path in package control options
« on: January 22, 2015, 02:19:08 am »
No, it is in the application data of your local user profile.

6
General Board / Re: Relative path in package control options
« on: January 17, 2015, 12:13:25 am »
Very pertinent remark.

Thanks!

7
General Board / Re: Relative path in package control options
« on: January 16, 2015, 08:54:25 pm »
@qwerty: interesting, I thought the local paths were stored somewhere in the registry, like the version control settings.

I might be able to hook a script to the open project event and that would patch the path.txt file...

Thx

8
General Board / Re: Relative path in package control options
« on: January 16, 2015, 06:17:18 pm »
Thank you for the answers.

@Simon: yes, as stated in the original post, it is possible to define a local path and associate it to an id. But these are all absolute paths and are apparently shared by all EA projects.

@qwerty: Purpose is to be able to properly use a same controlled package present in different locations on the hard drive, from different EA projects. Hence I wanted to be able to use a path relative, for example, to the location of the EA project file; alternative could be to use a local path that would be project-specific, but does this exist?

Mekugi

9
General Board / Relative path in package control options
« on: January 16, 2015, 04:17:13 am »
Hi,

In an attempt to workaround an issue with version-controlled shared packages in EA 11.1 (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1421225830), I would like to use package control without version control (packages represented with the red box on the left side).

I noticed that it was possible to use "Local Paths" IDs when specifying the XMI file name in the Package Control Options window (Ctrl+Alt+P), using %ID%.
I was wondering if there were other EA macros that could be used in that context, such as the .eap project path, or the path of the containing package's XMI file?

Thank you by advance

10
General Board / Re: Version control with shared packages
« on: January 15, 2015, 06:44:03 pm »
Geert,

That is indeed a possibility, but this comes with the cost of having to manually maintain the consistency between the baselines of the model and the source code, which I wanted to avoid.

Mekugi

11
General Board / Re: Version control with shared packages
« on: January 15, 2015, 01:09:05 am »
Hello Geert,

Thank you for the answer.

Maybe "project" was not the proper term to use in that context. I did not mean EA projects, but customer application projects (although application projects use different EA projects  :D).
Let's use "applications".

There are 2 axis:
- applications
- branches
Let's set the branches aside for the moment.


In my context, several applications share some packages.
Each application has its own Perforce workspace and local project path, as well as a EA .eap file  (not under SCC).

So for application appA:
- the package is located in ~/appA/sharedPackage.xmi to be checked out through Perforce workspace appA and the EA project is ~/appA/appA.eap
And for application appB:
- the package is located in ~/appB/sharedPackage.xmi to be checked out through Perforce workspace appB and the EA project is ~/appB/appB.eap

When I use appA.eap, I would like the package to be read from  ~/appA/sharedPackage.xmi and when I use appB.eap, I would like the package to be read from  ~/appB/sharedPackage.xmi.

Of course, I will not modify the package simultaneously from both EA project, as sharedPackage.xmi is protected by an exclusive lock.


As the Version Control Setting is located in the windows' registry, the information it contains will be valid only for one of the two applications.
And I cannot use two different Version Control Settings as these would need to have the same unique identifier.

Hope this clarifies the configuration I am using and the sought target.

Cheers,
Mekugi

12
General Board / Version control with shared packages
« on: January 14, 2015, 07:57:10 pm »
Hi,

I am trying to figure out how to use the version control capability of EA 11.0 to manage an EA package shared by different projects on different development branches.

I am using Perforce as a source code control application through its SCC-compliant plugin.
Each project has its own local project path and Perforce codeline.
I am using the multiple private model mode where each user has a own .eap file for each single project.


My understanding is that the package shall have its own unique identifier for the version control and I intended to use a version control setting for the package.

The problem here is that EA links the unique identifier to a single SCC configuration stored in the registry rather than in the EAP file.
Said version control setting contains information about the local project path and the Perforce codeline used to checkin/checkout the package.
Consequently, this setting cannot be used by 2 different projects in different local paths and possibly using different branches.

Is there any way to configure EA to suits the need of sharing a version-controlled package between different projects?

Thank you by advance.

13
@PSOSSA: I have the impression that the "working folder" you mentioned is set to the folder of the last file EA reads or writes. So if files in different folders are used, the "working folder" would change during EA's lifetime. Did you observe the same behavior?

Pages: [1]