Remove duplicate code and use jArchi API

[jbsarrodie]

Hi,

As it is now, I don't consider that we can host this plugin on archi-contribs: plugins hosted there sometimes lead to people thinking that we maintain them. So we try to make sure that this risk is as limited as possible.

Asof now, your plugin duplicate the whole jArchi API, which means that each time we'll change something on jArchi, people will expect it to be available in your plugin and will most certainly open an issue on our repo.

So what I would suggest is for your plugin to only add groovy support without duplicating the API itself. This means that you plugin would have to be installed alongside with jArchi, letting people use groovy but with the API that we are maintaining. This is similar to the behavior we would have had with you pull request and which makes sens IMHO.

Regards,

JB

[grrolland]

Hi,

I untderstand and share all the risks you mention.

While there is no Archi Scripting API extension, I do not remove the duplicated code. I wants my module to be usable by all peoples, so I can't rely on a module which binaries are not available.

As say in archimatetool/archi-scripting-plugin#64, If you publish an Archi Scripting API module as a default plugin of Archi (as a free downloadable binary distribution), I will remove the duplicate code in the Groovy Script Plugin and modifying my code to use this new plugin.

Discussion should continue here : archimatetool/archi-scripting-plugin#64

Regards.

[jbsarrodie]

I wants my module to be usable by all peoples, so I can't rely on a module which binaries are not available.

The reason why there is no binaries available is because people never contributed (in any way, not only donations) to Archi before. At some point we had to take a decision, and our decision was to make jArchi opensource but not distribute the binaries. This let people with two choices: either compile it themselves, or donate at least 1$ to get it.

This has proven to be a mind changer for users who started to support Archi and we want to stick with this.

Providing a plugin which extends jArchi would not only be a way to make sure that you are up to date with the API, this is also a way to respect the work being done and the spirit around Archi & jArchi.

But of course, this is opensource and you can do whatever you want at the end.

[grrolland]

I understand and respect you reasons. I respect the work you have done.

I just want to distribute my plugin without breaking your work and the model of distribution you have chosen.

I think there is only one way to do this : publish a Scripting API as a plugin (which is not usable without anoter language Srcipting plugin - jArchi or another), so your model will be preserved and my plugin will not duplicate your code.

[jbsarrodie]

I think there is only one way to do this : publish a Scripting API as a plugin (which is not usable without anoter language Srcipting plugin - jArchi or another), so your model will be preserved and my plugin will not duplicate your code.

The issue with what you propose is that the core of jArchi is its API (in fact the very first version of the script plugin has been created more than 4 years ago, but without a good API it was not usable, all changed when we switch to a jQuery-like API). So this has to stick with current way of distributing the plugin.

I just want to distribute my plugin without breaking your work and the model of distribution you have chosen.

Here's how I see it:

• As stated, IMHO your plugin should extend our official scripting plugin to leverage the jArchi API and avoid duplicating the API with all potential sync issues.
• This means that for your plugin to be used, users should first get and install jArchi
• For people you work with, colleagues, and friends, you can privately share a binary version of jArchi that you've compile yourself.
• For people you don't know, you suggest them to compile jArchi themself or get the binary version through small donation. Which IMHO is fair because of the work we've put in jArchi (without which your plugin could not exist)

If we agree on this, then your code could be hosted on archi-contribs (like Herve's DB & Specialization plugins) and you could make your plugin binary available through your repository's release page.

If you want to stick with a plugin which duplicates the API then I considered this a fork and you host it on your own GitHub account but not under archi-contribs.

Copying this comment on archimatetool/archi-scripting-plugin#64