Source with gradle and maven build systems fails #423
Comments
|
There's a workaround for the Petclinic which is to set Unfortunately that doesn't work for all projects because there is no corresponding env entry for the Gradle buildpack (you can't switch it off). |
|
I can remember this coming up once before. Someone accidentally had their project set up such that it triggered both Maven and Gradle. At the time, we didn't make any changes because it was essentially a user error and we couldn't think of a case where you'd want both. Can someone elaborate on why there are two build systems? And what is the desired outcome here? Should it be running both? Should it only run one? If so, which one should it pick? Thanks |
|
It's quite common with demos and guides (all of the guides on spring.io for instance). I would expect the user to be able to choose at least, if we can't come up with a sensible default. In the case of the Petclinic I would want the Maven build to be the "source of truth". |
|
Based on the current behavior, it seems that the gradle and maven buildpacks are mutually exclusive. Should they be moved into independent groups and made non-optional within the respective group? Then whichever build system is listed first would "win". If the order picks wrong for the project, then you can use something like the work around Dave mentioned (hopefully that's rare). |
|
Ok, that makes sense for demos and guides. You don't know which tool the user would be using so you support both. The trouble from the buildpack perspective is that you don't know what the user would prefer. The typical signal for what the user prefers is what build files they have included. Since there are both, we don't really know which one to use. We could pick one, but then we end up making the decision for the user and that'll never be right 100% of the time. We can definitely do better. A few thoughts:
Thoughts or preferences on the options above? I'm open to options I may have missed as well. |
|
Has there been any development on an ability to specify what build pack to use by any chance? |
|
@kiwi-bui Not in terms of automating this. The trouble is that when you have both, the buildpack can't know which one to pick. It requires user intervention. You can force one or the other. See #423 (comment) which shows the workaround. The same config setting exists for Gradle, so you can do the same workaround with it as well. |
How about adding the user the possibility to fix this at least? Sure, it works by setting |
|
The Gradle build pack now has the corresponding build file env var. You can set it to a non-existent file and the buildpack will pick Maven. |
This is an option that I was specifically trying to not do. I would rather fix this problem in a way that the user doesn't have to intervene. I think having these Anyway, we haven't actually looked at fixing this in a more permanent way because the main places where this has been reported are demo apps, because fixing this would be a high level of effort, and because there is a fairly simple workaround (also not new-user friendly, but it does work). |
But in any case, the user needs a way to intervene. The question is always or "just" is the buildpacks took the "wrong" decision. I think having these Would it though? The user only knows about these from the documentation and the default is then documented as
Yes, I doubt that it is worth it for this quite specific case.
When when talking about user experience, this "workaround" is far from ideal. TBH, I don't see any difference to |
|
For people returning to this issue in 2024; here's the current status: Provided you have source code that includes both
If you believe there should be |
What happened?
Spring PetClinic has long had a maven build, recently a gradle build was added.
Using the latest tiny paketo builder, both the gradle and maven buildpacks detect. The gradle buildpacks runs, removes the source code, then the maven buildpacks fails running because it's unable to find a pom.xml
Build Configuration
Checklist
The text was updated successfully, but these errors were encountered: