Moving Hallvard's git repo to PlantUML organisation and offering PlantUML as OSGi bundle on an Eclipse update site

[travkin79]

Hi @arnaudroques, @hallvard, and @The-Lum,

Following our preceding discussions (hallvard/plantuml#166, plantuml/plantuml#2127) I'd suggest to discuss the remaining tasks here.

From my point of view, we have the following goals.

• Make using PlantUML (EPL version) jar in Eclipse projects easier, i.e. offer each PlantUML version in an OSGi bundle on an eclipse update site for simplifying Eclipse plug-in dependency declarations and PlantUML version updates in Eclipse.
• Automate releasing such an OSGi bundle and update site as far as possible.
• Migrate Hallvard's Eclipse plug-ins for rendering PlantUML diagrams to plantuml/plantuml-eclipse.
• Automate / simplify releasing new versions of Hallvard's Eclipse plug-ins as far as possible.

In a first step, we copied Hallvard's Eclipse projects and git history to plantuml/plantuml-eclipse.

Next, @arnaudroques and @The-Lum will try to automatically trigger a GitHub workflow in this git repo as soon as a PlantUML release is created. Is it possible to also pass the version from gradle script to the GitHub workflow as parameter or environment variable?

I will adapt my PR for automatically releasing an OSGi bundle with the latest plantuml-epl.jar and updating the corresponding Eclipse update site. In addition, I will adapt Hallvard's Eclipse plug-ins to use the new OSGi bundle.

It seems, we can use https://plantuml.github.io/plantuml-eclipse/ (GitHub pages) for publishing release notes and the latest Eclipse update site.

[travkin79]

Hi @arnaudroques and @The-Lum,
I came far with automatically building an Eclipse update site with the latest PlantUML library version, but now I'm stuck with an issue in the GitHub workflow or gradle script. Could you take a look at it? Maybe I misunderstood something.

Details

• I'm working on the git branch automate-releases.
• I use build.gradle.kts in the git repository's root folder as the main build script (it also triggers Maven, but that doesn't matter here)
• I use the GitHub workflow .github/workflows/release-plantuml-lib.yml for preparing a new GitHub pages version with the latest PlantUML update site. For now, it is executed as soon as there is a push to the branch automate-releases.
• My problem is the following:
  • For some reason, the gradle script does behave different in the GitHub workflow compared to running it locally.
  • When running the gradle task updateGhPagesFiles from the GitHub workflow, the copy task does not only copy and modify some text files (by filtering), but also deletes all other files and directories in the target directory.

Before running the gradle task updateGhPagesFiles I have the following files and directories.

drwxr-xr-x  5 runner docker  4096 Mar 28 15:05 .
drwxr-xr-x  3 runner docker  4096 Mar 28 15:05 ..
drwxr-xr-x  7 runner docker  4096 Mar 28 15:05 .git
-rw-r--r--  1 runner docker    13 Mar 28 15:05 .gitignore
-rw-r--r--  1 runner docker 14279 Mar 28 15:05 README.md
-rw-r--r--  1 runner docker  1611 Mar 28 15:05 compositeArtifacts.xml
-rw-r--r--  1 runner docker  1611 Mar 28 15:05 compositeContent.xml
-rw-r--r--  1 runner docker   129 Mar 28 15:05 p2.index
drwxr-xr-x 15 runner docker  4096 Mar 28 15:05 plantuml.eclipse
drwxr-xr-x 14 runner docker  4096 Mar 28 15:05 plantuml.lib

After executing the task, which overwrites README.md, compositeArtifacts.xml, compositeContent.xml, and p2.index during copy (with filtering), I have only the following files left. See e.g. build run #35.

drwxr-xr-x 2 runner docker  4096 Mar 28 15:05 .
drwxr-xr-x 3 runner docker  4096 Mar 28 15:05 ..
-rw-r--r-- 1 runner docker 14584 Mar 28 15:05 README.md
-rw-r--r-- 1 runner docker  1710 Mar 28 15:05 compositeArtifacts.xml
-rw-r--r-- 1 runner docker  1710 Mar 28 15:05 compositeContent.xml
-rw-r--r-- 1 runner docker   129 Mar 28 15:05 p2.index

When running the same task on my machine, no files or directories are deleted.

Do you have any idea why this is happening and how to prevent it?

[travkin79]

It seems, I eventually found a solution to my issue. A Stackoverflow comment gave me the hint to declare gradle task inputs and outputs to avoid "stale" files, especially in the build folder, to be deleted before executing tasks that write to the build folder.

[travkin79]

Hi @arnaudroques and @The-Lum,
I think, I can now automatically determine the latest PlantUML release version, build an Eclipse update site with that PlantUML library version in an OSGi bundle, and publishing the update site to GitHub pages. All that is done by the GitHub workflow .github/workflows/release-plantuml-lib.yml.

Could you also make some progress with respect to triggering a GitHub workflow if a new PlantUML release is created?

(PlantUML pre-release versions and native image release versions should be ignored for the update site GH workflow triggering.)