Since a few weeks the Railway build always fails and the Docker image cannot be started.
Also it would make much mor sense to only deploy de pre-built docker image from Github.

As discussed in this Discord Thread it would be possible to simply add a separate Dockerfile for Railway that launches the pre-built image from Github.

Sample Dockerfile from Vaultvarden can be found here

When you click on the Header of the calendar to fast-forward to a specific year a modal with a combobox for selecting a year pops up in the center of the screen.

Ideally this should be possible directly in the header of the component instead.
Also it should be possible to fast-forward to a specific month/year combination - at the moment you can only fast-forward to a year that is within the past or upcoming 100 years.

The "simple" Logger Binding should be removed from the final release build since it can potentially break the project that references the Add-on because of "multiple implemenations" issue.

Using Vaadin 23.3.32 and 1.3.0 of the minicalendar, the css styling is not applied to the calendar. The minicalendar is added to a layout that is included in a module in the maven build.

    MiniCalendar appointmentDatePicker = new MiniCalendar();
    calendarLayout.add(appointmentDatePicker);
    appointmentDatePicker.setValue(activityItem.getAvailableStartDate());
    appointmentDatePicker.addValueChangeListener(event -> {
        updateTimeslotLayout(event.getValue());
    });

Currently the showcase will only deployed to railway whenever I trigger a new release.
This is not ideal since I'd need to trigger a release if for example railway just stops my app, just to initiate a new deployment.

There should be a workflow that can be triggered manually for a specific branch to publish the said branch to railway.

In the best case the release workflow will also trigger this new workflow instead of having the railway publish code duplicated.

The railway pipeline does not work as expected and needs to be adapted to work with the new custom Docker image.

With the latest chanes of the project the Release workflow config broke.
This must be fixed to have an automated deployment again.
Should be fixed with another Hotfix version.

It would be a nice addition to make the translation format for daynames configurable for the user.

As seen in the screenshot below the resource includes need to be updated to have a ./ prefix since the resources are packaged inside a .jar file.

The project should build a small runnable docker image that will ship a Jetty server and the showcase application.

Since the Vaadin 24 Upgrade the old Jetty Version will not be able to boot up the Showcase app.
Therefore, the Dockerfile must be updated to be deployable again.

Whenever there is a new version of the library the build pipeline should automaticalyl publish a new version of the showcase to a hosting provider (like Heroku)

Since the Vaadin Add-on is being built as a .zip file the fix for #13 did not really fix our problem at all because the entry in the zipped MANIFEST.MF was still false.

The project should have a Checkstyle configuration that is included in the build process to ensure a certain code style and minimum quality.

Currently the project contains some "showcase views" that can be viewed by starting the Maven Jetty plugin.

It would be nice to have a deployable (.war) and locally startable (.jar) showcase as a new Maven module in the project.
In the best case there's still some free hosting of .war archives possible, then I could add the showcase as URL in the Addon overview page in the Vaadin Directory

The Tomcat version that is currently used in the Showcase is no longer available and should be updated.

A new Vaadin version came out, the project should be updated to Version 23.3.5

Since the project layout has changed somehow the MANIFEST.MF for the addon also changed.
This needs to be adapted to match the old entry because the Vaadin Directory restricts the upload of the final component archive.

It would be nice to have the following options on the constructor:

1. Available date range (like the Vaadin DatePicker)
2. List of available days
3. List of List of days with List of styles :-)

In my case these are known at construction time and would save the 60 odd server roundtrips.

Thanks for the great component.

It seems that my switch to the multi-module project setup broke the actual project release because the resulting addon pom.xml is referencing a parent that is not published anywhere. In order to work around this we need to flatten the final build before we publish it to the Vaadin Directory.

See this Plugin