I am evaluating gradle for our project. We have multiple small project that contain small util libraries. Most projects are in an extra repository and cannot use a shared buildscript.
When working across multiple project the same feature branch is used. I already managed to get gradle to put the branchname into the created maven artifact as classifier.
For our continous integration it would be really helpful to resolve a dependency to such a library to the one using its own branch name if it exists. If it doesn't it should fallback to the normal declared version.
I managed to change the versions via resolutionStrategy.eachDependency but I couldn't find a way to implement the fallback if no version for this branch exists.
Is there any way this can be achived?
Regards,
arne
You'll have to write some code to achieve this. For example, you could copy the configuration, set classifiers for the copied configuration via resolutionStrategy.eachDependency, resolve the copied configuration via configuration.resolvedConfiguration.lenientConfiguration, check which dependencies could be resolved, and then choose classifiers for the original configuration accordingly (again via resolutionStrategy.eachDependency). The best place to do all of this is in configuration.incoming.beforeResolve.
Related
I want to publish a common build script which i will include across various projects in my application.
This will contain only the common set of dependencies, i.e dependencies with particular versions that will be common across all the artifacts in my enterprise application..
My applications will refer to this file from the url.
How can i achieve this?
EDIT1: my exploration in this direction is based on this answer on SO:
How to share a common build.gradle via a repository?
There are a few different options for this.
One is to publish a project with the dependencies you want to share defined as API dependencies. Projects that depend on this will inherit the dependencies.
Or you could write and publish a Gradle plugin that will configure your projects with the common dependencies. Projects can apply the plugin, and will automatically be configured in a certain way. (You don't need to publish a plugin to do this - first try creating a project-local buildSrc convention plugin.)
I would actually recommend neither of these approaches.
It's easy to get into a tangled web of dependency hell when transitive dependencies are inherited. It's likely that at some point some dependency will clash, and excluding dependencies can be a big headache, and will easily cancel out any benefit in trying to reduce a little duplication.
Additionally, it's nice when a project is explicit about its dependencies. Being able to look at a build.gradle.kts and understand exactly what dependencies are set is very convenient.
Instead, what I would recommend is controlling the versions of common dependencies in a central location. This can be achieved with the Java Platform plugin. This plugin can be applied to a single build.gradle.kts file, and it lists all versions of all possible dependencies. (It can also import existing Maven BOMs, like the Spring Boot BOM).
Now, all subprojects can add a platform dependency on the 'Java Platform' project.
dependencies {
// import the platform from a Maven repo
implementation(platform("my.company:my-shared-platform:1.2.3"))
// or import a platform from a local project
implementation(platform(":my-project:version-platform"))
// no need to define a version, if it's defined in the platform
implementation("com.fasterxml.jackson.core:jackson-databind")
}
This is the best of both worlds. Projects can be explicit about their dependencies, retain autonomy, while the versions can be aligned across independent projects.
I have a Maven dependency, pulsar-log4j2-appender, which I forked and changed the source code because it was throwing exceptions in my project.
After changing the source code, I ran the maven package command to build the jar and imported it into my project (in Intellij: Project Structure | Modules | Dependencies | Add JARs or directories...).
However, when I run the application, it seems like it's not able to find that dependency because the Pulsar appender which I declared in my log4j2.xml file isn't being configured.
Am I importing the JAR properly? I'm wondering if the JAR needs to be within the org.apache.pulsar namespace to be imported properly.
For example,
This is what the dependency looks like unaltered:
And this is what it looks like when I modify and build it myself:
If you modify the code from an open source project you should change both the groupId and the artifact id. If you do not you will have problems and future developers will say your name in ways you do not want to hear.
Changing these are necessary so that Maven knows to use your version instead of the publicly available version. Also, when people look at your project and see the groupId and artifactId from the "real" project they will naturally assume that is what is being used (which is why they will curse you if that is not the case). In addition, you will have to do something convoluted to get Maven to use your dependency reliably.
The practice I have followed is the prepend "com.mycorp", where mycorp is my employer's name, to the groupId and add mycorp into the artifactId. The only downside to this is that you must ensure that the "real" artifact's coordinates are not referenced as a dependency or as a transitive dependency or else you will have duplicate classes on the class path.
Finally, your best bet is to create a pull request for Apache Pulsar with your fix so that other people experiencing the same problem you are get the benefit of it.
I am trying to build my Java project into two different version, each one based on different versions on the same dependencies. Specifically, my project A requires a dependency B, which has two different versions (e.g. v1 and v2). I am looking to build project A with each dependency version of B and get as artifact two different jars: A-v1.jar and A-v2.jar. The source code is the same so I wouldn't want to duplicate it into two different Maven projects, as I am looking to scale it when new versions of B will be released.
What I have tried so far: I defined two build profiles v1 and v2 where I have specified the dependency B version. This works fine as I can build the two profiles, but the issue is that I have no idea how to tell Maven to add a version number to the build artifact. It always builds project A into A-1.0.jar, where 1.0 is the project A version in the pom.
One update of my investigation: I have added a finalName element in the build section of my parent pom to override the default artifacts naming. Now the naming will be like ${artifactId}-${project.version.mycustomver}, where project.version.mycustomver property is defined in each build profiles. This seems to generate the correct naming of jars, however maven-install-plugin is changing the artifacts names back to ${artifactId}-${version}. No idea why and how to avoid it.
I appreciate any suggestion. Thanks,
DanP
You can either use classifier which is somehow made for that.
But you should also be able to change the version using a property that is overridden in the profiles.
Since you need two distinct POMs, one per "version" of your project, you in fact need two projects. However, you can have one normal version A. And a second one which is empty but uses dependency management to exclude and replace the dependencies that changes from A-v1 to A-v2.
I have a project contains two sub projects:
A. a common library for external api
B. a program depends on above library
They are inside same directory. How I made B refer to A with maven?
Normally you will always share through a maven repository. That is mavens way to ensure a consistent and correct solution and a solution shareable by all developers.
You should search for a public maven repository with project A (e.g. http://search.maven.org or http://mvnrepository.com) and include in your pom
If it does not exist in public (is proprietary in someway or other), consider using an enterprise-wide maven repository such as nexus or artifactory to push to repositories.
Finally, some developers resort to either installing a mvn-local file if you are ever only going to work on an explicit workstation.
If you still prefer a filebased acces, it is possible to define a maven file repository and reference it in your pom. E.g. Heroku use this for bundling extra dependencies into their system.
Declare A as dependency in B's pom.xml. Make sure A has valid pom.xml and is deployed to your repository (local/nexus). We do that all the time. Take care to assign SNAPSHOT version if you always want latest to be pulled from repository.
In my multi-module Maven project, suppose I have two modules, car and horse. They both depend on a JAR file, transport.jar, a file not available in any online Maven repositories. As such, I need to find a way to make these modules depend on a file found somewhere in the project folder structure.
From what I understand, the default Maven solution would be to manually register the JAR file in the local repository. While this would work on a development machine, it breaks on the build server, which clears its local repository before each build.
I've been searching online on how to do this on and off for a while and found some helpful things, but nothing that completely works.
For instance, a common answer is to add a dependency to the file using <scope>system</scope>. However, not only do others claim that it's extremely bad practice to do so, it also doesn't work on the build server. (On a side note, I would also like to point out that using absolute paths to the JAR is also out of the question due to, again, it being built on several different machines.)
A more useful method I found was to define a local repository in the POM file, pointing towards the path file:${project.basedir}/lib. (Such as in this article) Unfortunately, if I place the JAR and repository definition in the car POM, I cannot successfully add a dependency to the JAR in horse. I've tried both with and without an additional reference to car in horse, as well as defining a second repository in horse, pointing to file:${project.basedir}/../car/lib. This problem would also remain if I tried to make a third module, transport-lib, specifically for wrapping the JAR dependency.
I could most likely add the JAR file to both modules and define two separate module-local repositories, but I really don't want to unless I have to due to the need to keep the two (often updated) JARs in sync etc.
So, my question is as follows: Can someone give me a confirmed-to-work method to have two modules depend on the same JAR file inside the project, given the parameters and restrictions mentioned?
Best solution is to use a repository manager like Archiva, Artifactory or Nexus and install that artifact into the repository manager. Afterwards you can use this artifact directly in your pom files without any issue.
Don't use the scope system, cause it will cause other problem after a release for other etc.