[
https://issues.apache.org/jira/browse/QPID-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781442#comment-17781442
]
ASF GitHub Bot commented on QPID-8352:
--------------------------------------
gemmellr commented on PR #225:
URL: https://github.com/apache/qpid-broker-j/pull/225#issuecomment-1787514391
This still seems way over complicated to be starting with. In some ways
actually more than it was first time round now there are 2 different mechanisms
to use, and yet still the 192 options.
Other broker projects here at the ASF, some that have done this very
recently, ended up with 1 or 2 basic images being published, with configs that
roughly match the existing release bundles. Built from the existing release
bundle, using a basic script. For anything else configuration wise, users can
then configure the broker. They are trivial by comparison, and look far easier
to maintain later than this, and actually allow building from any release
version as well which this approach by contrast doesnt look to.
E.g I simply do not see a need for us to have, and need to maintain later,
_16_ new assembly variants inside this module to select protocols or store
types from. Which as before, the protocol options are actually not even clear
which protocols will be getting enabled and so will actually mislead, and you
cant even select any different options if you want a combo. Users that want to
configure protocols and store types can and should just configure that using
the far more flexible existing configuration mechanisms for that, or just make
their own images as they must have been doing for a decade already. All we need
to do is make it easy for people to supply their own desired configuration
(which its not clear this really does yet).
If they want to customise the deps they based on their protocols and stores,
can make their own images, as they have had to for a decade already.
We can pick a JVM, we dont need to support them all. 17 or 21 at this point
makes sense.
We dont need 4 OS options. Particularly when one is going EOL in a bit over
6 months. 1 would be fine, 2 at a stretch if you want to e.g do alpine.
> Official Docker image for Broker-J
> ----------------------------------
>
> Key: QPID-8352
> URL: https://issues.apache.org/jira/browse/QPID-8352
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Chris O'Brien
> Priority: Minor
>
> Currently there is no official Docker image for Broker-J.
> It would be great if one was provided, as there are more than a few people
> interested in running Broker-J in a container, shown by the handful of
> inflexible and un-maintained Dockerfiles/images for Broker-J floating around
> GitHub/Docker Hub.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
