Using Maven 1.x with just the bundled/standard plugins, what configuration is necessary to build an executable Jar?
Answers should cover:
including dependencies in target Jar
proper classpath configuration to make dependency Jars accessible
Well the easiest way is to simply set the maven.jar.mainclass property to the main class you'd like to use.
As far as setting up the manifest classpath you can use maven.jar.manifest.classpath.add=true to have maven automatically update the classpath based on the dependencies described in the project.xml.
Disclaimer: It's been a long time since I've used Maven 1 and I did not test any of this out, but I'm pretty sure this will get you started in the right direction. For more information check out the jar plugin docs.
Related
I'm new to Bazel and Armeria. In the Armeria dev guide, in setting up with a build system, it has examples from Gradle and Maven, but not Bazel. Downloading the jar file (armeria-1.18.0.jar) and importing it directly using java_import() will build the project, but gives and error during runtime. It cannot find the runtime dependencies of Armeria like micrometer, etc.
This seems more like a question about bazel rather than armeria.
Have you tried using maven_install? I guess this takes care of pulling in transitive dependencies.
Sample: https://github.com/bazelbuild/examples/tree/main/java-maven
Documentation: https://github.com/bazelbuild/rules_jvm_external
https://github.com/dremio/dremio-oss/blob/master/pom.xml
After I clone the project,I try to build the project, but some dependencies are not found .How to find these dependencies,such as
the project accquire calicte:4.0.0-20210722102535-bda216e83f-dremio,which can not find in mavencenter
Any help?
I tried building dremio-oss on Windows the other day and there were no problems with resolving dependencies. You should include more information from the build log. You can also try using the "-U" option to force checking remote repositories which is useful if your local repository cache is out of date. Your error message also doesn't make sense since the correct version for Calcite is this one: https://github.com/dremio/dremio-oss/blob/master/pom.xml#L46
What is the difference of having the packages under the dependencies or devDependencies in the package.json?
How does that impact in the final build?
Sounds quite simple, but I don't have it clear to which packages to put in each section. Even similar addon's documentations vary as well, some say to use --save and others --save-dev, which confuses me.
In an ember app all your dependencies will go under devDependencies since you build the app via the ember cli and you do not include the app in another project.
For addons the story is a bit different, if your addon exposes any functionality from a package then that package has to be under dependencies.
Take a look in your package.json file and you will see two types of dependencies. One is called devDependencies(usually modules needed for local development) and one is called dependencies (dependencies used in production or that are integral to the given project). The --save flag adds your dependencies to the dependencies object of your package.json file and --save-dev adds your dependencies to the devDependencies. They're separated for convenience.
Edit:
This question has been answered before, but the tldr; is, it doesn't affect your production build. Hope that this helps.
Checkout dependencies can be used to add another work-in-progress project to your Leiningen project during development (for example: you're developing an app and underlying library in parallel).
However, when a checkout dependency itself has a "traditional" dependency (from Clojars), running lein run in the parent project will throw a java.io.FileNotFoundException since it apparently does not retrieve the "traditional" dependencies of its checkout dependencies.
Is there a way to let a Leiningen project recursively download the dependencies of its checkout dependencies?
My opinion of the "proper" way to do this is to have your project depend on the library in your checkouts directory as a traditional dependency in addition to having it in your checkouts directory.
Then every time you change dependencies, run lein install in your library project. This will cause lein to generate the appropriate jar file and install it into your local maven repo. It does not matter if this library project is finished, because you are not actually running it in this state, just using it to fetch dependencies.
Then when it does work you don't have to do anything to "switch to production" other than remove your checkouts directory. The dependency is already in place in the dependent project.
There is a side effect of using checkouts to work on libraries in that the code is loaded twice. Once from the "depended on" version, and then again from the "checkouts version". This is very occationally a problem for me when I'm using protocols and have to remember to re-load the protocol definition.
My current project is split up in multiple sub-projects using lein-sub. The core sub-project depends on other sub-projects. Right now, I'm typically working through the repl and simply re-compiling the current namespace to get an updated result; However, whenever I update a sub-project, and try to re-compile that namespace, I don't get the updated results for those projects. I've tried to delete everything in target/ and re-installing the dependencies, but nothing is working.
How would I be able to reload sub-projects in the quickest way possible?
lein-sub doesn't put your subprojects on the classpath; if they're available at all, I expect that's due to a lein sub install issued at some point?
For the type of simultaneous interactive development you're asking about you can use Leiningen's built-in checkouts feature. Just create a directory called checkouts in the root of your top-level project and in there create symbolic links to the root directories of the dependencies. You still need to add them as :dependencies to project.clj, but the fresh code from the checkouts will be used. You can then run your REPL in the top-level project while simultaneously working on all of them, reloading the individual namespaces from the dependencies just like you would with those from the top-level project.
See the tutorial (link to the version on master) for a detailed description.