Issue with radicale server

[ecxod]

Issue with radicale server

[mikeberger]

I use third party software for all caldav communications: https://github.com/ical4j/ical4j-connector

Unfortunately, the software is very out of date and I have been waiting for a new release for a while: ical4j/ical4j-connector#56

I am not sure that Radicale has been supported for the past 5 years: ical4j/ical4j-connector#35

I see that the developer is still making commits towards a new release, but I have no timeframe and low expectations. At some point, without a new release of ical4j, all caldav code will just stop working as the caldav servers put out new releases.

As for Baikal, it still works for me. I have Baikal 0.9.4 working with php8.1. Do you have the php xml extension installed?

[ecxod]

I think we could work it around.
Borg is attaching the username in a automatic way like this (what is wrong):

https://dav.example.org/user%40example.org/12345678-1234-1234-1234-123456789012/[email protected]
                                                                                ^^^^^^^^^^^^^^^^

the URL should be only :

https://dav.example.org/user%40example.org/12345678-1234-1234-1234-123456789012/

here is how I fill the mask:

it is just the url-string that is different, this is why borg can not find the principal

As you can see in the error message

Syncing....Please wait
SYNC: connect to https://dav.zp1.net/c%40zp1.net
net.fortuna.ical4j.connector.ObjectStoreException: net.fortuna.ical4j.connector.FailedOperationException: Principals not found at [/user%40example.org/12345678-1234-1234-1234-123456789012/[email protected]]
Fertig

Lets try to fix it.

[mikeberger]

Unfortunately, Borg does NOT create the URL. BORG passes the paths in the options screen to the ical4j software and ical4j builds that path. ical4j does not build it correctly. The bug is not in my code.

To make things worse, ical4j even has a bug in the error that it prints. ical4j is not attaching the user to the principal path. ical4j is incorrectly printing the user path in the error instead of the path it actually builds. ical4j does not print the principal path for you to see.

throw new FailedOperationException(String.format("Principals not found at [%s]", userPath)); <-- userPath is the wrong variable printed in this error message

Finally, ical4j has separate URLs for principal path and user path. I don't know if caldav servers still use 2 paths. Most use 1 now.

You can change the value in "Principal Path" from "default" to other things. This will be added to the path that ical4j builds. You will not be able to see the actual path that ical4j builds because it prints the WRONG one. You may be able to get it to work by trial and error, but maybe not. I have been frustrated by this for years and no longer use caldav because of this.

[ecxod]

I tried to compile it with my gitlab

I used this pipeline with a maven image

image: maven:3.8.1-openjdk-17
stages:
- build
build_job:
  stage: build
  script:
  - cd BORGCalendar
  - mvn clean install
  artifacts:
    paths:
    - BORGCalendar/install/target/*.jar

And it compiles without errors, BUT the install-1.10.jar seems to not be functional

here is the log of the last pipeline

and here is the latest Job

you can download the artifact here :

I moved the artifact to install\target

C:\Users\Christian\workspace\borg_calendar\BORGCalendar\install\target>java -jar install-1.10.jar
kein Hauptmanifestattribut, in install-1.10.jar

so I took a look into it and there is a manifest

C:\Users\Christian\workspace\borg_calendar\BORGCalendar>jar tf install-1.10.jar
META-INF/
META-INF/MANIFEST.MF
licenses/
licenses/asf 2.0 - license-2.0.txt
licenses/the bsd license - bsd-license.html
licenses/mit license - mit-license.php.html
licenses/ical4j - license - license.txt
licenses/mpl 2.0 or epl 1.0 - license.html
licenses/cddl_gplv2+ce - license.txt.html
licenses/epl (eclipse public license), v1.0 or later - legal.html
licenses/gnu lgpl (gnu lesser general public license), v2.1 or later - lgpl.html
licenses/LICENSE.ical4j
licenses/eclipse public license 1.0 - epl-v10.html
licenses/cddl 1.1 - cddl+gpl-1.1.txt
licenses/apache license - license-2.0.txt.html
licenses/the apache software license, version 2.0 - license-2.0.txt
licenses/bsd 3-clause - license.txt
licenses/hsqldb license - hsqllicense.html
licenses/gnu lesser general public license - lgpl.txt
licenses/bsd - license.html
licenses/cddl+gpl license - cddl+gpl_1_1.html
licenses/cddl - cddl.txt.html
licenses/BORGCalendar-THIRD-PARTY.txt
licenses/gplv2+ce - cddl+gpl_1_1.html
licenses/common development and distribution license (cddl) v1.0 - cddlv1.0.html
licenses/cddl_gplv2+ce - cddl+gpl_1_1.html
licenses/apache license, v2.0 or later - licenses.html
licenses/bsd license - bsd-license.php.html
licenses/the mit license - license.txt
licenses/gnu general public license - version 2 - gpl-2.0.html
licenses/gpl2 w_ cpe - cddl+gpl-1.1.txt
licenses/LICENSE.jnlf
licenses/apache license, version 2.0 - license-2.0.txt
licenses/gnu lgp (gnu general public license), v2 or later - lgpl.html
run_borg.sh
META-INF/maven/
META-INF/maven/BORGCalendar/
META-INF/maven/BORGCalendar/install/
META-INF/maven/BORGCalendar/install/pom.xml
META-INF/maven/BORGCalendar/install/pom.properties

is this what it should be ?

[mikeberger]

install-1.10.jar is not used and serves no purpose. It is just an artifact created by maven, which insists on building a JAR file.

There are build instructions in the readme on the project page - but perhaps they are too vague.

After running maven, the contents of BORGCalendar\install\target\installer is the program.

To get a linux .deb package to install, you would build on linux and then manually run BORGCalendar\install\linpackage.sh
To get a windows executable, you must build on a windows machine and then manually run BORGCalendar\install\winpackage.bat. On windows, you also need a third party tool called WiX Toolset to actually build a .exe

The installers just copy the contents of BORGCalendar\install\target\installer somewhere standard and also include a JRE, an executable to start the program, and menu and desktop entries. the user does not have to install Java - the installer will include it.

I assume that someone editing the code and doing their own builds would do this on their own machine. If gitlab builds on some other machine, then I guess you can download the contents of BORGCalendar\install\target\installer and run BORG from the command line using java -jar borg.jar. I don't know anything about gitlab.

[ecxod]

Did you start this Program in 2000.07.17 ????? omg :))

I want to try to build this in a docker runner on my gitlab.

In winpackage.bat you request a file called borg.jar in :

  jpackage -t msi \
  --app-version 1.10.04 \
  -n BorgCalendar \
  --vendor MBCSoft \
  -i target\installer \
  --main-class net.sf.borg.control.Borg \
  --main-jar borg.jar \
  --win-dir-chooser \
  --win-menu \
  --win-menu-group Borg \
  --win-shortcut \
  --icon borg.ico

in your source code borg.jar it is not present and accordingly jpackage is failing
if borg.jar is created by running maven then this my be the key.

[mikeberger]

Maven builds the contents of the installer folder which contains the program, including borg.jar:

If you are changing the code, you would normally build and run Borg from inside an IDE, like eclipse or intelliJ.

I wrote a C++ version of Borg in 1992. It was pretty ugly. It used native X-windows graphics and ran on a PC running linux 0.96c, which was an adventure.
I wrote the Java version starting around 2000. It was pretty ugly back then as well. I wrote it to learn Java.

[ecxod]

After running maven, the contents of BORGCalendar\install\target\installer is the program.

So the pipeline must be

image: maven:3.8.1-openjdk-17
stages:
- build
build_job:
  stage: build
  script:
  - cd BORGCalendar
  - mvn clean package
  - mvn clean install
  artifacts:
    paths:
    - BORGCalendar/install/target/installer/*

Artifact is indeed 35 MB:job/6269

In the next step I must bring the "installer" folder from the docker container back to the repository and then start to build a windows container in witch I copy the part starting from "install/.." and run jpackage over the install folder.

[mikeberger]

jpackage will not be able to build the msi installer without WiX - https://wixtoolset.org/

I do not know how you will get WiX on your windows container.

Also, you do not need the mvn clean package line. mvn clean install does the entire build. Your script is building twice.

[ecxod]

I Think I could use the image dactiv/wix

docker pull dactiv/wix

docker run -v BORGCalendar\install:/project dactiv/wix jpackage -t msi \
    --app-version 1.10.04 -n BorgCalendar \
    --vendor MBCSoft -i /project/target/installer \
    --main-class net.sf.borg.control.Borg \
    --main-jar borg.jar \
    --win-dir-chooser \
    --win-menu \
    --win-menu-group Borg \
    --win-shortcut \
    --icon /project/borg.ico

something like this ... I am not sure yet ..

[mikeberger]

another issue was logged against the ical4j library not too long ago:

ical4j/ical4j-connector#59

If there ever is a fix, I'll incorporate it.