Hi,
I need that a build do not fail if a maven dependency is not found on repositories.
Obviously if any class from that dependency is used, compilation will fail. But if not, build should finish without errors.
Can this be made in Gradle?
Some notes:
Thank you.
Maybe it could somehow be hacked into that, but it definitely sounds like something you should not do.
If you have optional dependencies, you should instead model feature variants.
See for example Optional dependencies are not optional
Yes, I know that is a bad practice. But is a matter of development processes in a big company rather that a technical issue.
We are developing some “devtools” that should be available in the future and should be usable in Spring applications without user intervention.
When a devtool is in the classpath then Spring Framework will pickup classes simply using it’s internal classpath scanning feature.
Any way to do this?
I’m afraid I did not understand yet.
Why would you want to depend on something that does not exist?
Why don’t you first make it exist before you depend on it?
And when you say “without user intervention”, who is the user? And who depends on what that is or is not there? And on which level do you need to ignore the non-existence?
Spring Framework can provide beans implementing any interface through various combinations of property configurations, missing classes/beans, or different component scans on the classpath.
We are highly motivated to adopt this approach for configuring Spring applications. It’s crucial to supply optional dependencies as new features are developed. Users (hundreds of other team developers) must access these features without any intervention in the build system, often without even knowing that these features exist.
Additionally, my question was specifically about whether a ResolutionStrategy, a class that is difficult to customize due to its requirement for numerous constructor parameters, could include a “failOnMissingJar(false)” method or an equivalent alternative.
This is not the appropriate forum to discuss my company’s development process.
Why are you getting mad at me?
I’m not interested in your development process.
I’m just trying to help you in my sparse spare time.
And to help, I need to understand the problem / situation.
And to me it is (still) unclear why you want to depend on something that does not exist.
And what depends on it and so on.
And I guess without some kind of MCVE it will not become clear enough for some good recommendation.
But well, as I’m not allowed to ask any questions, I’ll just answer yours with “not that I know of” without the ability to maybe provide some workable alternative.
Our projects work as follows:
prjApp:
dependencies {
implements 'mycompany:libA'
}
‘mycompany:libA’ may or may not have a ‘mycompany:devtools-libA’.
Our Gradle plugin reads dependencies with the group ‘mycompany’ and adds the corresponding ‘devtools-…’, but the plugin doesn’t know if the ‘devtools-…’ exists or not.
The list of existing ‘devtools-…’ libraries is present within our Gradle platform.
We would like to avoid defining a list in the Gradle plugin to avoid updating it every time a new ‘devtools-…’ is implemented, and we would also like to avoid HTTP calls to retrieve this list.
Having a feature that allows compileJava to not fail would be very convenient.
Thanks, that clears it up very much.
Unfortunately, it does not change much with my answer.
As far as I know you can neither tell the dependency it should be lenient, nor the configuration it should be lenient.
The only thing where it could be done I’m aware of, is an artifact view, where you can leniently resolve, so that missing dependencies are ignored, but I don’t think that will help in your situation, unless you also reconfigure each and everything using it to use the artifact view instead and I actually doubt this is even possible.
Maybe it could be an option that you have a repository that is defined after the repository that has the actually existing devtools libs and returns a result without artifact, so that the dependency resolution can find all devtools libs, but just gets results without artifact file for the missing ones (for example a POM with packaging pom).
Another option could be, that you actually publish the devtools for each and every library, for the ones don’t having one, it could again be a packaging pom type publication without actual artifact, just that something can be resolved.
Yet anothet option - depending on flexibility - could maybe be, that you do not publish the devtools under separate artifact coordinates, but publish it as feature variant for the libraries where they exist. If you then request that feature variant (by attributes, not capability) you can configure compatibility rules so that the normal variant is used if no devtools variant is found, but if the devtools variant is found it is resolved and would then have both artifacts.