ppalaga commented on issue #616: Utility to generate/scaffold an extension for a camel component URL: https://github.com/apache/camel-quarkus/issues/616#issuecomment-599395886 I have the tool in a state where it is generating what I think is the right code. Now let's discuss the tree structure. ## JVM-only Extensions As I said I'd prefer to have the JVM-only extensions in a separate directory. Current: ``` . ├── ... ├── extensions ├── extensions-core ├── extensions-support └── ... ``` Proposed: ``` . ├── ... ├── extensions ├── extensions-core ├── extensions-support ├── extensions-JVM └── ... ``` ## Itests of JVM-only Extensions I am not 100% sure what would be the best solution. I prefer having the itest as close as possible in the source tree to the corresponding extension to eliminate as much scrolling and clicking in the IDE. The most straightforward way to reach it would be ``` ├── ... ├── extensions-jvm │ ├── extension-1 │ │ ├── deployment │ │ ├── runtime │ │ └── integration-test │ ├── extension-2 │ │ ├── deployment │ │ ├── runtime │ │ └── integration-test │ ├── ... └── ... ``` Pros/cons: * Easy to move the whole extension to the appropriate directory when promoting from the JVM-only state to the full support. * Wild idea: We should have isolated per extension tests for all new and existing extensions. The grouping of itests, that we currently do to reduce the CI times should be done by a tool that would merge several isolated itests into one. The isolated itests should be run by the CI regularly at least in the JVM mode to make sure that the dependencies are correct. The isolated itests should be run in the native mode on demand, e.g. before the release. WDYT?
---------------------------------------------------------------- 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 With regards, Apache Git Services
