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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
