In cross-language-cpp/djinni-generator#43 python support is proposed and will likely come into master as an experimental feature in the next months.

As a user I'd like the intellij plugin to support interfaces that marked for implementation in python (+p)

The current sourcecode comes without a build tool and without any information how the "generated" code in there was generated.
I want to adopt the code to a modern IntelliJ plugin structure (based on this official template: https://github.com/JetBrains/intellij-platform-plugin-template) and configure a proper build process for it.

The code is currently licensed with Apache 2.0 and a Copyright to Dropbox.

The cross-language-cpp organization does not intend to just fork the original software from dropbox, but rather gain ownership of it as dropbox has stopped maintaining it.

Yet still all files have a Copyright notice that claims Dropbox as the owner.

The Apache License states:

In every licensed file, original copyright, patent, trademark, and attribution notices must be preserved (excluding notices that do not pertain to any part of the derivative works). In every licensed file changed, a notification must be added stating that changes have been made to that file.

As a project maintainer I want to clarify if this applies to the code that was derived from the original dropbox repository and is now maintained under the cross-langugage-cpp organization.

Personally I would prefer to re-license all files to the cross-language-cpp organization, if this is a legal option.

This question also applies to the djinni-generator & djinni-support-lib repos.

In the support-lib integration tests I spotted an interface that derives parcelable. This is not supported by the IntelliJ Plugin and marked as an error:

Any method prefixed with const gets an error at the first parentheses.

The Compatibility verification of the newly published plugin warns about

Compatible. 9 usages of deprecated API. 1 usage of internal API

As a maintainer I'd like to update the plugin to not use internal & deprecated API calls, to reduce the risk of incompatibility in the future.

As seen in #21 and #22 , the Plugin is currently configured to work with a "maximum" Version of IntelliJ.
As a maintainer I want to remove or change this restriction to be more generous (pluginUntilBuild=*?), because the current configuration will regularly break the plugin if we don't act fast enough, while API changes in new IntelliJ versions just may lead to a broken plugin.

Seems the flags datatype was forgotten...

• How to build and install the plugin?
• How does the release to the plugin-repository work?
• How is the code structured?
• How is all the code in src/gen generated?

Even though mixed case is allowed in enums and records, they are converted to upper case in the generated Java code, so it is not a good idea to use it.

(Maybe this should be fixed in Djinni proper instead).

as staten in #7 and the side effect of the current solution, a release requires some know how in how to write the change log, and what to do .
If this know how exits, the release is pretty much straight forward, but not very intuitive.

Let's investigate if this could be improved, base on an action that runs on tag release creation, instead of and action that creates an (draft release) tag

During approval process, I got this e-mail:

Hello,

Thank you for submitting your plugin.

Please provide a more detailed plugin description and usage instructions. You can update it in the plugin.xml file and upload it to the Marketplace again.

We are looking forward to approving your plugin.

The Readme contains 2 badges linking to the Jetbrains Marketplace. They are not yet set up correctly, attemts to locally set the required plugin-id have failed (the badge still shows "not found"):

Reasons why the badges may fail:

• because the plugin has not been approved yet and therefore is not publicly listed in the marketplace?
• because I set the wrong plugin-id?

The main branch of this repository is protected & merging into it requires at least 1 approval from another user. This seems to collide with the release process of the intellij plugin used as a template for this repo: On release it tries to modify the CHANGELOG.md file in main.

We need to figure out a way around this.

• Is it possible to give the github action special rights, so it can also manipulate main?
• ...?

Example on what goes wrong: https://github.com/cross-language-cpp/djinni-intellij-plugin/runs/1339227838?check_suite_focus=true

Some time ago the IntelliJ platform got a major update to 2020.3

The plugin refused to work on this new version because the until-build property was set to 202.*.

As a maintainer I'd like to get rid of this "upper version limit", as it will repeatedly make our plugin uncompatible with newer versions of IntelliJ, while it may still be working.