Issues with model merging

Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
While model merging works with our ClientServer project, it does not work with the BasicPubSub project. When trying to accomplish an end-to-end verification of the modeling tool we were able to successfully merge a ClientServer model following instructions from Ernesto’s videos. Following the same instructions, we moved onto our BasicPubSub example which has a module instantiation and the DDS_DCPS profile inside of it. In this merging scenario, the comparison became overrun with errors (null pointer exceptions, Papyrus crashing, etc.) and we weren’t able to successfully merge. We have seen cases where a branch to branch merging of the BPS models worked flawlessly. But by simply reversing the merge between the branches, things went haywire. Even when things appeared successful, we clicked save and the model changes never saved to the file system. These model merges were very simple (a single small modification to the deployment plan or adding a type to a message).

Hi @j26151,
It's been a while, but the tests I did with BasicPubSub_new from the git repo worked. Is this a different model? If so, can you attach it or send it to me?
Also, the videos are outdated. The reference guide is this one: https://github.com/ZeligsoftDev/CX4CBDDS/blob/papyrus/doc/compare/papyrus-compare-guide.md. If you already saw that guide, did you do the setup as described there?
Thanks

@eposse I did do the setup as described in your guide. I have attempted numerous different ways for comparing/merging models. Specifically, I am interested in the merging use case at the moment. I have attached a zip file with models that I currently have not been able to merge. If you meld/compare all three of them together using a text comparison you will see how simple the change is. the ".branchA" and ".branchB" both had a different field added to a message. The ".master" file is where both branchA and branchB started from.
PubSubExample.zip

Hi @j26151. Thanks. I see that the files in the zip archive are the .uml files. In order to reproduce the problem can you attach the full Papyrus models (including the .di and .notation files)?
Also, were you merging branchA onto branchB or viceversa? (It's just to try to reproduce the problem as closely as you are experiencing it.)
Thanks

Specifically, I was having troubles merging branchB into branchA
ForZeligsoft.zip

Thanks. I'll take a look and let you know what I find.

Hi @j26151
I've had some mixed results.
First, I cannot reproduce the same behaviour with exception pop-ups that you described, but I've ran into other issues.
I did my experiments on a fresh Papyrus 4.4 with a fresh build of Papyrus CX, the latest from the papyrus branch.
I've experienced the same as issue #170.
But before that I tried merging branch B into branch A (I'm attaching a tiny git repo with the models you sent) and the merge didn't crash or resulted in exception pop-ups, but it stopped with a conflict. When I opened the conflicting file with the Merge Tool, it didn't show anything on the structural view but instead just showed an error, and produced an exception recorded in the Error Log. (See attached file at the bottom). I've never seen this kind of exception before.
So, can I ask you to try with the git repo attached?  (issue193.zip)
Try it in a fresh install.
Before you try the test, clean up the Error Log, by selecting Window->Show View->Other...->General->Error Log, and then, in the Error Log view (in the bottom) click the "Delete Log" button (a red X). See the screen shot at the bottom.
Then, unpack the git repository I sent and add the git repo: in the Git Repositoried view in the Git Perspective, click the button that says "Add existing Git Repository to this View". Navigate to wherever you unpacked it, select it and add it.
Then, import the project from this repo, right-clicking on the repo in the Git Repositories view and selecting "Import Projects...". In the dialog, select the project.
Then, go to the Git History view and select the "Show All branches and tags" button (the last one).
Branch "branchA" should be checked out already, but in any case, you can always right-click on a branch and select "Checkout". Then right-click on "branchB" and select "Merge".
After this there are two possible outcomes: 1) it finishes and reports a conflict, or 2) it crashes or shows the pop-ups that you experienced.
If 1) was the case, go to the Git Staging view, select the file with the conflict, right-click and select "Merge Tool". After a while, you should see the Compare view and the error that I mentioned above.
Then, go to the Error Log view and click the "Export Log" button (the first from the left). Save the error log somewhere and attach it here.
If it resulted in a lot of pop-ups, but you can close them, close them and export the Error Log as above.
If it crashed or you were forced to kill it, restart the tool and export the Error log.
exception-when-merging-branchA-to-branchB.txt

issue193.zip

The zip file that you sent me was in a weird state. The git repo was showing me in branchA currently in the processes of merging with conflicts. So I remove the .git/index.lock file and did a hard git reset
to get the repo back into a state where I could checkout branchA and merge branchB. If you want to give me a different zip where I do not have to take these steps, let me know.
When I attempted to merge branchB into branchA I received a merge result dialog saying that the result of the merge was conflicting. There was no crash here. If I did see crashes
at this stage in the past, they were few are far in between. I went to the git staging view, and selected the merge tool. Almost immediately (not after a while), the compare view
appeared and I received the error that you linked a picture of.
Here is the error log that you were looking for, if you ignore the git reset commands (relating to the above problem), then you can see that I received the same issues that you had.
errorLog.log
I just want to point out that using my own repo, I did not have this issue, I was able to get element to show up in the merge tool, and I had different issues there.

Hi @j26151
I think there were two issues with the git repo I sent you: 1) I think it was probably in a state where it was in the middle of the merge, hence the .git/index.lock, and 2) I had made the project's folder the same as the top-level working tree, instead of creating a folder specifically for the project.
I'm attaching a corrected version of the git repo, with branchA checked out but not in the "merging" state (no .git/index.lock), and with the model project in a folder called IDLPubSub.
In this model, trying to merge branchB into branchA does not result in crashed, exceptions or the error from the previous screenshot. It does result in a conflict, but after opening it with the Merge Tool, one can see the structural differences correctly, as shown in the attached screenshot.
Can you try this new repo and also record the error log (remember to delete it first), to make sure we are seeing the same behaviour?
Thanks
issue193.zip

After playing around with your repository and my original project, I have seen the following in both:

Rarely (1 out of 10 merges/merge tools) eclipse completely runs out of memory crashing eclipse

Very Rarely the merge completes by itself with no conflicts and the resulting model looks correct

Often with my project, although a few times with your repository, the merge finishes with conflicts and when I open the model compare tool and see the following erroneous display:

Often with your repository, and rarely with mine, the merge finishes with conflicts and when I open the model compare tool I see the follow display which allows me to merge the elements easily:

My goal here would be for you to be able to see the situation that I saw with the "bad.png" image linked above. I am not sure why my repository sees it more frequently than yours does. It could be because I have remote origins that I merge with, and also my git history is more complex than that in your repository.
There were no extra errors in the error log to report except in the cases where eclipse crashed. I can link that error if you would like.

Hi @j26151
I have several follow-up comments and questions.

The issue that you see Eclipse running out of memory and crashing is known. See issue #170. It is mentioned in the "Known issues and limitations" in the docs (https://github.com/ZeligsoftDev/CX4CBDDS/blob/papyrus/doc/compare/papyrus-compare-guide.md#limitations-and-known-issues). Is this different than the issues that you were originally reporting (NPE's, crashing, error pop-ups), or is it the same. See also issue #171.
"Very Rarely the merge completes by itself with no conflicts and the resulting model looks correct": whether there are conflicts or not depends on the models, so are you saying that 1) there are cases that you expect there to be no conflicts but conflicts are reported, and/or 2) that the result of a non-conflict merge is incorrect, and/or 3) something else?
When you say that the display in the first screenshot is erroneous, are you referring to the fact that it is in "Text Compare" mode rather than "Model Compare" mode, or that the left panel in the comparison is empty? or something else?
I'm not sure that a more complex history would by itself cause problems, except if the result of an earlier merge was incorrect, and then subsequent merges are just piling in the problems. I will try to experiment with a remote repository and let you know if I have any issues with that.
In order to try to reproduce the problem it would be very useful to know the history of the model. Would it be possible for you to share a copy of your local git repository?

Thanks

Answers to your questions:

Both, we had seen issues 170 and 171 before and I saw 170 a few times while testing your project. If these issues are documented, then I guess that there is no more need to talk about these issues anymore.
I am saying that with the models in the repository you sent me, there was a situation where the git merge completed with 0 conflicts, and the branch was completely merged with the model file appearing to be correct. So eclipse must have known how to auto-merge the model files correctly. This only happened once in my testing of your repository and a few times with my own projects. I am not pointing this out as an error condition, I just thought it was worthy of mentioning as it is inconsistent, but not wrong.
I say that the display in the first screenshot is erroneous because of everything that you mentioned, and more. The fact that it opens to text compare with an empty panel on the left is suspicious. When you look at the top right pane, you can see only one message field is present when there should be two (look at the "good" image). Additionally, when the merge tool opens and looks like the erroneous image, I have not been able to successfully merge or satisfy the conflict. It appears that something is just wrong with either the merge or the tool at that point.
Sounds good.
See attached project. There are two sets of branches in this repository that can be played with. The "branchA branchB" combination is what we have been working with throughout this issue. The "client_deploy server_deploy" is another very simple example that was causing us issues when merging one into another. The differences between these two are slightly more complex, but all it is is a different component process/component being deployed to the right side of the deployment plan.
idlpubsub.zip

Hi @j26151
Follow-up comments:

Previously I observed issue #170 on Windows and macOS but not Linux. Are you seeing this on Linux? Issue #171 was on a particular scenario. If you do get crashes or pop-ups with errors, remember to export the log and attach it either here or in one of those issues, or if it looks different, feel free to open a new one.
That is strange. I've never observed that behaviour. Mind you, EMF Compare may do a "pre-merge" in certain cases. This is controlled by a preference in Window->Preferences->EMF Compare->Merge. I don't fully understand yet when this happens. However I would expect consistent results. So either there is a bug in EMF Compare, or the order of the merges determines when this "pre-merge" occurs. We'll need to try to reproduce the conditions when this happens. When you said that it happened only once in my repository, do you mean that it happened merging the exact same commits every time, or you created new commits and tried to merge them?
On a fresh Papyrus CX install, the Merge Compare Tool opens by default in the "Model Compare" mode, rather than textual compare. You can control this by clicking the fold-down arrow next to "Text Compare". If at some point you switched, maybe the setting was remembered.  The left empty panel would be expected if the file was added on the right side (didn't exist on the left-hand side), which looks consistent with the few decorator icons visible there. This would also explain why there is only one "Message" field. Are you sure that in that case the same file existed in both sides? In any case, if you see this, try opening the common ancestor panel, which may give us some hints. When you say that you cannot merge, do you mean that the buttons to apply changes (left-to-right or right-to-left) in the top-right panel are unresponsive, or that you can click them, some change is applied but then it cannot finish, e.g. you cannot save?
I tried with a remote repository without running into problems, so we can probably rule that out.
I'll try with your repo and see what I can find.

Also, to try to rule out environment conflicts, can you attach a copy of your configuration? (Window->About Papyrus->Installation Details...->Configuration).
Thanks

Yes, we have see the "out of memory" error on Linux. #171 might be different then what we are seeing, but I am not sure. If we see it again we will get the error log and let you know.
Just to make it clear, everything that we have been talking about for this ticket has been done with the model files that I sent you or your repository that you sent us. We are always merging branchB into branchA. If we ever start taking new steps or doing different branch merges, then we will let you know. That being said, I have only seen this issue/blessing once. I am not sure how or why it happened the way that it did. If I see it again then we can raise more alarm.
I guess that the "Text Compare" window isn't the problem so much as the empty "Text Compare" window. Before discussing the erroneous image vs good image I want to stress again that both image were created by doing the exact same steps. Starting with a clean repository state. Merging branchB into branchA. Going to the git staging view, and opening the merge tool. In the erroneous image, there are a few things that I want to point out when comparing to the good image. First, there 33 differences instead of 32. Second, in the top right panel, there are two top level model elements instead of one. If you look at them there are the "<->" character strings designating the comparison of models, however, one side is empty for both of those top level model elements. In the good image, there is only one top level model element and the "<->" string is comparing the two models. So I believe the problem is that EMF compare is somehow being tripped up and instead of comparing the models, it has two separate models that it is comparing to nothing. This leads to the "cannot merge" behavior. What I mean by this is that the buttons are responsive, and items do move around when merging, but it is not clear what I am doing. For example, I could try to merge "fieldB" over from right to left and all of sudden "fieldA" is missing on the right side. Then, if I do try to save, nothing is saved. Its hard to describe the bad behavior because the entire screen is just incorrect.

Attached is my configuration.
config.txt

So, I've been following along and testing model merging alongside Eric on a different machine and these are my observations so far:

I also am seeing this "out of memory" error rather frequently (maybe 2 out of every 10 merge attempts). Here is the error log I managed to snatch before my workspace became completely unresponsive:  crash.txt
Using your provided example in issue193.zip, I'm running into frequent null pointer exceptions mentioned above that result in an unsuccessful merge. It happens to me about 5 out of every 10 attempts on my machine. It doesn't seem to occur as often for Eric. Here's a screenshot showing what I normally see when this occurs:

When this happens I try to merge "fieldB" over from right to left and it doesn't work. As in, fieldB is never successfully merged over. This also occurs with Eric's provided example, but the error log is specific to the issue193 project. Below I'm attaching the error log I get when I run into this issue:
nullPointer.txt
I'm also seeing the same behavior that Eric is describing. With Eric's provided example, I am very rarely able to perform a successful merge. Around 95% of the time, I see the erroneous display discussed above and VERY rarely I'm able to see the "good" display (it happened for me MAYBE once after many, many merge attempts over the course of a few hours). I also still see frequent null pointer exceptions and the "out of memory" issues. With your provided issue193 example, I see the "good" display mentioned above and very rarely see the erroneous display (as in it took many hours of merge attempts with your example to reproduce the erroneous display even just one time). I also still see frequent null pointer and "out of memory" exceptions.

Hi @j26151 and @J75880
Ok, I've experimented with your repository, and the short story is that it mostly works on my environment, although I did ran into some issues, but not the same as yours.
The repository was in the "merging" state with the UML file in conflict, so I started the Merge Tool right away, and this is what I got:

I noticed from your screenshots that you are in the "Group by Resource" view, so I switched to that one and here's the result:

I switched to the "Text Compare" mode, and got this:

Now that one is a bit strange because in the Model Compare view the exception exists on the left and not on the right, so the decorator is correct, but the Text Compare view shows the same text. We'll have to take a closer look at that.
Moving on to the change involving the new field, I see this:

Then I click the "Apply all changes on the left to the right" button, and it succeeded. I saved, got a prompt asking me if I wanted to go to the Staging view, which I did, the file still showed the "conflict" red diamond, but since I had saved it, I simple moved it to the staging area. Then I opened the model, and got a pop-up saying that the model was corrupt, so the merge failed in some way. But at least I can now track down what that problem is.
At one point I got an NPE like you did. Looks like it originates from EMF Compare and has to do with displaying some elements. This seems similar to some NPEs that we saw before and already resolved.
I have not run into the empty panel problem, not the Merge Tool starting in Text Compare mode. And it does concern me that you are seeing inconsistent results on different runs. I assume that when you say you are following the exact same steps, you are doing them from the exact same starting point, i.e. the exact same commits (not just the same branch). If for example, you tried to merge B onto A and failed, and then you modified either A or B and tried to merge B onto A again, we might be compounding problems, so I'd like to make sure that we do the experiments from the same state.
I did find something else that may be the reason for some of your problems: we have a different set of features.
I found that there is a mismatch between your configuration and mine, in terms of the features and plugins included. Some are understandable, for example, I see that you have some NGC specific plugins. I hope those do not interfere in any way, and at this point we have no reason to think so. For other mismatches I don't know why.
Below I list the feature mismatches. For each feature, the first one is the one in my configuration, and the second one is (or isn't) in Eric's:
com.zeligsoft.base_feature (<IP_ADDRESS>009302352) "CX Base"
com.zeligsoft.base_feature (<IP_ADDRESS>010051730) "CX Base"

This is probably just that you did your own build a few days after me.
com.zeligsoft.cx_feature (<IP_ADDRESS>009302352) "CX Platform"
com.zeligsoft.cx_feature (<IP_ADDRESS>010051730) "CX Platform"

Same as above.
org.eclipse.egit (<IP_ADDRESS>906121030-r) "Git integration for Eclipse"
org.eclipse.egit (<IP_ADDRESS>908231537-r) "Git integration for Eclipse"

Maybe a more recent build picked up the newer EGit, but it's only a minor version upgrade, so I wouldn't expect it to be the cause of all the problems.
org.eclipse.emf.compare.egit (<IP_ADDRESS>905300200) "EMF Compare EGit Support"
None

This one is very strange. The Papyrus Compare feature requires the EMF Compare EGit support and the build is supposed to pick it up automatically. It did so in my build. I'll try to build on Linux to see if it goes missing there.
org.eclipse.emf.compare.rcp.ui (<IP_ADDRESS>905300200) "EMF Compare RCP UI"
None

Same as above.
org.eclipse.emf.compare.uml2 (<IP_ADDRESS>905300200) "EMF Compare UML2 Comparison Support"
None

Same as above.
org.eclipse.jgit (<IP_ADDRESS>906121030-r) "JGit Core"
org.eclipse.jgit (<IP_ADDRESS>908231537-r) "JGit Core"

Same as above.
org.eclipse.jgit.ssh.apache (<IP_ADDRESS>906121030-r) "Bundle-Name"
org.eclipse.jgit.ssh.apache (<IP_ADDRESS>908231537-r) "Bundle-Name"

Same as above.
I also have the Xtend features but Eric doesn't. I think Papyrus Compare doesn't use it, but it may. I'll have to double check that. In any case, it is strange that they are not in your build:
org.eclipse.xtend (2.2.0.v201605260315) "Xtend Core "
org.eclipse.xtend.sdk (2.18.0.v20190528-0716) "Xtend IDE"
org.eclipse.xtend.typesystem.emf (2.2.0.v201605260315) "Xtend EMF Typesystem "
org.eclipse.xtend.typesystem.uml2 (2.2.0.v201605260315) "Xtend UML2 Typesystem"
org.eclipse.xtend.typesystem.xsd (2.2.0.v201605260315) "Xtend XSD Typesystem "
org.eclipse.xtext.ui (2.18.0.v20190528-0716) "Xtext UI Core "
org.eclipse.xtext.xbase (2.18.0.v20190528-0716) "Xbase Model"
org.eclipse.xtext.xbase.lib (2.18.0.v20190528-0419) "Xbase Runtime Library"

In the configuration I also noticed some settings related to the Eclipse "Team" support, and EGit falls under that. These settings are set in Preferences->Team. I have the following, you don't:
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.apply_patch_in_sychronize_view=false
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.compress_folders=true
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.default_layout=org.eclipse.team.ui.compressed_layout
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.remove_from_view_without_prompt=false
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.reuse_open_compare_editors=true
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.run_import_in_background_=false
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.show_author_in_compare_editor=false
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.sychronizing_default_participant=none
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.sychronizing_default_participant_sec_id=none
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.sychronizing_default_perspective_to_show=prompt
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.syncview_default_perspective=org.eclipse.team.ui.TeamSynchronizingPerspective
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.validate_edit_with_no_context=false
/bundle_defaults/org.eclipse.team.ui/org.eclipse.team.ui.view_syncinfo_in_label=false
/bundle_defaults/org.eclipse.team.ui/pref_generichistory_view_linking=true

You also have reference set for IMB Xtools, which is a bit strange, as I didn't see any com.ibm.* bundles.
Perhaps more relevant is that you have the following settings, which I don't:
/instance/org.eclipse.emf.compare.ide.ui/org.eclipse.emf.compare.ide.ui.preference.editor.tree.selection.firstChange=false
/instance/org.eclipse.emf.compare.rcp.ui/org.eclipse.emf.compare.rcp.ui.groups.3way.ranking=org.eclipse.emf.compare.rcp.ui.internal.structuremergeviewer.groups.impl.ByResourceGroupProvider;org.eclipse.papyrus.compare.diagram.ide.ui.internal.structuremergeviewer.groups.PapyrusGroupProvider;org.eclipse.emf.compare.rcp.ui.internal.structuremergeviewer.groups.impl.ThreeWayComparisonGroupProvider;org.eclipse.emf.compare.rcp.ui.internal.structuremergeviewer.groups.impl.DefaultGroupProvider;org.eclipse.emf.compare.rcp.ui.internal.structuremergeviewer.groups.impl.KindGroupProvider
/instance/org.eclipse.emf.compare.rcp.ui/org.eclipse.emf.compare.rcp.ui.groups.3ways.syncbehavior=always

So, I think that in order to guarantee we are starting from the same state, we need to investigate first why we have a different set of features, and specially why you are missing some critical for Papyrus Compare. BTW @J75880 can you attach your configuration as well, to compare as well? (Window->About Papyrus->Installation Details...->Configuration).

Here's my configuration:
config.txt

Ernesto, in order for us to provide you with the cleanest Papyrus configuration feedback, I completely removed all our Papyrus and Eclipse-based RPMs and completely removed /opt/Papyrus and ~/.eclipse. I reinstalled Papyrus, saved a configuration file, installed CX, saved a configuration file, etc. until we had all of our Eclipse plugin RPMs installed on top of Papyrus and CX. I took configuration snapshots each time. Below are those files. FYI - We need the newer eGit in our VM configurations because of a bug the old one has with network mounted home directories.
Just Papyrus: Papyrus_config.txt
Papyrus + CX: Papyrus+CX_config.txt
Papyrus + CX + SNA: Papyrus+CX+SNA_config.txt
Papyrus + CX + SNA + eGit plugin: Papyrus+CX+SNA+Egit_config.txt
Papyrus + CX + SNA + eGit plugin + SNA model libraries: Papyrus+CX+SNA+Egit+ModelLibs_config.txt
Hope this helps you narrow things down - fingers crossed it's a configuration issue!

Thanks @J17359, I'll investigate those configs. SNA is your own set of features, I assume?
@ysroh has found some new information. He also experiences the crashes (#170) and NPEs (#171), and the same issues described here such as opening in Text Compare mode and empty left or right panels. He said that removing the Papyrus Compare feature eliminated the crashes and NPEs, but with only EMF Compare he still experienced the Text Compare mode and empty panels issue. I've asked him to check his configuration to see if he is missing the same features I mentioned earlier.
I've checked our development environment, and in particular the meta-data for the update site that we build (category.xml of com.zeligsoft.dds4ccm.update.axcioma) and it includes those features:

(Note I didn't highlight all of them in the screenshot above, but they are all included.)
I understand that you build from the git repository these update sites, and that the build is performed internally, without an external internet connection, is that right? That will likely influence the set of features that get packaged. Perhaps you could investigate the set of features included in your builds? After doing a fresh build (from a clean slate), check the contents of the CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/repository/features folder, and also unzip the generated update site at CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/dds4ccm_axcioma_2.0.0.v2020MMDDBBBB.zip and CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/com.zeligsoft.dds4ccm.update.axcioma-2.0.0-SNAPSHOT.zip. In the unzipped update sites, check the features folder. Look for the missing features I mentioned earlier.

Thanks @J17359, I'll investigate those configs. SNA is your own set of features, I assume?

Yes. SNA is our own set of Eclipse plugins - build/run tools for SNA applications, example project import options, etc..

I understand that you build from the git repository these update sites, and that the build is performed internally, without an external internet connection, is that right?

Not really. In order to build your software, we follow the same instructions you document here, except we also pass a proxy settings xml file to maven as well to allow maven to reach out to the internet. We then use the spec file you provide here to generate the RPM that will install the dds4ccm_axcioma_2.0.0....zip file into Papyrus using the headless p2 application as specified in the spec file scriptlets.
However, when installing the RPM, we cannot guarantee an internet connection. So if features that were used to build your software are not also provided with your software, we will not be able to pull them in alongside it during install. We've seen this in the past and Young-Soo or Paul have added those dependency features of yours to some file in your build system so they get added to the dds4ccm_axcioma_2.0.0....zip file that is generated when running maven.

Perhaps you could investigate the set of features included in your builds? After doing a fresh build (from a clean slate), check the contents of the CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/repository/features folder,

and also unzip the generated update site at CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/dds4ccm_axcioma_2.0.0.v2020MMDDBBBB.zip and CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/target/com.zeligsoft.dds4ccm.update.axcioma-2.0.0-SNAPSHOT.zip. In the unzipped update sites, check the features folder. Look for the missing features I mentioned earlier.

"normal" zip:

SNAPSHOT zip:

From what I could tell on Friday (from the above screenshots), I think you (@eposse) and I have the same configuration setup. Please confirm that my screenshots of the jar lists are showing what you expected.
Please let me know what else I can investigate for you from our end. I also don't mind setting up a WebEx so I can screen share with you and show you how we build/install Papyrus and CX onto our VMs. If you need to see actual model merge scenarios on our end, I'll have to lean back on Eric or Jon to walk you through those.

Hi Michael,
We are actually right at the end of a release of another product which is scheduled to be completed on Thursday. Until then Ernesto's and Young-Soo's time is limited. Starting Thursday, at the latest, we will put those two on this problem full time until it is fixed. Sorry for the delay, but this other release is critical.
Ernesto has looked at the config you sent and says that it is also missing the EMF compare features. Maybe you can take a fresh Papyrus install and install  the update site generated by the build (zip archive) and verify if the features listed as missing in #193 are still missing.
Regards,
Simon
From: Michael Steppe<EMAIL_ADDRESS>Sent: Monday, October 12, 2020 10:02 AM
To: ZeligsoftDev/CX4CBDDS
Cc: Subscribed
Subject: Re: [ZeligsoftDev/CX4CBDDS] Issues with model merging (#193)
From what I could tell on Friday (from the above screenshots), I think you (@eposse https://github.com/eposse ) and I have the same configuration setup. Please confirm that my screenshots of the jar lists are showing what you expected.
Please let me know what else I can investigate for you from our end. I also don't mind setting up a WebEx so I can screen share with you and show you how we build/install Papyrus and CX onto our VMs. If you need to see actual model merge scenarios on our end, I'll have to lean back on Eric or Jon to walk you through those.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view https://github.com/ZeligsoftDev/CX4CBDDS/issues/193#issuecomment-707139313  it on GitHub, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7AIL5C5U5GIVI6XFB3Z3DSKMD4FANCNFSM4R5TUOKQ .Image removed by sender.

Hi Michael, We are actually right at the end of a release of another product which is scheduled to be completed on Thursday. Until then Ernesto's and Young-Soo's time is limited. Starting Thursday, at the latest, we will put those two on this problem full time until it is fixed. Sorry for the delay, but this other release is critical.

No worries @simonredding1! I totally understand. I'll do my best to get as much of our configuration information as I can logged on here for @eposse and @ysroh to go over as their time allows.

Ernesto has looked at the config you sent and says that it is also missing the EMF compare features. Maybe you can take a fresh Papyrus install and install the update site generated by the build (zip archive) and verify if the features listed as missing in #193 are still missing. Regards, Simon

Maybe there's a misunderstanding here, but that's exactly what we do using the spec file you all provide here. That RPM spec file takes the zip archive generated by your maven build and installs it into Papyrus headlessly via the p2 director. In that spec file, there is a list of installation units that you've all maintained for what exactly from the zip gets installed, so maybe you're missing the features @eposse says we're missing?
In previous comments, @eposse states the following features are missing from our configurations:
org.eclipse.emf.compare.egit (<IP_ADDRESS>905300200) "EMF Compare EGit Support"
org.eclipse.emf.compare.rcp.ui (<IP_ADDRESS>905300200) "EMF Compare RCP UI"
org.eclipse.emf.compare.uml2 (<IP_ADDRESS>905300200) "EMF Compare UML2 Comparison Support"

org.eclipse.xtend (2.2.0.v201605260315) "Xtend Core "
org.eclipse.xtend.sdk (2.18.0.v20190528-0716) "Xtend IDE"
org.eclipse.xtend.typesystem.emf (2.2.0.v201605260315) "Xtend EMF Typesystem "
org.eclipse.xtend.typesystem.uml2 (2.2.0.v201605260315) "Xtend UML2 Typesystem"
org.eclipse.xtend.typesystem.xsd (2.2.0.v201605260315) "Xtend XSD Typesystem "
org.eclipse.xtext.ui (2.18.0.v20190528-0716) "Xtext UI Core "
org.eclipse.xtext.xbase (2.18.0.v20190528-0716) "Xbase Model"
org.eclipse.xtext.xbase.lib (2.18.0.v20190528-0419) "Xbase Runtime Library"

For what it's worth, I see the following in my configuration files, under the "Plug-in Registry" section (not the "Features" section from which @eposse got the list above from):
org.eclipse.emf.compare (<IP_ADDRESS>905300200) "EMF Compare Core" [Starting]
org.eclipse.emf.compare.diagram (<IP_ADDRESS>905300200) "EMF Compare Diagram Comparison Support" [Starting]
org.eclipse.emf.compare.diagram.edit (<IP_ADDRESS>905300200) "EMF Compare Diagram Comparison Edit Support" [Starting]
org.eclipse.emf.compare.diagram.ide.ui (<IP_ADDRESS>905300200) "EMF Compare Diagram Comparison Support IDE UI Integration" [Starting]
org.eclipse.emf.compare.doc (<IP_ADDRESS>905300200) "EMF Compare Documentation" [Starting]
org.eclipse.emf.compare.edit (<IP_ADDRESS>905300200) "EMF Compare Edit Support" [Starting]
org.eclipse.emf.compare.egit (<IP_ADDRESS>905300200) "EMF Compare EGit Support" [Active]
org.eclipse.emf.compare.egit.ui (<IP_ADDRESS>905300200) "EMF Compare EGit UI integration" [Resolved]
org.eclipse.emf.compare.ide (<IP_ADDRESS>905300200) "EMF Compare IDE integration" [Starting]
org.eclipse.emf.compare.ide.ui (<IP_ADDRESS>905300200) "EMF Compare IDE UI" [Starting]
org.eclipse.emf.compare.rcp (<IP_ADDRESS>905300200) "EMF Compare RCP" [Starting]
org.eclipse.emf.compare.rcp.ui (<IP_ADDRESS>905300200) "EMF Compare RCP UI" [Starting]
org.eclipse.emf.compare.uml2 (<IP_ADDRESS>905300200) "EMF Compare UML2 Comparison Support" [Starting]
org.eclipse.emf.compare.uml2.edit (<IP_ADDRESS>905300200) "EMF Compare UML2 Comparison Edit Support" [Starting]

org.eclipse.xtend (2.2.0.v201605260315) "Xtend Core" [Resolved]
org.eclipse.xtend.core (2.18.0.v20190528-0610) "Xtend Core" [Starting]
org.eclipse.xtend.ide (2.18.0.v20190528-0610) "Xtend IDE" [Starting]
org.eclipse.xtend.ide.common (2.18.0.v20190528-0610) "Xtend IDE Common" [Starting]
org.eclipse.xtend.lib (2.18.0.v20190603-0326) "Xtend Runtime Library" [Resolved]
org.eclipse.xtend.lib.macro (2.18.0.v20190603-0326) "Xtend Macro Interfaces" [Resolved]
org.eclipse.xtend.shared.ui (2.2.0.v201605260315) "Xpand Shared UI" [Starting]
org.eclipse.xtend.typesystem.emf (2.2.0.v201605260315) "Xtend EMF Typesystem" [Resolved]
org.eclipse.xtend.typesystem.uml2 (2.2.0.v201605260315) "Xtend UML2 Typesystem" [Resolved]
org.eclipse.xtend.typesystem.xsd (2.2.0.v201605260315) "Xtend XSD Typesystem" [Resolved]
org.eclipse.xtend.typesystem.xsd.ui (2.2.0.v201605260315) "Xtend XSD Typesystem UI" [Starting]
org.eclipse.xtend.util.stdlib (2.2.0.v201605260315) "Xtend Standard Library" [Resolved]
org.eclipse.xtext (2.18.0.v20190603-1042) "Xtext" [Starting]
org.eclipse.xtext.builder (2.18.0.v20190603-1005) "Xtext Builder" [Starting]
org.eclipse.xtext.common.types (2.18.0.v20190603-1025) "Xtext Common Types" [Starting]
org.eclipse.xtext.common.types.edit (2.18.0.v20190603-1005) "Xtext Common Types Edit" [Resolved]
org.eclipse.xtext.common.types.shared (2.18.0.v20190528-0513) "Common Types Shared State" [Starting]
org.eclipse.xtext.common.types.ui (2.18.0.v20190603-1005) "Xtext Common Types UI" [Resolved]
org.eclipse.xtext.ecore (2.18.0.v20190603-1025) "Xtext Ecore Support" [Starting]
org.eclipse.xtext.generator (2.18.0.v20190603-1025) "Xtext Generator" [Starting]
org.eclipse.xtext.ide (2.18.0.v20190603-1042) "Xtext IDE Core" [Starting]
org.eclipse.xtext.smap (2.18.0.v20190603-1025) "JSR-45 SMAP installer" [Resolved]
org.eclipse.xtext.ui (2.18.0.v20190603-1005) "Xtext UI Core" [Starting]
org.eclipse.xtext.ui.codetemplates (2.18.0.v20190603-1005) "Xtext Codetemplates Language Runtime" [Starting]
org.eclipse.xtext.ui.codetemplates.ide (2.18.0.v20190603-1005) "Xtext Codetemplates Language Generic Ide" [Resolved]
org.eclipse.xtext.ui.codetemplates.ui (2.18.0.v20190603-1005) "Xtext Codetemplates Language UI" [Starting]
org.eclipse.xtext.ui.shared (2.18.0.v20190603-1005) "Xtext UI Shared" [Starting]
org.eclipse.xtext.util (2.18.0.v20190603-1042) "Xtext Utility" [Resolved]
org.eclipse.xtext.xbase (2.18.0.v20190528-0033) "Xbase Model" [Starting]
org.eclipse.xtext.xbase.ide (2.18.0.v20190528-0033) "Xbase Generic IDE Services" [Starting]
org.eclipse.xtext.xbase.lib (2.18.0.v20190603-0326) "Xbase Runtime Library" [Resolved]
org.eclipse.xtext.xbase.ui (2.18.0.v20190528-0513) "Xbase UI" [Starting]
org.eclipse.xtext.xtext.generator (2.18.0.v20190603-1042) "Xtext Generator 2" [Starting]
org.eclipse.xtext.xtext.ide (2.18.0.v20190528-0021) "Xtext Language IDE Support" [Starting]

As you can see, all the features from @eposse's list are listed only in the plugins section of our configuration file (with the exception of org.eclipse.xtend.sdk). So like I said earlier in this comment, I think the issue is that we've installed the plugins but not the features themselves. Maybe Papyrus doesn't use plugins that aren't registered with their features? That's starting to get outside my wheelhouse of Eclipse knowledge.
Any of the differences in our configuration files that start with /bundle_defaults/ or /instance/ or /profile/ is a result of the user preferences that were in place when the configuration file was created. I was able to verify this by wiping my ~/.eclipse folder after making an EMF Compare preference change. So I think those sort of differences are not an issue. Those are all listed under the "User Preferences" section of the configuration file, FYI.
In any case, I think it would be beneficial if you all could test an RPM installation of CX yourselves. You version control the RPM spec files and that is the only way that we install your software. I think THAT is the biggest point of contention here, to be honest. I imagine you all manually install the zip archive in the Papyrus GUI. If you select/check different features in your manual install than are listed in the RPM spec file, that could be why we're seeing differences (I'll try and verify this behavior).
On a side note, having some sort of automated test you could run on that spec would greatly minimize these sort of issues in the future. I could have sworn you used to have this automated test running via Travis CI at some point earlier this year. A lot of our configuration mismatches and bug reproducibility problems could likely come from testing the software as you deliver it. I think there have been a few times where Young-Soo couldn't reproduce our problems because he was running a second instance of Papyrus based on an instance where he had his plugins/features built (just like we do internally to test our Eclipse plugins). But in order to reproduce what we were seeing, he had to actually install the software via RPM like we do. Just an idea to mitigate these types of inconsistencies 😄

As I expected, installing your zip generated by our build of your software manually shows a bunch of features that are not already installed, because they're not called out by p2 in the spec file. As you can see in the screenshots below, the Papyrus Compare Feature (Inbubation) feature is greyed out because we have already installed it (because the spec file specifically calls it out in its installation units). I would imagine you all need to add something similar for the runtime dependencies required for Papyrus Compare to work (i.e. the EMF Compare and Xtend features).
CX CBDDS Runtime Dependencies

CX CBDDS Runtime Dependencies (cont.)

Hi @J17359 (CC @simonredding1 , @j26151 @J75880)
You are probably right about the RPM spec file missing these features. I'm not quite familiar with RPM spec files so that's quite likely the cause as you say.
I think that it is possible that most of the required plugins were installed but not the features, but it's also possible that not having the features somehow makes things go awry.
I don't know if we has automated installation tests about this. Perhaps this was before I was on the project. I'll as Paul. You are right about issues that don't occur in the development environment (instance within an instance) and not in the built product. In fact I only noticed #170 and #171 after testing in the installed product, and these did not occur in the development environment. These problems could also be avoided with a target platform definition in the development environment. I had made some progress towards creating one, but it hasn't been fully tested so I don't know yet if it is complete.
As Simon said, until Thursday I'm terribly busy, so unfortunately I don't think I'll be able to spend a lot of time on this until then. If I get a bit of time, I'll try to update the spec file with the missing dependencies. In the meantime, could you try to manually install those dependencies and try the tests we previously discussed to see if some of the issues go away?
Thanks for understanding.

@eposse - We understand you're limited until Thursday. Not a problem. I'm just trying to give as much feedback as I can so you have information to go off of when you return.
I did try to install the missing features via p2 from the command line to ensure that they could be installed without a network connection and the install failed for missing dependencies that were not included in the generated zip archive. I think you'll have to look into that as well when you add those installation units to the spec file.
For reference, when I ran the following (which mostly comes from your spec file - with the exclusion of all the EMF and xtend deps I added)

I got the following error (looks like the new deps I added have deps of their own that aren't available without contacting the network)

@j26151 is installing these via the Papyrus GUI and checked the contact all update sites during install to find the required software checkbox so that we could at least get those dependencies installed. He will comment below with his model merge feedback after installing those dependencies manually and retesting.

Hi @J17359
In the test you mention in your last comment, installing without a connection, you say that it fails for features not included in the zip but the only error is the one with Xtend IDE (org.eclipse.xtend.sdk)?
From the screenshot it looks like the EMF Compare feature is being installed.
I'm a bit confused, because the earlier screenshots you posted showed the "missing" features (including Xtend IDE) in your zip files.
In the zip generated by my local build the Xtend IDE feature is included, as are the ones that looked missing in your installations.
I'm going to setup a VM for an rpm-bases distro to test there. Is there any particular recipe or command that you use to install the rpm?

@eposse The VM should RHEL or CentOS 7.X (minor version doesn't matter much here). Papyrus must be installed to /opt/Papyrus as well. Then the command to install the cx-axcioma rpm would just be "rpm -i "

@eposse  - The error I am seeing isn't stating that it can't find the xtend.sdk package, it's stating that it can't find the xtend.sdk package's dependencies:

You can see it's complaining about org.eclipse.xtend.lib.source which I couldn't find anywhere in your zip artifact from your build.

Hi @J17359 @j26151
Thanks, this is quite useful.
Sorry, I missed the problem being the xtend dependency (the screenshot is a bit dark ;)).
So, to confirm your process, you build it using that script (appropriately modified), which masses proxies settings to maven so that during the build it does access the internet, and rpmbuild generates the .rpm file which you then install with "rpm -i .rpm" while disconnected, correct?

Sorry, I missed the problem being the xtend dependency (the screenshot is a bit dark ;)).

Sorry about that! It's hard to get all the relevant information in a screenshot sometimes and the text can get small and hard to read.

So, to confirm your process, you build it using that script (appropriately modified), which passes proxies settings to maven so that during the build it does access the internet, and rpmbuild generates the .rpm file which you then install with "rpm -i build-name.rpm" while disconnected, correct?

Exactly. We have internet access during build, but not during install.

Hello @J17359.
I had a few issues getting a CentOS 7 VM that worked but I finally got one. I was able to build with a modified version of your script (using the mvnw script included in the root directory to install the correct version of maven).
I was wondering how are you installing Papyrus itself. Do you get the "All-in-one" update site from https://www.eclipse.org/papyrus/downloads/index.php? or do you use the update site at https://archive.eclipse.org/modeling/mdt/papyrus/updates/releases/2019-06? Do you use the Eclipse Installer? If so what package do you base your install on? The Modelling Tools package? Something else?
In theory there shouldn't be a difference between these, but out past experience with Papyrus makes me think that it is not impossible to obtain a different set of bundles depending on the update site, base package, etc. So I'm trying to get something as close as possible to your setting.
From what I see, you expect Papyrus to be installed in /opt, is that right?

@eposse

I was wondering how are you installing Papyrus itself. Do you get the "All-in-one" update site from https://www.eclipse.org/papyrus/downloads/index.php? or do you use the update site at https://archive.eclipse.org/modeling/mdt/papyrus/updates/releases/2019-06? Do you use the Eclipse Installer? If so what package do you base your install on? The Modelling Tools package? Something else?

From an email from Simon back in January of this year, he stated we should download Papyrus from https://www.eclipse.org/downloads/download.php?file=/modeling/mdt/papyrus/rcp/2019-06/4.4.0/papyrus-2019-06-4.4.0-linux64.tar.gz. Since we downloaded that tarball back in January, things haven't changed. We actually wrapped that tarball in an RPM so that we can ensure installation is always the same. We simply extract that tarball into /opt and create a desktop shortcut for it.

From what I see, you expect Papyrus to be installed in /opt, is that right?

Correct, our papyrus folder structure looks like:
/opt/
    Papyrus/
        features/
        papyrus
        papyrus.ini
        plugins/
        etc.

Hi @J17359 @j26151 @J75880 .
So I finally was able to install the tool as you do on CentOS 7.6.1810 as indicated by your instructions. The generated tool indeed lacks the features I listed before.
Nevertheless I decided to give it a try and I got some results different from you.
The git repo that you sent me was in a locked state with the merge in progress, so I opened the Merge Tool right away, and it actually worked (mostly). It wasn't in Text Compare mode and it didn't show the left panel empty. It wasn't missing difference rows either.

I performed a merge abort and attempted the merge again, obtaining the same successful result.
I then clicked the button to apply all the changes from right-to-left (as branchB was on the right and being merged onto branchA on the left), and it succeeded in merging the changes, but the resulting model becomes corrupted:

One thing that I did which was different was that I had not imported the project before starting the merge. So after having imported the project, I checked out the original branchA commit and tried to merge again. This time I got some sligly weird results. The Merge Tool looked a bit different with only one view on top and different decorator icons:

But after closing the Merge Tool and opening it again, it became more reasonable:

Although now it showed only one difference row for the Message field changed.
I did ran into some NPEs which appear to be caused when trying to display certain properties in the difference views, but I have not experienced the out-of-memory crash yet. Perhaps it happens after several operations.
In any case, at this point it is a problem that I still get different results from you even though it looks like I have the same configuration as you, with the exception of the SNA and IBM features you have. So my guess is that those features you have may be interfering somehow.
But in any case, the build is still missing some features, even if the plugins seem to match, so I'm going to try to update the rpm spec file to add all the relevant dependencies and see if we can get the same set of features.
In the meantime, have you observed any improvements when you manually install the missing features?

@eposse Your last two screen shots are much more similar to ours. You may have not gotten the empty text compare box, which could just be a result of different comparison preferences, but if you notice in the top right pane (or top pane), there is  the "<->" symbol in between the two models that are being compared. In your last two screen shots, there is only on model on one side of that "<->" symbol with the other side being blank. This is the exact issue that we were seeing that was causing the empty text compare box.

Thanks.
I think it's better to ensure first that we have the exact same set of features and plugins and in particular making sure that you get all the required dependencies so that we all get the same sort of errors.
I'm making progress and updated the RPM spec to install what we need as dependencies, but I also got the error complaining that the Xtend IDE was missing the "org.eclipse.xtend.lib.source" bundle. I'm investigating that one now.

I've opened a pull request (#200) updating the rpm spec and update site with dependencies on a new branch (papyrus-rpm-deps). I've verified that after installing with rpm -i, while disconnected, all features expected are there.
Can you build it (of the new branch) and give it a spin and see if at least some of the problems go away?
Thanks

@eposse I'm building the RPM from your branch now and will give it to @j26151 for testing. He'll report back once he tests the merges with the new RPM.

Hi @J17359 @j26151
I did some experiments with your git repo on Papyrus with the new package build with RPM on CentOS and I ran into issue #170 (out-of-memory), but I was able to get some very telling exceptions in the error log and in the console. I've commented on them in #170.
The short version is that the git repo seems to be corrupted and it may be due to a JGit bug.
I remember you mentioned that you install a slightly newer version of EGit. Do you install that manually or modify the RPM spec file?

We downloaded the 5.4.2 version of the egit p2 repository from https://wiki.eclipse.org/EGit/FAQ#Where_can_I_find_older_releases_of_EGit.3F. The direct download link can be found here.
I then wrapped that p2 zip we downloaded into an RPM using the attached spec file (I added the .txt extension for it to upload).
egit-plugin.spec.txt
As you can see, we simply install the p2 zip and then install three of the installation units in the RPM scriptlets section, nothing fancy - same thing you do for the Zeligsoft CX RPM.

@eposse With our latest RPM I have been able to create a table of test results for two different projects. One project, is the original issue193.zip project that you gave us. The second project, is the same zip file, issue193.zip, but with the ".project" file moved up a directory to the root of the git repo. I have attached that project zip file here:
issue193_v2.zip
Also attached here is my current configuration:
config.txt
When testing each project, I tried 4 variations that all involved using the model comparison view with the projects available in the git repository view. These variations were "Merged in Git, Merged via. commandline" cross "Imported as an actual project into eclipse, not imported as a project". Here were the results:

Project
Not Imported, Eclipse merge
Not Imported, Shell Merge
Imported, Eclipse merge
Imported, Shell Merge

Issue193
Conflicting, Model Compare View Appears correct, cannot save
Conflicting, Model Compare View Appears correct, cannot save
Auto merged, Model is correct
Model Compare View looks correct, Was able to save and create correct model.

Issue193_v2
Conflicting, Model Compare View Appears correct, cannot save
Conflicting, Model Compare View Appears correct, cannot save
Auto merged, Model is correct
Model Compare View is incorrect

To add some more information. When I say "conflicting" I just mean that Git in either eclipse or via. the command line could not auto merge the model and that something manual had to be done. When I say "cannot save", what I mean is that even though the model compare view looks correct and allows me to interact with it, I cannot actually save any of my changes or conflict resolutions. When I say "Model Compare View Appears Correct", what I mean is that I see the following screen vs the "Model Compare View is Incorrect:
Correct:

Incorrect:

For the above images, please notice the difference where the correct view has a single IDLPubSub.uml <-> IDLPubSub.uml line where the incorrect view has two separate lines for the model files.
Lastly, I want to point out that @J75880 was never able to get the eclipse's merge to "Auto Merge", however, I was.
Here is my understanding of what is going on based on the table above.

If the project with the model is not imported into Eclipse to be an actual "project", then merging/resolving conflicts do not work as the file cannot be saved.
If the project is imported and the model merge is simple enough for eclipse to do automatically, then the merge may happen automatically and be correct (this is a good outcome)
If the project is imported and the model merge has conflict (either the merge is complicated, or done via. the command line, or just not being handled automatically) then we must use the model compare view to fix the issues.
The model compare view does not appear to work if the model is in a subdirectory, deeper than where the ".project" file exists (this is the point of me creating and linking the issue193_v2 zip file). This is the main issue that we need to get resolved.
The model compare view works correctly if the model is a sibling file of the ".project" file. This is good, but will not suit our use case at all as we have tons of projects with model files in different folders and directories.

Hi @j26151. Thanks for the new info. Are you sure the config you sent is from the rpm built from branch "papyrus-rpm-deps" (and not branch "papyrus")? I've compared it with the configuration I get from that rpm, and it looks like yours is still missing the same features I mentioned before.

I didn't build the RPM that I used to test, @J17359 did. But looking back at the Jenkins job he built it with, it appears that he used the correct branch, "papyrus-rpm-deps"

@eposse - I'll work today in a totally fresh VM to see if I can reproduce your configuration using the base Papyrus RPM we install plus your CX RPM. I'll post the config once I have it.

@eposse What features specifically are we still missing? We tested with the correct papyrus-rpm-deps branch

@eposse - while I'm creating the new config, please look into how you're installing Papyrus to ensure we're the same on that front as well. We install the version of Papyrus your team pointed us to (linked here) and then the CX RPM. We do not install anything else besides the newer egit RPM. If at any point in your Papyrus setup, you're contacting update sites or pulling dependencies from the network, that would be where we could see differences. We can pull packages from the network during BUILD but not during INSTALL so we need you (CX) to provide us with anything beyond the base Papyrus features.

Hi @J17359 and @j26151.
First to answer Eric's question, your config is still missing these features:
org.eclipse.emf.compare.egit (<IP_ADDRESS>905300200) "EMF Compare EGit Support"
org.eclipse.emf.compare.rcp.ui (<IP_ADDRESS>905300200) "EMF Compare RCP UI"
org.eclipse.emf.compare.uml2 (<IP_ADDRESS>905300200) "EMF Compare UML2 Comparison Support"
and also these:
org.eclipse.xtend (2.2.0.v201605260315) "Xtend Core "
org.eclipse.xtend.sdk (2.18.0.v20190528-0716) "Xtend IDE"
org.eclipse.xtend.typesystem.emf (2.2.0.v201605260315) "Xtend EMF Typesystem "
org.eclipse.xtend.typesystem.uml2 (2.2.0.v201605260315) "Xtend UML2 Typesystem"
org.eclipse.xtend.typesystem.xsd (2.2.0.v201605260315) "Xtend XSD Typesystem "
org.eclipse.xtext.ui (2.18.0.v20190528-0716) "Xtext UI Core "
org.eclipse.xtext.xbase (2.18.0.v20190528-0716) "Xbase Model"
org.eclipse.xtext.xbase.lib (2.18.0.v20190528-0419) "Xbase Runtime Library"
I don't think the Xtend features are essential, at least as far as Papyrus Compare is concerned, but they should be there as they are specified in the rpm spec file.
As for my build, yes, I'm using that exact version of Papyrus, and in fact that exact tar ball.
In every test I've done on CentOS to install the rpm, I've completely removed Papyrus first and then untarred it:
[vagrant@centos7-gui:~] > cd /opt
[vagrant@centos7-gui:opt] > sudo rm -rf Papyrus
[vagrant@centos7-gui:opt] > sudo tar zxvf papyrus-2019-06-4.4.0-linux64.tar.gz

Then, after a successful build, I disconnect from the internet entirely and go to the folder where the RPM was created and do:
[vagrant@centos7-gui:noarch] > pwd
/home/vagrant/git/CX4CBDDS/releng/com.zeligsoft.dds4ccm.update.axcioma/rpm_build/noarch
[vagrant@centos7-gui:noarch] > ls
cx-axcioma-2.0.0-0.2010220054_80099d0.noarch.rpm
[vagrant@centos7-gui:noarch] > sudo rpm -i cx-axcioma-2.0.0-0.2010220054_80099d0.noarch.rpm

Can you send me a log of your jenkins job? Perhaps there are some clues there.
Thanks.

@eposse - in looking at the Jenkins logs when preparing to send I did notice that I was accidentally building the CX RPM using our version of the zeligsoft spec that I created to test things out on our end while helping debug these model issues. My version of the spec didn't have your changes. I'm regenerating the RPM now using your spec for us to install/test internally and send you the config for. My apologies.

Ah! That would explain it ;) Good to get things cleared out.

Ah! That would explain it ;) Good to get things cleared out.

Everything about the zip file the RPM installed was correct. My spec scriptlets for the installation units was not, however which is why our configurations were off. I'll post the new results shortly.

@eposse - Here is the latest config with a branch new papyrus and your CX RPM from your branch:
ernestoConfig.txt
To confirm it was your RPM, see below for the yum install output where the installation units were logged as installed successfully:
ernestoInstall.txt

Looks good. The features are there. Of course that doesn't mean the bugs are gone, but at least now we have the same baseline (modulo you NGC and IBM plugins).
I assume that "yum install" just performs an "rpm -i", right?

I assume that "yum install" just performs an "rpm -i", right?

Yes. Yum will attempt to reach out to any enabled repositories for dependency management whereas rpm will simply fail if those deps are not met. Under the hood, they do the same thing though.

Using the RPMs that Michael created, I was able to test out the project mentioned above again. I had the same results although the images for the "good" vs "bad" model differences view are just slightly different.
Good:

Bad:

Lastly, here is my configuration:
config2.txt

A couple of questions about your latest test:

These results are for the one that does have the .project in the root folder of the git repo or the one that doesn't? As stated in this link: Considerations for Git Repositories to be used in Eclipse it's a bad idea to make the root folder of a git repo into an Eclipse project. I've made that mistake in the past with I can confirm that indeed it results in all kinds of problems, incorrect results, exceptions and even crashing. If you are doing this with the .project at the root, that may explain the "bad" image.
This is the result of merging branchB into branchA as well?
Are you grouping the results by resource? See Alternative grouping of changes
Have you experienced any of the previously reported issues (the comparison opens in "Text Compare" mode, or the left panel appears empty, or it stalls, and runs out of memory, etc.)

@eposse

See below
Yes
Yes
Yes, but see below

It appears at the moment that the main issue has been solved by moving the .project file into a subdirectory within the git root. I was never aware that this was an issue and many of our programs here have git repos and projects at the same level. I would classify this as a bug on Papyrus Compare, however, this is a work around that is available and we can live with. Overall, we believe we can move forward with this as a known limitation.
With the incorrect model comparison view being resolved, or at least a workaround found, we have one last issue that we would like you to investigate. This issue being that module instantiations are considered "model conflicts" when they should not be.
Please use the following project to reproduce:
issue193_v3.zip
What you should do to reproduce is the following:

Unzip the project
Add the project as an existing git repository
Import the Issue193 project from the git repo
Merge branchB into branchA from the command line. We do this via. the command line to force a conflict and to not allow eclipse to fix anything automatically
See that there are multiple differences. There should only be one differences (the different fields added to the message), however, there are "differences" between the module instantiations which were not modified. We have models with upwards of 50 module instantiations. If we have a model merge scenario with say 5 changes, we cannot be sifting through 500+ changes, where 500 of them are not actual issues, just to resolve the few changes that we need

@eposse - Would you mind making the pull request for that spec file while we figure out the remaining issue in this ticket so that we can build the "papyrus" branch that has those latest spec updates?

@J17359 Sure. I'll do the refactoring of the spec file that you suggested in the pull request and after the build is done I'll merge it.

@J17359 I've fixed the spec file, tested it and merged the branch into the papyrus branch.

@j26151
First just one last comment about the use of .projects in the root folder of a git repo: it is not a bug in Papyrus Compare. It is EGit's behaviour, and described in the link from my lat comment, which is in EGit's documentation, which states that you shouldn't have .project files at the same level as .git folders. Hence, we don't really have control over this. But as you say, there is a workaround.
Regarding your new git repo, if I understand correctly, the only change you would like to see (in this example) is the message field addition and none of the other changes (all of which seem to be updates to CX Exceptions in module instances). Is that correct?
Assuming that is the case, it is quite likely because Papyrus Compare knows how to deal with Papyrus models, but it is not yet customized to deal with the AXCIOMA meta-model, and does not know about module instantiations. This is mentioned in Limitations and known issues.

We know that it is documented as a limitation so maybe this ticket can be closed out now that we've figured out the missing features/.project issues and are seeing the same behavior (w/limitations) as you now. Should we write a new feature request for you (Zeligsoft) to start working the AXCIOMA model merge support as soon as possible? Our end users will need that before they'll ever fully adopt our new version of our software.

Hi. Yes, I think it might be a good idea to have a dedicated issue/feature request.
I'll keep investigating this and all other issues we have been discussing.
But before closing this issue, can you confirm whether you still get the comparison opened in Text mode or with an empty left panel?

By moving our projects into a subdirectory of the git respository we see the following:

The model does open in the text view, but this could just be a preference issue. This does not seem like a problem as once we click on one of the conflict, it changes to the model mode.
No, we no longer see the empty left panel.

@j26151 @eposse  - Where do we stand with this ticket? We have a bunch of NPE tickets in the backlog I'd like to clean up so I can keep track of what still is affecting our users...

I think this issue should be closed.

Yes, I agree that this issue can be closed.


Bug: Navbar and Footer Hyperlinks Missing for Pages

Describe the bug
In the navbar, only text is mentioned but no hyperlinks are given to each separate page leading to users missing those pages. Even in my case, I was not knowing about the separate page since it was not linking on the navbar as well as on the footer.
To Reproduce
Steps to reproduce the behavior:

Go to 'homepage'
Click on any navbar link
See the error
Scroll down to 'footer'
Click on any footer link
See error

Expected behavior
Proper hyperlinks must be added to each element so that users can navigate to different pages on the sites and check out for certain issues if any.
Screenshots

Additional context
Can I work on this small issue for GSSoC'22?

hey @Shubham29012001 it will be good if you can implement react scroll to the nav links and after scrolling to the section , add separate pages links to learn more buttons

Ok got it will implement it and send the PR soon.

hey @Shubham29012001 updates on it?

Hey @mohityadav0903, I really sorry for the late updates. I will create the PR soon.


Folder contents should show the portal type as a tooltip

I miss this small feature from Plone, showing the portal type as a tooltip for the entries in the folder listing.

https://github.com/plone/volto/blob/master/src/components/manage/Contents/ContentsItem.jsx#L164


Can't add furnace recipe

furnace.addRecipe(<minecraft:coal:0>, <minecraft:coal:1>);
results in

Named a variable furnace, nevermind :)


Diff edits seem to not work at all

What happened?
I have attached an image showing my problem.
I have created a simple python file that needs to be diff edited:
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# Diff edit this line into a print statement
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence

And I have asked the model (gemini-2.0-flash-exp) to diff edit it. It repeatedly fails. I understand that I am not using Claude 3.5 Sonnet, but given how simple the task is, it seems rather strange that the model cannot successfully do it. Moreover, the search block it has provided (attached below) seems like it should match something:
The SEARCH block:
# Diff edit this line into a print statement
...does not match anything in the file.

I have not once gotten the diff edit to work. It is possible that somehow, the tool call is simply misleading gemini-2.0-flash-exp into adding an extra whitespace or newline at the end.  If that is however the problem, it should be quite easy to fix with custom instructions.
Steps to reproduce

Create a python file called diff_edit_test.py. Add the content:

# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# Diff edit this line into a print statement
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence
# This is a sentence

Send cline/gemini-2.0-flash-exp the prompt "Diff edits are currently broken, and I need to find out why. Read the diff_edit_test.py file and try to diff edit line 9 (# Diff edit this line into a print statement ) into print("diff edits work!")"

Relevant API REQUEST output
replace_in_file for 'diff_edit_test.py'] Result:

The tool execution failed with the following error:
<error>
Error writing file: The SEARCH block:
# Diff edit this line into a print statement
...does not match anything in the file.
This is likely due to differences in whitespace or line endings between the SEARCH block and the actual file. Try again with a more precise SEARCH block.
(If you keep running into this error, you may use the write_to_file tool as a workaround.)
</error>

Additional context

Yup! just watching this same bug occurance on loop. I also provided Custom Instruction: "Don't use replace_in_file to edit files, you are only allowed to use write_to_file"

I have the same problem on .razor files (Blazor), I just disabled the diff editing stuff.

I see similar behavior and I think it's due to Prettier running after save and changing whitespace. I --think--.

I had to downgrade to 2.2.0 due to similar issues with Ollama Models like qwen

Can I please see the actual search/replace provided by the model? You can find this by expanding the file:

This doesn't seem to be a model problem based on the information you provided. If it's providing a valid search, and the extension is failing to apply the diff then it is probably an issue with parsing the model's diff properly.

I cannot open the diff edit failed block to see the search/replace, and there is no cline wants to edit this file where it is supposed to be. Instead, I have provided this, which should be taken with a grain of salt as it is AI generated, but is likely correct:

Oh wow it seems it's unable to even call the tool correctly in the first place. Note to contributors: try to reproduce this with gemini and check global storage (lib/app support/code/saoudrizwan.claude-dev/user/global/tasks/conversation_history.json) and see what the model is outputting that the extension is failing to parse. It could be introducing some artifact we need to filter.


Clean up using attemptCatching

I'm avoiding the elvis operator on purpose. This would be way neater with it, though, because elvis is the idiomatic way to do "recovery".

Thanks for the PR, @kyay10 !
I'm not going to merge it, as I made some more changes on the main branch. Your version is available there under src/main/kotlin/NumberParserMonadRaise.kt


feat(api): Add kubernetes version to coredns version mapping

Added script and makefile target to update coredns version mapping.
make coredns.sync will fetch the list of releases from upstream
release branches and create a mapping k8s releases to coredns versions.

Can you explain how this is used? The CoreDNS version mapping aren't referenced anywhere in this PR.

Can you explain how this is used? The CoreDNS version mapping aren't referenced anywhere in this PR.

Indeed, this PR just adds the mapping. We will need more changes to actually use that mapping (subsequent PRs). For cluster-class based clusters, we need a post cluster upgrade hook in CAREN that will set the CoreDNS version to the new the new version. For classic clusters, CAREN isn't in the picture, so we will need to also adopt that logic in the classic upgrade path.

Ah OK this is for the CoreDNS upgrade issue

Question: How do we ensure that the mapping stays up-to-date with the supported Kubernetes versions? I'm not sure that we define "supported Kubernetes versions" anywhere in the repo, actually. We also have a mapping https://github.com/nutanix-cloud-native/cluster-api-runtime-extensions-nutanix/blob/c644526d967b6c2778d34a7a75908a1042110d20/charts/cluster-api-runtime-extensions-nutanix/values.yaml#L74-L79 of versions for a different purpose.
I think we need a "source of truth" for supported Kubernetes versions, but we don't have to add it in this PR.

Thanks for updating the semver package.

Question: How do we ensure that the mapping stays up-to-date with the supported Kubernetes versions? I'm not sure that we define "supported Kubernetes versions" anywhere in the repo, actually. We also have a mapping
https://github.com/nutanix-cloud-native/cluster-api-runtime-extensions-nutanix/blob/c644526d967b6c2778d34a7a75908a1042110d20/charts/cluster-api-runtime-extensions-nutanix/values.yaml#L74-L79
of versions for a different purpose.
I think we need a "source of truth" for supported Kubernetes versions, but we don't have to add it in this PR.

The script in this PR looks for every version greater than a minimum version (default v1.22: 10 versions old). The source of truth is basically lookups to k/k every time this script is run (pre-commit).


Configuring rabbitmq server / rabbitmq_sensu_password

I would like to set non-default values here. I changed the variable of rabbitmq_sensu_password to something else other than sensu and then deployed the changes. I found that the deployment completed but it was broken. Checking the logs suggested the rabbitmq credentials were wrong. So I changed the json file back to the default password of sensu and restarted the services and all was working once again. I cannot see another variable which does the server side configuration of rabbitmq.
Is it possible to set server side properties with this role here? If not then I would I need another role for that.

Hey @tonyppe!
So, I haven't personally tried changing rabbitmq_sensu_password but, looking through the code, it get's propagated to https://github.com/sensu/sensu-ansible/blob/master/tasks/rabbit.yml#L48-L56 which should be updating the actual user in RabbitMQ. Based on what you put here, it sounds like the password isn't getting propagated to the server config.
Tracing that, if, sensu_transport is set to rabbitmq then we do this bit: https://github.com/sensu/sensu-ansible/blob/master/tasks/common.yml#L28-L41 where sensu_rabbitmq_config defaults to https://github.com/sensu/sensu-ansible/blob/master/defaults/main.yml#L67 and thus uses https://github.com/sensu/sensu-ansible/blob/master/templates/sensu-rabbitmq.json.j2 which is also using the rabbitmq_sensu_password variable here: https://github.com/sensu/sensu-ansible/blob/master/templates/sensu-rabbitmq.json.j2#L13
So, from what I'm seeing, we're properly configuring both the RabbitMQ side and the Sensu Server side. If changing the password back to the default worked in the Sensu config, then the step at https://github.com/sensu/sensu-ansible/blob/master/tasks/rabbit.yml#L48-L56 must not have actually updated the RabbitMQ password.
I chekced out the docs on that rabbitmq_user module, and it looks like from https://docs.ansible.com/ansible/latest/modules/rabbitmq_user_module.html#rabbitmq-user-module,

To change the password of an existing user, you must also specify force=yes.

So, the 'cheap' answer is that we need to get force: true added to that task, but, looking just through the docs, every Ansible run is going to cause that entire user to be re-created which is not ideal.
In the meantime, you can also use rabbitmqctl change_password to update the user in RabbitMQ (Docs: https://www.rabbitmq.com/rabbitmqctl.8.html#change_password ) that should also unblock.

Yeah, confirmed that the rabbitmq_user module with always delete and re-add the user if we use force https://github.com/ansible/ansible/blob/v<IP_ADDRESS>-1/lib/ansible/modules/messaging/rabbitmq_user.py#L285-L289
Looks like there's quite a number of open PR's to fixup the module to be a bit nicer that have not gotten merged as well.

Thanks Jared! I will check more on this and come back here. For the moment this isn't really an issue; since I am still working out a plan then the defaults are fine. If I want to I can configure the server manually before doing the deploy if this is the case.
thanks again for your help and thorough information!

Sounds good, at this time, I'm not finding anything from Ansible itself that will allow us to cleanly allow changing the password with the current rabbitmq_user module that also doesn't involve completely deleting and re-making the user. Let me know if you're able to work around this, and I've subscribed to the PR's that are already open to make this easier, if those get released, I'll follow up here.

Sadly, Ansible has yet to address this upstream. If the above linked PR's are ever merged (some have been open for months now) we can do some work here. However, until then, I can't see a sane way that this can be supported within this role 😞
I'm going to close this out, and am still subscribed to the above PR's such that if they do get released, we can revisit this. If anyone has any other ideas on how to support this, I encourage you to open a PR and we can discuss the options there.


AttributeError: 'NoneType' object has no attribute 'text'

This was run in ipython notebook (python 2.7.11)
/Users/megablanc/Library/Python/2.7/lib/python/site-packages/craigslist/__init__.pyc in get_results(self, limit, sort_by, geotagged)
    158                 price = row.find('span', {'class': 'price'})
    159                 where = row.find('small')
--> 160                 p_text = row.find('span', {'class': 'p'}).text
    161
    162                 result = {'id': id,

AttributeError: 'NoneType' object has no attribute 'text'

Full code:
from craigslist import CraigslistHousing

cl = CraigslistHousing(site='boston', area='gbs', category='roo',
                         filters={'max_price': 2000, 'min_price': 500})

results = cl.get_results(sort_by='newest', geotagged=True, limit=20)
for result in results:
    print result

I get a couple results but eventually it crashes.

It seems like this particular line of code was changed in the repo...is the pip version out of date?

Seems like it. I had the same issue until I re-ran my pip installer with "pip install git+https://github.com/juliomalegria/python-craigslist"
Hope this simple solution helps others who had the same issue.

The solution from @WIRUT worked great with a fresh virtualenv.

Yep, this is the same as #16. I've made the fix already, but haven't released a new version to PIP. I was waiting for more fixes/improvements, but if this is affecting to people already, I'll go ahead and make a new release soon.


Update login app from NodeJS 12 to latest

Describe the issue
In the latest ASEA patch the nodejs12.x lambda runtime is being deprecated. Our login application uses nodejs12.x so we'll need to upgrade to 14 in ECF Forge, Assembly and Live
Additional context
Add any other context, attachments or screenshots
Acceptance Criteria

In ECF Forge, upgrade the Login application's lambda runtime from "nodejs12.x" to "nodejs14.x"
Test the login application's functionality in Forge
In ECF Assembly, upgrade the Login application's lambda runtime from "nodejs12.x" to "nodejs14.x"
In ECF Live, upgrade the Login application's lambda runtime from "nodejs12.x" to "nodejs14.x"
Test the login application's functionality in Live

The code has been quickly review checking for breaking change on the NodeJS Changelog and nothing appears.
We have change the version of the lambda and tested on lz0, everything was working well.
It's going to be deployed by max on lz1 today and lz2 monday if everything is going smoothly.
The PR of the module : https://github.com/BCDevOps/aws-login/pull/10


Geospatial component for heightmaps (2nd try)

🎉 New feature
Second attempt at adding geospatial component.
Summary
Our first attempt at the geospatial component did not have gdal installed in macOS or Windows CI, and we didn't notice because the geospatial component is an optional dependency. This had broken ign-rendering builds, so #267 and #289 were reverted in #291. These dependency issues have been resolved in https://github.com/osrf/homebrew-simulation/pull/1790, https://github.com/ignition-tooling/release-tools/pull/626, and https://github.com/ignition-tooling/release-tools/pull/624, so let's try re-adding these pull requests.
This needs to be merged in sync with downstream pull requests to ign-rendering, ign-physics, and ign-gazebo.
Test it
UNIT_Dem_TEST is the primary test added in this pull request, but this should also be tested with downstream branches.
Checklist

[X] Signed all commits for DCO
[X] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[X] Updated migration guide (as needed)
[X] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

there is a test failure with dem_nodata.dem on both homebrew and windows. I'm guessing it's related to the version of gdal or proj
from windows:
59: [ RUN      ] DemTest.UnfinishedDem
59: C:\Jenkins\workspace\ign_common-pr-win\ws\ign-common\geospatial\src\Dem_TEST.cc(184): error: Expected equality of these values:
59:   7499.8281
59:   demNoData.WorldHeight()
59:     Which is: 7499.8838
59: C:\Jenkins\workspace\ign_common-pr-win\ws\ign-common\geospatial\src\Dem_TEST.cc(185): error: Expected equality of these values:
59:   14150.225
59:   demNoData.WorldWidth()
59:     Which is: 14150.134
59: [  FAILED  ] DemTest.UnfinishedDem (185 ms)

from macOS
64: [ RUN      ] DemTest.UnfinishedDem
64: /Users/jenkins/workspace/ignition_common-ci-pr_any-homebrew-amd64/ign-common/geospatial/src/Dem_TEST.cc:184: Failure
64: Expected equality of these values:
64:   7499.8281
64:   demNoData.WorldHeight()
64:     Which is: 7499.8838
64: /Users/jenkins/workspace/ignition_common-ci-pr_any-homebrew-amd64/ign-common/geospatial/src/Dem_TEST.cc:185: Failure
64: Expected equality of these values:
64:   14150.225
64:   demNoData.WorldWidth()
64:     Which is: 14150.134
64: [  FAILED  ] DemTest.UnfinishedDem (38 ms)

knowing very little about DEM files, I tried running gdalinfo dem_nodata.dem, but I can't find my way to either of those values
$ gdalinfo dem_nodata.dem
Driver: GTiff/GeoTIFF
Files: dem_nodata.dem
Size is 65, 65
Coordinate System is:
PROJCRS["NAD27 / UTM zone 10N",
    BASEGEOGCRS["NAD27",
        DATUM["North American Datum 1927",
            ELLIPSOID["Clarke 1866",6378206.4,294.978698213898,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4267]],
    CONVERSION["UTM zone 10N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-123,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Engineering survey, topographic mapping."],
        AREA["North America - between 126°W and 120°W - onshore. Canada - British Columbia; Northwest Territories; Nunavut; Yukon. United States (USA) - California; Oregon; Washington."],
        BBOX[34.4,-126,77.13,-120]],
    ID["EPSG",26710]]
Data axis to CRS axis mapping: 1,2
Origin =<PHONE_NUMBER>00000000000,5122005.000000000000000)
Pixel Size =<PHONE_NUMBER>23076934,-216.000000000000000)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  557805.000, 5122005.000) (122d15' 0.36"W, 46d15' 4.05"N)
Lower Left  (  557805.000, 5107965.000) (122d15' 6.53"W, 46d 7'29.19"N)
Upper Right (  567615.000, 5122005.000) (122d 7'22.25"W, 46d15' 0.79"N)
Lower Right (  567615.000, 5107965.000) (122d 7'29.48"W, 46d 7'25.94"N)
Center      (  562710.000, 5114985.000) (122d11'14.66"W, 46d11'15.06"N)
Band 1 Block=65x63 Type=Int16, ColorInterp=Gray
  NoData Value=-32767
  Unit Type: m

the "Corner Coordinates" section seems promising, but computing differences doesn't give values that match up with the test expectations of approximately 7499.8 and 14150
>>> 567615.000 - 557805.000
9810.0
>>> 5122005.000 - 5107965.000
14040.0

Per VC, there may not be a reliable way to calculate world width/height because of projections and coordinate transformations. Instead will try to set world dimensions with projected measurements since we can get meters per pixel. This is possible with already projected DEMs (projected coordinate system), need to be sure it's possible when they are in a geographic coordinate system.

A workaround to load non-Earth DEMs fa605bd0dd82828615dfdb8ef8dc9031d03a2a4a and I've created an issue regarding computing the world dimensions https://github.com/ignitionrobotics/ign-common/issues/311.
I believe this PR is ready for review

I believe this PR is ready for review

looks like there's a just a few windows compiler warnings to fix

Hmmm, do you know what changed windows ci? These warnings didn't appear when we merged https://github.com/ignitionrobotics/ign-common/pull/267

Hmmm, do you know what changed windows ci? These warnings didn't appear when we merged #267

I think windows CI wasn't fully working when we merged #267. I believe it landed in the following build:

https://build.osrfoundation.org/job/ign_common-ci-win/12/

CMake Warning at C:/Jenkins/workspace/ign_common-ci-win/ws/install/ignition-cmake2/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:55 (message):
   CONFIGURATION WARNINGS:
   -- Skipping component [geospatial]: Missing dependency [GDAL].
      ^~~~~ Set SKIP_geospatial=true in cmake to suppress this warning.

@osrf-jenkins run tests please

it looks like the windows build fails on one jenkins node and passes on the other:

https://build.osrfoundation.org/job/ign_common-pr-win/202/ passes on https://build.osrfoundation.org/computer/win-windows_nuc.win10
https://build.osrfoundation.org/job/ign_common-pr-win/203/ and https://build.osrfoundation.org/job/ign_common-pr-win/204/ fail on https://build.osrfoundation.org/computer/win-beefy.win10

cc @j-rivero

it looks like the windows build fails on one jenkins node and passes on the other:
* https://build.osrfoundation.org/job/ign_common-pr-win/202/ passes on https://build.osrfoundation.org/computer/win-windows_nuc.win10

* https://build.osrfoundation.org/job/ign_common-pr-win/203/ and https://build.osrfoundation.org/job/ign_common-pr-win/204/ fail on https://build.osrfoundation.org/computer/win-beefy.win10

cc @j-rivero

I've sent https://github.com/ignition-tooling/release-tools/pull/657. Bad news is that our vcpkg snapshot is too old to work (mirrors already removed the required versions from our snapshot). I don't think that the problem is a blocker to merge this PR.


Add game loader screen

Closes #13.
Should close #92.
TODO

[x] Loader animation
[x] Run tests on CI
[x] Finish the loading scene and show it on the start
[x] Pack loader resources properly (.svg → .png on build)
[x] Add logic to download resources on startup, wire with preloader
[x] Add logic to use already loaded resources on startup
[x] Rebase onto main
[x] Add disclaimer text (in English for now in all supported languages)
[x] Check the issues we're claiming to close: there should be no leftover TODOs
[x] Ensure we truly unblock #47
[x] Migrate everything to Tasks

[x] Check that we properly switch to the thread pool

[x] Localize everything
[ ] Final UI sweep

Before merge

[ ] TODO sweep

After merge

[ ] Unblock #47
[ ] Raise an issue on local game config file (with data location)

Drop command line argument for resource location
Allow to override config via environment
Remove the launchSettings.json from .gitignore (it should no longer be required to pass any non-shareable parameters there)

@kant2002, could you please take a look at the Ukrainian translation I've managed to prepare using ChatGPT and Google Translate?


Conflict HTTP Basic Auth with JWT Token

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?

Yes

Are you sure you're not using someone else's docker image?

Yes

Have you searched for similar issues (both open and closed)?

Yes

Describe the bug

When i tried to manage login localhost:81 with SSL and HTTP Basic Auth, i got error on api/token, i think there's conflict between HTTP Basic Auth with JWT Token because it has same auth headers
Nginx Proxy Manager Version

v2.9.3
To Reproduce
Steps to reproduce the behavior:

login nginxproxymanager from local-IP:81
create proxy host with subdomain pointed to local-IP port 81
create user+password on Access List menu
edit proxy host then enable non public Access List
try to login from subdomain
it will prompt for insert username+password
subdomain with nginxproxymanager can be opened but can not login, it will say unathorized
i can login from subdomain if i disabled HTTP Basic Auth or change Access List to Public Access

Expected behavior

Can use HTTP Basic Auth and not conflicted with JWT Token login
Screenshots

Operating System

Docker on Ubuntu 20.04
Additional context

Unfortunately your expectation cannot be met.
There's an argument to be made that the JWT is more secure than basic auth anyway.
Instead of using basic auth you can use ip rules to make access to the admin more secure.


Bootstrap debug logging

This PR adds some helpers that allows executed commands to properly make it to a log file or STDOUT/STDERR based on setting the DEBUG ENV variable.
/cc @Kami

Nice, this should save us some time when troubleshooting user problems. :+1:
I will test it tomorrow.

:+1:

@lakshmi-kannan or if you want / have time, you can test it as well :P

Pushed a change since - is apparently not a valid character for a function name in sh.
I did actually suggest we should just default to bash, but other people thought defaulting to sh is better :P

I also updated "script/preflight-os" to also use this new function since this was actually the main offending part which logged to a file instead of stdout / stderr.

I did actually suggest we should just default to bash, but other people thought defaulting to sh is better :P

😐

In confirmed it now works with the latest changes:
Ensuring pre-flight libraries are setup...
Running bundle install --path vendor/bundle --deployment --binstubs...
Installing rake (10.3.2) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/rake-10.3.2.gemspec
Installing CFPropertyList (2.2.8) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/CFPropertyList-2.2.8.gemspec
Installing i18n (0.7.0) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/i18n-0.7.0.gemspec
Installing json (1.8.3) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/json-1.8.3.gemspec
Installing minitest (5.8.0) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/minitest-5.8.0.gemspec
Installing thread_safe (0.3.5) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/thread_safe-0.3.5.gemspec
Installing tzinfo (1.2.2) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/tzinfo-1.2.2.gemspec
Installing activesupport (4.2.3) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/activesupport-4.2.3.gemspec
Installing builder (3.2.2) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/builder-3.2.2.gemspec
Installing activemodel (4.2.3) from /opt/puppet/vendor/bundle/ruby/1.9.1/specifications/activemodel-4.2.3.gemspec
...

I will test it some more and if everything looks OK merge it into master.

Tested it on multiple servers with and without DEBUG environment variable. It appears to be working OK so I will go ahead and merge it.


Followup on #146

Description
This should just unblock master for now, mystery not yet solved but 🤷 #146

I'm going to deploy this branch directly into heroku master and check if everything is good.

@froi seems to be holding up, feel free to merge.


Style example property error

Property="Shell.ShellTabBarBackgroundColor"
Property="Shell.ShellTabBarTitleColor"
Property="Shell.ShellTabBarUnselectedColor"
These properties are wrong,
the correct usage should be
Shell.TabBarBackgroundColor
Shell.TabBarTitleColor
Shell.TabBarUnselectedColor

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ef7242a0-d46e-19ea-e22d-f327dcc9b3e9
Version Independent ID: f050be8e-9413-19e7-5799-90a55c4e5bfb
Content: Xamarin.Forms Shell Layout - Xamarin
Content Source: docs/xamarin-forms/app-fundamentals/shell/tabs.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @zy55769068
While you're correct that the properties you've identified have been renamed, the correct naming is Shell.BackgroundColor, Shell.TitleColor etc.
The docs have just been updated, and will continue to receive more updates this week.


Error runing on ios simulator

Error (Xcode): In /Users/{user_name}/.pub-cache/hosted/pub.dev/flutter_curl-0.2.0/ios/Curl.framework/Curl(nghttp2_pq.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/{user_name}/.pub-cache/hosted/pub.dev/flutter_curl-0.2.0/ios/Curl.framework/Curl' for architecture arm64
Could not build the application for the simulator.
Error launching application on iPhone 14 Pro Max.
xcode version 14.2
ios version 16.0
flutter doctor -v output
[✓] Flutter (Channel stable, 3.7.9, on macOS 13.3 22E252 darwin-arm64, locale en-IN)
• Flutter version 3.7.9 on channel stable at /Users/{user_name}/Development/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 62bd79521d (4 days ago), 2023-03-30 10:59:36 -0700
• Engine revision ec975089ac
• Dart version 2.19.6
• DevTools version 2.20.1
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
• Android SDK at /Users/{user_name}/Library/Android/sdk
• Platform android-33, build-tools 33.0.2
• ANDROID_HOME = /Users/{user_name}/Library/Android/sdk
• Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 14C18
• CocoaPods version 1.12.0
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2022.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)
[✓] Connected device (3 available)
• iPhone 14 Pro Max (mobile) • A9ED1A36-88A0-485A-9A7A-E350E60A1E12 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-16-0 (simulator)
• macOS (desktop)            • macos                                • darwin-arm64   • macOS 13.3 22E252 darwin-arm64
• Chrome (web)               • chrome                               • web-javascript • Google Chrome 111.0.5563.146
[✓] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!

Interesting. Seems to work fine in my setup which is pretty much same. Is this M1 or M2?
Did you recently update the library to 0.2.0? Then you might have to do a clean build.
Also try running in a device too to see if that works.

Its an M1 mac mini
No i was already using the 0.2.0 version
It works fine in android but cannot launch it on iOS simulator.

after running flutter clean and flutter pub get the same original error comes back

I have pushed a patch to sim-arch branch. Could you try it?
You can change your pubspec like this:
    flutter_curl:
        git:
            url: https://github.com/ajinasokan/flutter_curl
            ref: sim-arch


refactor(plugins) removing ngx.req.raw_header() for HTTP/2 compatibility

Enables HTTP/2 compatibility by removing ngx.req.raw_header() invocation calls.

Updated.

(fixed merge conflict and squashed)