Join https://github.com/plantuml-stdlib and/or migrate there?

[Potherca]

Several of us have been making an effort to bring together the projects and people who feed sprites into the official plantuml-stdlib.

We've been doing this under https://github.com/plantuml-stdlib/, with the go-ahead of Arnaud Roques (creator of PlantUML)

This ticket is to ask whether you would be interested in joining that effort and/or migrating this project to the PlantUML-StdLib organization.

The main reason for asking is to see if, by joining forces, we can make sure that any sprites already added to the official plantuml-stdlib remain maintained.

So, what do you think?

[gadams999]

Hi @Potherca,

We would definitely be interested in joining the effort, especially if there is a way to incorporate the icons directly into the plantuml-stdlib. Is there any documentation on the build process or how to link the output from our releases to yours? Today we curate the icons from the source files and this requires minor to significant changes per official release, so timing (such as with the latest) may be delayed.

[Potherca]

There isn't really any documentation yet, but I've got a timeslot set aside for plantuml stdlib this weekend, so I hope to remedie that situation in the coming two days.

The long-term view is indeed to see if we can get a more direct integration with plantuml and to have more standard and automated ways for keeping things up-to-date. Once we've got more maintainers and projects onboard, we should also be able to (after reaching any form of low-level consensus) be able to present the main PlantUML repo with out proposal.

As long as we don't create more work or issues for @arnaudroques I think we've got a good change of making live easier for all involved libraries.

[gadams999]

Getting back to you after our recent major release. I reviewed the plantuml-stdlib and saw the repo where the build steps take place via cloning the various repos. At present we have the resources to keep the AWS Icons distributions aligned to the quarterly release dates. For now, would it be okay to continue to git clone our repo and incorporate into stdlib that way?

We can confirm that the dist/ directory and icon structure won't change. What does change between each release are various icon names and paths. For instance, in the most recent release, certain AWS services and resources moved from one major category to another. Is there a way the stdlib can address these changes between releases of plantuml that won't break user's diagrams?

Maybe one approach would be to remove any paths or categories for the stdlib. Since each PUML filename needs to be unique for our all.puml approach, that could provide longer term stability of icon and file names. We could incorporate an additional step in our publishing process (manual today) that would create a flat directory structure and pin icon names.

Would you like to continue the discussion here or move it to one of the repo's in the plantuml-stdlib org?

[arnaudroques]

Getting back to you after our recent major release. I reviewed the plantuml-stdlib and saw the repo where the build steps take place via cloning the various repos. At present we have the resources to keep the AWS Icons distributions aligned to the quarterly release dates. For now, would it be okay to continue to git clone our repo and incorporate into stdlib that way?

On my side, for now this is ok to continue to git clone your repo and to incorporate it into stdlib that way (that is, also manually).

We can confirm that the dist/ directory and icon structure won't change. What does change between each release are various icon names and paths. For instance, in the most recent release, certain AWS services and resources moved from one major category to another. Is there a way the stdlib can address these changes between releases of plantuml that won't break user's diagrams?

Currently, there is no way of solving this issue. Maybe in some future we could include two different releases of the stdlib in a single release of PlantUML, so we could have either:

• !include{v7.0} <awslib/AWSCommon>: this would include v7.0 files
• !include{v10.0} <awslib/AWSCommon>: this would include v10.0 files
• !include <awslib/AWSCommon>: this would latest release (that is v10.0 in this example).

Since the whole stdlib is compressed and packaged into plantuml.jar file, we cannot put all releases because we try to limit this file size. So your next suggestion really makes sense:

Maybe one approach would be to remove any paths or categories for the stdlib. Since each PUML filename needs to be unique for our all.puml approach, that could provide longer term stability of icon and file names. We could incorporate an additional step in our publishing process (manual today) that would create a flat directory structure and pin icon names.

That's sounds like a good idea. Maybe you could create a new branch to test this suggestion, so that we see how it would look like and what users would think about it.

Would you like to continue the discussion here or move it to one of the repo's in the plantuml-stdlib org?

Let's keep it simple right now ant let's continue the discussion here.

Thanks!

[gadams999]

Maybe one approach would be to remove any paths or categories for the stdlib. Since each PUML filename needs to be unique for our all.puml approach, that could provide longer term stability of icon and file names. We could incorporate an additional step in our publishing process (manual today) that would create a flat directory structure and pin icon names.

That's sounds like a good idea. Maybe you could create a new branch to test this suggestion, so that we see how it would look like and what users would think about it.

We'll give it a go. I'm thinking of a separate directory such as dist/plantuml-stdlib-source or something similar that will contain all the icon pumls. Then the build from your side could reference that directory and the AWSCommon ones.

We would guarantee that all icons for a specific version will be present. Naming would be flat, so the chances of a move/add/delete/rename should be minimal and probably only for newer AWS services. If someone really needs a specific icon or ensure it will be available, they could one-off reference to our repo and release.

[gadams999]

Closing stale issues.

With limited resources on our side, we'll leave as-is. Please feel free to reuse the assets created here on each release.