Upgrade Papyrus version

[J17359]

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

Ideally, upgrade to the latest version of Papyrus, but I'll leave that up to you to evaluate. I'd say at least 6.x. The version CX currently delivers is 4.8.0 (2020-06). There are two newer major releases 5.x and 6.x available on their home-page.

[eposse]

An update:

I managed to resolve the freemarker issues and I can build it. But it looks like its dependency on log4j is optional after all and we may be able to get away without its patch. The same may be true for Ant. I'm investigating this. I hope so, because Ant has a very weird and special build, different from anything else.

As I realized that the dependency is optional made me think that the same may be true for other patches, so I'm going step-wise through all the patches to see where it may be optional. The idea is to determine the set of patches that are absolutely required while ensuring that there is absolutely no bundle remaining depends on log4j 1.

While doing that, I discovered that another patch was missing for a component required by Papyrus called org.eclipse.nebula.widgets.nattable, but looks like it's easy to patch.

[eposse]

An update:

I've finally managed to build it so that the generated RCP doesn't include log4j 1, even though it still keeps the old apache ant.

So it is very close to be ready for testing. Nevertheless, I need to update the GitHub workflow because that one fails on this branch, since I updated only the RCP and not the other build artifacts (update sites, ATCD, etc.)

I'll let you know when I get the build working on GitHub.

[eposse]

@j26151 An update: (I posted this in the PR so I'm re-posting it here in case you didn't see it.)

I got the GitHub build working. It seems to be free of any traces of log4j 1. I am testing the resulting artifacts, but you might start your own tests as well. You can get the RPM and ZIP files here.

I expect there will be a few issues. I will be testing myself in the next few days.

Let me know of any issues that you run into.

[eposse]

BTW, it needs Java 17.

[eposse]

Preliminary testing on CentOS 7 seems to show everything working fine.

[emammoser]

Java 17 shouldn't be a huge problem. We are no longer running on CentOS 7 since it is no longer supported. We have moved to Alma Linux 8. I wouldn't expect any different issues, just letting you know. Our team does not have any extra capacity to spare dedicated developers to test this feature for the rest of the year. I do not yet know about allocation for our team next year. I would not wait on our team to confirm these changes.

[eposse]

Ok, I understand. I will keep testing on my end, and in particular I will setup an Alma Linux 8 VM to test. I will also work on integrating back Papyrus Compare, which if you remember, we had left aside while working on the rest of the patches, as you said it was not the main priority.

I assume we continue this work on the branch, leaving the PR open until you have time to test it, correct? Or should I merge it once I am confident enough and deal with potential issues in the new year?

[eposse]

An update:

I successfully integrated Papyrus Compare and I continued testing. Code generation works as before. But during testing I found a bug when opening diagrams and the deployment editor. I am debugging this by comparing the behaviour in the old version (Papyrus 4.8) with the new one (Papyrus 6.5). I found a difference in the objects representing diagrams being created which is the cause of the bug, but I do not know yet why that happens. I continue investigating.

[eposse]

Just to give you another update:

The problem is related to architecture contexts and viewpoints. The code in Papyrus that handles these has changed drastically from 4.8 to 6.5. I'm still narrowing down the exact point where the problem originates. I have found a few places where this may be happening but I might need to contact the Papyrus developers.

[eposse]

A new update. I have been investigating problems related to the architecture context/viewpoints that arose during testing. I have fixed one that prevented the opening of the Deployment Editor, but there are others, preventing the creation and opening of standard UML diagrams, and resulting in an empty "New Diagram" pop-up menu. These are all related. I was able to create a minimalistic architecture model and tested it in plain Papyrus 6.5 and can confirm that the problems are with Papyrus, not with CX. I have been able to narrow down the Papyrus component responsible for this bug (it's the "Architecture Domain Merger" and happens when you open a Papyrus model for the first time during a session.) I am now in touch with the Papyrus developers to try to figure this out. I'll keep debugging it to see if I can patch it myself, rather than wait who knows how long before the Papyrus team fixes it.

PS: I'm off next week and I'll be back after New Year's.

[emammoser]

Thank you for the follow up. Hopefully this is something that can be resolved relatively quickly but keep us updated as you learn more.

[eposse]

A new update:

I was finally able to figure out the root cause of the bug. There is an bug in the algorithm that merges "Architecture Contexts" in Papyrus (not CX). I'm working on a solution, but it is not trivial, as this code impacts a lot of things that Papyrus does. But I have good reasons to think that I'll be able to fix it soon.

[emammoser]

Glad to hear it! Thank you for the update.

[eposse]

A status update: I have a solution that appears to work and seems to work on most cases, but there are still a couple of things that don't quite work, so I'll be digging into these. But I think I'm nearly done. Nevertheless, I think that we may need to migrate models, which is natural to expect considering we are jumping from Papyrus 4.8 to 6.5. But I think the migration rule would probably be relatively simple.

[eposse]

By the way, since we are making such a major version jump, perhaps we should also do a major version jump in CX from 2.6 to 3.0?

[emammoser]

I think it makes sense to do a major version jump to 3.0 personally. @J17359 thoughts?

[J17359]

Yes, 100% agree. Something this drastic should be a major version bump.

[eposse]

Sounds good. I'll update the version once I'm done fixing all the issues I've found with the patches.

[eposse]

I've finally resolved all the pending issues, and everything seems to be working well. I think it's ready for you to test. I'll just do a bit of code cleanup, start a build and let you know when it's ready for you to download.

[eposse]

Ok, the build is finally ready for you to test. You can get it in this link. I've tested it on AlmaLinux 8.9. Everything works as expected as far as I can see. No Log4J 1 to be seen. Only Log4J 2.17.1.

Note that the RPM still has version 2.6.0, but it is the right one, so you can test it. I'm now going to update the version to 3.0.0 as discussed in #490.

[eposse]

Closing as agreed with @j26151 by e-mail on February 26, 20024.