You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "zbendhiba (via GitHub)" <gi...@apache.org> on 2023/07/25 14:20:52 UTC

[GitHub] [camel-quarkus] zbendhiba commented on pull request #5117: Onboard Camel K Runtime

zbendhiba commented on PR #5117:
URL: https://github.com/apache/camel-quarkus/pull/5117#issuecomment-1649939306

   > For naming, I'm not sure I like prefixing stuff with `k`. I'd prefer we use `camel-k`, then there's no ambiguity. Do we want to name artifacts like `camel-quarkus-k-core-api` or just simplify to `camel-k-core-api`? What do others think?
   > 
   
   I have a preference for `camel-quarkus-k-core-api`, unless there's a technical reason from Camel-k project.
   
   > Then there's the question of how we strucure things. We could either continue with what's proposed here with something like:
   > 
   > ```
   > |- extensions-jvm
   > |----- camel-k
   > |--------- core
   > |--------- runtime
   > |--------- foo
   > |--------- bar
   > ```
   > 
   > Or have dedicated top level modules for the camel-k specific stuff. E.g:
   > 
   > ```
   > | - extensions-jvm-camel-k
   > |----- core
   > |----- runtime
   > ```
   
   This could be a first way of dealing with this.
   
   > 
   > For any native supported bits:
   > 
   > ```
   > | - extensions-camel-k
   > |----- extension-a
   > |----- extension-b
   > ```
   > 
   > And a similar split for the integration tests `integration-tests-jvm-camel-k` & `integration-tests-camel-k`.
   > 
   > I am generally terrible at naming / deciding these things, so it'd be good for others to comment.
   
   


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org