I want to build a integration route in camel-k. But for better debugging (f.e. adding break-points) i have build the integration-route with camel in a maven project. This project now contains multiple classes as dependencies (logic and separate processors) in multiple files. The route works fine, now i want to deploy it in kubernetes with camel-k. Is there a convenient way for packing all needed classes when building the route with kamel cli? This way both uses (camel and camel k.) would be possible within the same project. In other discussions one solution that have been pointed out was to pack the classes as jar's and add them as maven dependencies in modline, but with that approach every time a change would be made everything had to be repacked. I also tried to load all classes with the kamel run command, but the integration could not connect the classes that way.
You could use this answer https://stackoverflow.com/a/69844968/6528166 which removes Maven as requirement. You can provide the jar directly.
Related
We are using the Jenkins Job-DSL plugin for creating a number of jobs and having the actual job-configuration as part of the version-controlled source-code.
In order to test the resulting XML files locally, I currently use something like the following:
java -jar /opt/job-dsl-plugin/job-dsl-core/build/libs/job-dsl-core-1.78-SNAPSHOT-standalone.jar create_jobs.groovy
This allows to look at the resulting XML while making changes.
However some DSL elements are failing in the local build, but still work on the actual Jenkins installation.
E.g. "batchFile", "pullRequestBuildTrigger" and a few others.
As far as I understand these are separate Jenkins plugins which contribute some additional elements to the DSL, so the core job-dsl-plugin does not know about them.
I tried various ways of adding the code from these plugins to the job-dsl-plugin so that I can run the local transformation, but I could not find a way that actually works. Adding the plugins to job-dsl-plugin, classpath, ... nohting fixed it.
I also looked at How to import and run 3rd party Jenkins Plugin's extension DSL (githubPullRequest) with Gradle tool locally?, but the suggestions there did not work for me as I do not want to run a local Jenkins instance here.
So how can I run the job-dsl-plugin manually with DSL from additional plugins being available?
I'm not sure if this is the best place to post such a question, but here it is. I'm a test automation engineer that works primarily with backend, spring boot command line apps. My tests, at a high level, are designed to ensure that any type of data that is thrown at the app will be handled correctly. We are a Java shop.
As with any "good" testing practice, I am treating the app like a blackbox, in that I do not pull in the model objects to run my tests. I simply supply the app with data, execute a command line type script (run.sh) that takes my data and processes it. My tests are comprised mostly of JDBC (to interact with the database) and a slew of ArrayList utilities that I have put together to sort out result sets and get specific db information.
Thus far, I have been deploying my tests as a JAR. I bundle everything up and deploy it to the environment with a script that will execute the tests. The tests do not run when the app is run. Though they do live inside of the project, they are a separate entity with separate launcher classes. However, I am finding that managing dependencies in a JAR is a real headache. Is there a better way to deploy automation / integration tests for command line apps?
I'm pulling in maven shade plugin to bundle all of my dependencies into a "God JAR", but that isn't helping me to resolve the issues that occur when I attempt to execute the JAR. I get multiple bean instantiation errors, relating to the app itself, and not my tests. For this reason, I pull in the app model, and the app itself as dependencies. When I ran the tests in my initial testing, they worked just fine. Deployed to environment and they continued to work correctly. Fast forward a couple of months, a few changes made to the app, and now it's a dependency nightmare when I build the new JAR.
TLDR: I'm having trouble managing dependencies in a maven project, integration tests JAR. Is there a better way to deploy automation / integration tests for command line apps where dependency management is easier?
(Note: I'm relatively new to this world, so pardon me if the question seems a bit vague).
I think the error happens when you use the shade plugin to re-package the spring boot jar. The way spring boot works is to add dependencies into the jar as jars itself and configure its own class loader (in the meta config) that is capable of reading classes from jar files inside the jar file. The standard java class loader does not do this - thats probably why the shade plugin misses out some jars (probably the ones embedded in the spring boot uber jar).
what I would try is to create a test-version of the spring boot app that contains the test-classes in the compile scope and a dependency to the original spring boot jar (you don't need the uber jar - therefore you may have to add a classifier to the original (app) spring boot plugin config to have that jar still available as it is replaced by default) and use the spring boot plugin to package the test version of it (using the dependency and its classifier above you used for the original app).
Never found a really satisfactory solution to this. How do you do it? I am looking for inspiration for new approaches.
For context, assume I write a generator that takes a project resource and generates a code file. But it could be any other project support tool - validator, converter, deployer etc. Often manually triggered actions that are not running as part of normal build.
Such tools typically require a few dependencies that are not required by the project itself at runtime.
Strategies that I have applied or considered in the past:
add tool dependency to project anyway, and either mark it "provided" or filter it out during the packaging process (this is what I usually do, but now I am in danger of adding normal project code that uses the tool dependency, potentially resulting in an error that only manifests during runtime)
use a script (trying hard to avoid scripts and their hidden dependencies and complexities)
create separate support projects (trying hard to avoid project explosion, especially for seemingly small tasks that are handled by a few lines of code)
subprojects / modules (only vaguely aware of this option, never really tried it)
maven plugin that is run with a profile with separate dependencies (trying to avoid the separate project required to maintain the custom plugin)
Inspiration from answers and comments
separate tools project shared by multiple projects
I just realized that maven and eclipse already solved exactly this problem for a very specific "tool": test code.
Test code often needs additional dependencies not used by the application itself.
People obviously invested quite a bit to keep the "test / tool" infrastructure within the same project, as opposed to creating a separate test-project:
separate source locations (src/main/java, src/test/java)
separate resource locations (src/main/resources, src/test/resources)
a full-blown separate maven dependency scope "test", complete with transitive resolution
separate compilation phases (compile / test) with separate dependency trees
eclipse supports special junit launch configurations that are able to correctly resolve the test dependencies
probably more stuff that I am not aware of currently
So, I am strongly considering to program all my supporting tools as "junit test cases".
I am planning to create and commit shared junit launch configs for the team that execute just one specific "test case", which will run the tool logic instead of testing.
The problem I have to solve is to avoid running these dummy tests during the normal maven test phase.
Also, writing this, I realize that there is even another such system already in place: the maven plugin infrastructure, that also has a separate dependency resolution mechanism. Although, so far it seems necessary or normal to create separate projects to create plugins. I will look into ways of writing and building project specific maven plugins without needing to create separate projects. I am thinking about generating the pom.xml needed for plugin compilation on the fly, and including all the test dependencies.
I am in need of separate jar of some classes existing in a multi-module project. I need to pull those classes out of existing module so that I can create a jar for them which I can then export to some other project. What I am thinking is what's the advantage of creating separate module in existing project or altogether creating a separate project?
I can't think of possible trade-off. Can you tell me the trade offs involved.
I would suggest you to create an another module instead of a separate project.
Justification:
1) You can pack this jar and use wherever you want it.
2) You can add this module as a dependency to the other modules
3) We will be following the the Maven general rule "one primary artifact per POM"
Conceptually, you should only create a new project if the set of classes you're moving are coherently useful. If this new project you're going to create can be used to solve a problem (with a good API), I think it's a good enough reason to create a new project.
Otherwise, it's perfectly fine for a maven artifact to be shared among other projects even it is just a module of a multi-module project.
Just my $0.02
module:
- easy to manage dependencies
- easy to support shared components. For example two modules use the same
database.
- build/ci process may take longer
project:
- you can easily deploy projects separately with their own versions and so on
- more convinient in case a dedicated team works on a seprated project
- easy to manage build system
- more complicated to handle dependencies
I develop a little java utility library using maven. Now I'd like to add some demo / sample code to show how to use the library.
Where is the best place to put it?
In a sub-package with the other code. I don't like this since it means the demos will be included in the library jar file.
In a new maven artifact. That works, but I'd prever to have the demos closer connected to the library source.
As a sub-artifact. Haven't tried this yet. Seems to make everything a bit complex for something that should be simple.
Is there any common pattern to do this?
If it's some sample code snippets that run by themselves and just demonstrate how to use the library, then write them as unit tests, in the same module.
If it's more like a separate demo application (that a user might even interact with), then create a separate artifact. It's the standard way of doing it. If you really want to you could put it in the same module, but in a different source directory, but that's just making it harder on yourself.
Your library and you demo should probably share a parent module (of type "pom", not "jar" like the others), giving you a multi-module project. Then you can build both by launching maven from this parent module.
If you want to release your library and demo together (you can, but you don't have to), you can do that from the parent too.
In other words, it's not because they are separate modules, packaged in different artifacts, that they cannot be closely connected anymore. The different modules of a multi-module project still form one whole project.
You hadn't written what kind of utility library it is, but if it's something like apache commons, then most of the demos can be written as JUnit tests, which are placed in the same artifact. Good designed JUnit tests both tests your code and provide example how to use your utilities.
I prefer a new maven artifact, it can make your own artifact clean
I would recommend create a maven multi-module project where one module is the core and one module is the demo code. That way the user can choose if he wants to create both modules (they become separate artifacts) or if he just wants the core.