Full Uuidv7 support added

[JanDiederich]

Update: I added a new feature, the "UUID examiner Popup", but I want to test it as a daily driver, to make sure no bugs are left.

If you use UUIDs as database IDs, the use of UUID Version 7 is recommended. uuidv7.org praises it this way:

The Key Benefits of UUIDv7

UUIDv7 is rapidly gaining traction for various use cases across many industries. Here are some of the primary benefits:

1. Time-Ordered and Sortable: UUIDv7 encodes the time of creation as part of the identifier, making it naturally sortable. This is especially valuable for systems where data needs to be ordered by time without needing an additional timestamp field.
2. Globally Unique: UUIDs are designed to be unique across all systems without the need for a central authority. UUIDv7 maintains this property while also encoding a time element, making it ideal for systems with multiple nodes, distributed architectures, or decentralized applications.
3. Efficient Storage and Indexing: Since UUIDv7 is time-based, its encoding structure ensures that identifiers are predictable. This can be particularly useful for indexing in databases, where sorting or querying by time is common.
4. Improved Compatibility with Modern Systems: UUIDv7 is designed with modern technologies in mind, offering improved support for cloud-native applications, distributed databases, and microservices, making it a future-proof choice for scalable systems.
5. Compatibility with Existing UUID Libraries: UUIDv7 can be used seamlessly with existing libraries and systems that support UUIDs. This makes it easy to adopt UUIDv7 in your applications without significant refactoring or integration challenges.

Therefore our Chief-Architect adopted them and this UUID plugin suddenly turned useless for me. But because it was such a nice plugin, I just added UUIDv7 support. With a tooltip for the timestamp part of UUIDv7's.

I also updated all plugins to current versions, which was cumbersome, because there were many breaking changes in the build-setup. This is also the reason I add this PR only as a draft. Because I wanted to make sure the plugin manifest is still to the plugin owners liking. I never published a plugin before, and I'm unsure.

I know you didn't want to invest much time in this plugin anymore, but I think I did basically all the work, there isn't much more left for you. Please, at least try it out, maybe it will convince you.

---

P.S.: The completely new feature, the "UUID examiner Popup" is for the following use-case:
Currently I have to communicate with a lot of people, who all need to send me their data w/ UUIDv7s, to my surprise that's quite a challenge. It seems many people don't want to use proven libraries, but rather write their own, or create the IDs per hand. As a result I have weird looking UUIDs (the random part is fixed) or just wrong UUIDs (version 5). Also often I want to know when something was written, which is stored in a UUIDv7.

So I needed a way to examine whole batches of UUIDs. That is where the UUID examiner comes in handy.
Just copy+paste 100 lines with 5 UUIDs per line from your SQL-Query in that thing, and you get all 500 UUIDs "decrypted":

• Did someone insert everywhere their UUIDv5s?
• Do we have components remaining writing UUIDv4?
• From when are all these 500 UUIDs? Are there odd ones? Is there a bug?

---

Please report any problems.
Thanks.

[leomillon]

Hello!

Thank a lot for this awesome work. I'll try to have a look at it as soon as possible 👍

[leomillon]

Hi again!

I tried to look at almost every line you added in this PR (which does not seem to be "finished" with your last commits) and here is my feeling: there is a bit too much things in this PR and not in the proper order.

I'll try to develop this feeling:

Upgrade the existing base first

First, to add new features to this project, I would first upgrade everything required for compatibility with the latest versions of the plugin platform, Kotlin, libraries, release tasks, etc.

This way, you ensure to have an up to date plugin (which is quite important against the IntelliJ Platform with some breaking changes sometime) without breaking the core features.

Add the UUID v7 support

Then and only then, I would add v7 support, but with slightly different choices:

• I would not have chosen number inputs for all parts of the fixed date. Instead, a simple text input with some parsing / validation should do the trick.
• Having a radio button between v4 and v7 feels weird because you're not choosing "which one you want to use", you're choosing which one to configure. Perhaps tabs would be more appropriate?

Other features

You also added other features such as "Copy to clipboard" and the "Examiner popup" (which I think may not belong in this plugin).
That's too much to review / comment in a single PR.

Conclusion

Although I really like the idea of adding the v7 support to this plugin, I would prefer that the plugin is first upgraded "as is", followed by separate PRs for each new feature, etc.

If this version is ok for you and your needs, feel free to use your fork directly.

[JanDiederich]

I tried to look at almost every line you added in this PR

Nice. Thanks.

(which does not seem to be "finished" with your last commits)

Sorry, but I constantly get new ideas on how to improve that thing. Therefore I added the "Update: I added..." line at the top of my PR. And, as said, "I want to test it as a daily driver, to make sure no bugs are left.". I still didn't delete my PR, because the biggest share of my old source-code hasn't been touched, and I thought it would be great to get feedback on that. Nevertheless, I'm looking forward to not needing to change anything anymore, if no bugs are found.

Upgrading the base first...
I don't want to revert this or create a Git mess. What I could do, is creating another PR where I try to have only the plugin API changes included, which is hard, because it's connected everywhere (even simple Unit-Tests didn't work anymore with the latest versions). So, just as one example, I have my unit-test changes for the UUIDv7 part and the changes for the new API in the same files. But I can try that if you really insist.

I would not have chosen number inputs for all parts of the fixed date. Instead, a simple text input with some parsing / validation should do the trick.

Understandable, I did that in past projects, but that turned out to be cumbersome, either with the number input, or perfecting the date parser to be less rigid and smarter. What I may recommend instead is adding the LGoodDatePicker. I just wanted to avoid adding that dependency, if I can implement this easily myself (although in a much less beautiful version).

Having a radio button between v4 and v7 feels weird because you're not choosing "which one you want to use", you're choosing which one to configure...

I already thought about that, but I had no really convincing idea on how to improve that. And I was afraid to earn a rejection, by changing too much of the existing design. Given the Swing editor is so powerful, feel free to redesign this and post screenshots w/ descriptions of your design. I will then write an implementation.

The other features...
Well, for my taste they go hand-in-hand. Especially the examiner, I'm thrilled to use it at work this week (today was a holiday). That really ties everything together for me. 😄

[JanDiederich]

Full disclosure: I found out that the Apache CSV library is super sensitive when it comes to malformed CSV data. That isn't acceptable for an input field (in the UUID examiner) where you can freely input anything. It exits with an exception. I replaced it with a more robust library and expanded the Unit-Test for that with malformed data.

I will continue using this plugin as a daily driver, to make sure there are no further bugs left.

[JanDiederich]

The UUID examiner is super helpful and I'm very satisfied with its results.
But I still missed a live preview in inlays and in the debugger variable overview, so I added that too.

I will evaluate this further.

[JanDiederich]

I added the Date and Time picker you requested.

[JanDiederich]

I cleaned up the inlays and debugger info.

@leomillon I still need screenshots of the GUI design you requested. Please post them so I can implement your design idea.

Edit: My plan is to 1st "complete" this plugin and then extract the basic changes to the new IntelliJ plugin systems, you requested.

[JanDiederich]

@leomillon Hi. Did you know you can release versions of your plugins as EAP / Dev versions?
So, I suggest you do that, if you are unsure how users will receive these extensions.

Edit: I'm myself super happy with my design extensions, totally love them. They don't get in my way, they just help. It just works.

[JanDiederich]

I added a better merging of UUID and default String rendering to the debugger. It is now also possible to completely disable the custom UUID debugger via settings.

@leomillon You have no donate option on this repository, and since I know how demotivating it can be to work for 0 €, I would donate 10 € if you added a donate button.

[JanDiederich]

@leomillon Hi, I updated the readme.md screenshots for the generator and settings dialogues to show the improved date & time selection. I forgot that.

I still want this PR to pass. But I still need your mockups for the new UI design.