[Feature Request] Change element type

[etienne-sf]

Hello,

After sending a big wishlist, in the General Archi Discussion forum, I started a local test on the "Change type' issue.

As you already answered several times, changing the type of an element (or a relationship) is a complex stuff.

And I can confirm that, after fighting several hours on this one. Discovering EMF is already a journey. :)

BTW, the jArchi plugin allows to do this. And it seems to me that the code in jArchi could be incorporated in archi, in a way or another.

Is there a reason why it's not done ? I can see several such reasons:

• It would not work
• You don't have time (I can help, here)
• You don't want to, to encourage donation on jArchi

So my question here is a simple one (to begin with :) ):

If I work on this "Change Type" capability (for instance, changing a BusinessRole into a BusinessActor) in archi.exe, would it be a good idea according to you and what you want archi to be?

Etienne

[Phillipus]

I might consider implementing it natively in Archi in 2021.

It would not work

It would work.

You don't have time (I can help, here)

Correct. But I don't need help - it would take longer.

You don't want to, to encourage donation on jArchi

Wrong. That's a pretty dumb thing to say.

It seems that everyone wants their favourite Archi feature implemented now, and of course with free 24/7 support. I'm growing tired of the continual sense of entitlement.

[Phillipus]

Closing this as it's covered in #663

[etienne-sf]

Hello,

I know you just closed it, but it's not really covered by #663, as this one is about relation ship.

And when I say I can help: I've already done a good part of the job, and I'm willing to help.

I'm not asking you to do it. I'm sorry if I was unclear, so here is my real question: if I do it properly, would you accept the PR ?

Etienne

[Phillipus]

would you accept the PR ?

It would take me longer reviewing and re-writing a PR than if I just implemented it myself. I don't have the time to look at this right now. We have a roadmap for Archi on the website, and there are greater priorities before this.

[jbsarrodie]

Hi guys,

It seems to me that there is some misunderstanding here.

@Phillipus I don't read Etienne's issue as "I want this now", so if he wants to try working on this and don't expect you (or me) to review it before some weeks or month, then that might be a good way for him to start understanding the codebase. It will of course take him more time than your (or even me) to do it, but that's how someone learn. 8 years ago it was taking me ages to create some bad hack in Archi's code ;-)

@etienne-sf: The main reason why we don't work on this kind of request is because it can be done with jArchi. Creating jArchi (which is opensource so anyone can clone the code and compile it) was a way for us to make it easier for people to code the feature they want for Archi so that we can focus on the real difficult (thus core) ones. This specific use-case is covered by the script I shared some time ago, making it not urgent for us.

One important thing to know is that working with EMF is easy, but making things available in Archi's UI taking the undo/redo stack into account is more difficult and takes time. For jArchi to work and in order to be able to undo the changes made by a script, Phil had to create a jArchi specific undo/Redo mecanism. That's the reason why jArchi is so powerful, but also why something that can be done with it has to be full coded again (and in a different way) in the core of Archi if we want this feature to be "native".

So to answer your question: you can of course work on this and submit a PR, but understand that it will certainly take some (read a lot) of time before we can review it, not because we don't want it, but because we don't have much time and we are focusing on other features.

BTW, I read your post the day you posted it (and liked it very much), but more than 2 months after, I still havent found time to reply because there's only one me and I have only few hours available each week. I wish I could have more time ;-)

[etienne-sf]

OK, I understand Philippus's point. It's true that the code is both really complex, and very clean and stable. And I understand that you don't want to break it. And you think that receiving help will consume more from your time in code check, than your time to develop it.

It's a little sad to me, as I think I've done a good part of the way, to get it done. And I think I'll be conform to your code quality standard (including undo and redo). But there is no issue there, as you where very precise on this point ("Do not just submit code or a Pull Request without prior agreement. It will be rejected.").

@ jbsarrodie, Thanks for your answer. I feel better with this one. But I'm unable to use jArchi. It seems nice. I don't have credit for a donation. And I've not been able to use it with archi from its source code. I find it simpler to implement it in archi (despite undo, redo, integration in EMF, managing folder and other featureIDs...)

But, then, how can others contribute to archi ? Or, simpler : how can I help?

Etienne

[jbsarrodie]

It's a little sad to me, as I think I've done a good part of the way, to get it done. And I think I'll be conform to your code quality standard (including undo and redo). But there is no issue there, as you where very precise on this point ("Do not just submit code or a Pull Request without prior agreement. It will be rejected.").

We were very precise on this point ;-)

More seriously, don't be sad. We don't say we won't look at it, but it will take time for us to be able to do so (and you might expect 6 month before we do it).

But I'm unable to use jArchi. It seems nice. [...] And I've not been able to use it with archi from its source code.

Well, download Archi's code, download jArchi's code, then simply compile jArchi as a plugin like any other plugin you would have developed (See https://github.com/archimatetool/archi/wiki/Developing-Import-and-Export-Plug-ins#deploying-the-plug-in).

I don't have credit for a donation.

That's not needed as its open source. We simply decided to not make the binary version available outside of Patreon. That being said, we'll be very happy with a small donation ;-)

I find it simpler to implement it in archi (despite undo, redo, integration in EMF, managing folder and other featureIDs...)

Did you manage to check that all relationships are still valid after having changed the type? If they are invalid, do you prompt the user to offer him to stop and roll back, or to continue and remove them, or to continue and convert them to association, and then, do you offer to keep track of the fact that they were converted as a side effect of another conversion? And even if relationships are still allowed this doesn't make them valid, so how to you manage this ? etc...

But, then, how can others contribute to archi ? Or, simpler : how can I help?

That's a good question. I must admit that, because nobody actually contributed features (except Mads 7 years ago and of course Herve with its plugins), we're not that good and maintaining a list of things that people could contribute too, because this costs us time we don't have.

So I guess that these ideas could be considered:

• Test new versions and provide feedback
• Provide support to other people on the forum
• Provide new features through jArchi (this makes it easy for people to test them)
• Provide new features as plugins
• Look at opened issues (and some closed one) to see potential new features for Archi itself or coArchi or jArchi, write a good description of the addressed use-case and the potential solution in a wiki page and discuss it with me. I'm usually acting as a kind of product owner and if the described feature insert itself into a bigger use-case we have in mind, then we'll be able to dispatch the work.

TBH, while I write these lignes, I think there's a real need to extend jArchi to expose new methods and support new use-cases. We're also working on coArchi 2 so it might be worth looking at it (we'll soon have to rewrite from scratch a new diff/merge engine).

[Phillipus]

Re-opening...

[jbsarrodie]

Hi,

I've noticed #699. Before moving on and implementing this, we should first agree on the behavior as it can't be as simple as selecting the target type only. Might be worth looking at this issue for a reminder of previous discussions about it.

So again, here are the key points, based on the implementation done in my jArchi scripts set:

• User should first decide what to do with invalid relationships. Only two options here: abort or convert to associations (and then keep track of previous type in a comment added into the documentation attribute).
• If 'abort', then the whole operation should succeed only if all elements can be converted. This means that as soon as converting one element leads to unvalid relationship, we should roll-back the whole operation.
• The new feature should be able to also change type of relationships. But this adds additional checks (junctions)
• The "new" concept should have a new id and not reuse the old one as this is no more the same concept (this is to avoid side effects on model import feature, coArchi...)

Btw, "refactor" is not really a good menu name (sounds too technical to me). A simple "Change type..." menu with per layer sub-menus seems better.

[etienne-sf]

Hello,

You just closed the #700 Pull Request. And restricted comments to collaborators

FYI:

• There is no link with an issue about donating 1$. My use of archi is not big enough to justify learning an additional tool. That's all.
• As I explained, I'm working on another open source project, where there is feedback that I must take into account.
• I'm still willing to implement this #700 PR, and respect the guidelines and comments you provided.

But perhaps it's too late now.

Etienne