Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plugins/extensibility/customizability #306

Open
kadhonn opened this issue Feb 8, 2024 · 4 comments
Open

plugins/extensibility/customizability #306

kadhonn opened this issue Feb 8, 2024 · 4 comments
Labels
enhancement New feature or request needsDiscussion Add this to tickets that have to be talked through with the core dev team

Comments

@kadhonn
Copy link
Member

kadhonn commented Feb 8, 2024

We need a way to make our applications extensible/customizable.

The most obvious example (but not the only one) is our html-publisher: we already do that by adding the "about us" page for example.
But the way we do it right now is a bit... weird and should probably be changed.

I currently can think of the following solutions for this problem:

  1. Put most of our code into libraries which can be reused.
  2. Make some sort of plugin system so you can use the existing app and just add your .jar file
  3. Have a dependency on the "finished" project to customize it. This is the current way but feels quite wrong.

Detailed explanations for those points:

This is straightforward. Put everything in its own module and publish that.
Our own html-publisher would just use t he library and wire everything together.
Other people could basically clone this bare publisher and add their own classes

People do not modify the publisher but can extend it by dropping in their own .jar file.
Has the positive effect that people can reuse our own published dockerfiles and just add the jar.
Has the downside of being more tricky to test/run locally

I do not recommend this one. We currently depend on the finished springboot app, which causes a lot of weird things.
You also need to redo the springboot-packaging yourself and the base project has to export all the springboot dependencies...

Currently I would favor 1) but I am open to suggestions

@kadhonn kadhonn added enhancement New feature or request needsDiscussion Add this to tickets that have to be talked through with the core dev team labels Feb 8, 2024
@kadhonn
Copy link
Member Author

kadhonn commented Feb 8, 2024

We should also think more about what kind of customizability we really need and want to support

@Yolgie
Copy link
Member

Yolgie commented Feb 13, 2024

yes, please let's define that and go from there

@kadhonn
Copy link
Member Author

kadhonn commented Mar 15, 2024

i had the idea, maybe we can make it customizeable by providing our own spring boot starter like in this article: https://www.codecentric.de/wissens-hub/blog/extending-spring-boot-five-steps-writing-spring-boot-starter

@kadhonn
Copy link
Member Author

kadhonn commented Mar 15, 2024

for what any why we want to make boudicca customizable:

To make it possible for others to host simple adaptations of Boudicca.

Two existing examples:

  1. https://boudicca.events Our own site is actually an extension of the base boudicca html publisher. We extend it with the About Us and Impressum sites.
  2. https://diabolical.boudicca
    events This not-quite-joke spinof changes a lot off css variables and adds a additional filter for events.

So currently we have 3 properties we want to extend/customize

  1. Header links + actual sites
  2. CSS
  3. Additional filter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needsDiscussion Add this to tickets that have to be talked through with the core dev team
Projects
None yet
Development

No branches or pull requests

2 participants