lburgazzoli edited a comment on issue #1128:
URL: https://github.com/apache/camel-quarkus/issues/1128#issuecomment-621931531
> 1. According to your proposal, our non-core extensions will depend on
`camel-quarkus-core` (rather than `camel-quarkus-main`), right?
correct
> 2. Our existing itests should in theory either (a) work with the proposed
changes as long as they do not use `camel.*` properties or (b) work with the
proposed changes if the `camel-quarkus-main` dependency is added.
correct
> 3. Which of the three options ("core only", "main", "main-static") is the
one that will meet the needs of 80% of users?
this is very hard to answer as there's many way to use camel, using main to
create a standalone camel application is certainly one option but you can also
use some little camel from
[smallrye-reactive-messaging](https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/camel/camel.html)
or [mutiny](https://issues.apache.org/jira/browse/CAMEL-14381) or when you
need some small integration capabilities in your application.
I think that nowadays it is likely common to require some integration
capabilities so I believe having a core that helps setting up things but give
you freedom to i.e. provide your own main is the most sensible choice we can
make.
> 4. Can we make core-deployment smart enough to decide whether main or
main-static is needed and add one of those as necessary?
I think there have been some discussion on quarkus side to have a way to add
additional artefacts depending on some conditions but I'd rather start with
something simple and less magic and see how it goes.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
