Source with gradle and maven build systems fails about java

[dsyer]

There's a workaround for the Petclinic which is to set BP_MAVEN_POM_FILE to a non-existent file. E.g.

$ pack --env BP_MAVEN_POM_FILE=no-such-file.xml build dsyer/petclinic
...
aving dsyer/petclinic...
*** Images (9738aa16341a):
      dsyer/petclinic
Adding cache layer 'paketo-buildpacks/bellsoft-liberica:jdk'
Adding cache layer 'paketo-buildpacks/syft:syft'
Adding cache layer 'paketo-buildpacks/gradle:application'
Adding cache layer 'paketo-buildpacks/gradle:cache'
Adding cache layer 'cache.sbom'
Successfully built image dsyer/petclinic

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).

[dmikusa]

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

[dsyer]

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".

[scothis]

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).

[dmikusa]

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:

1. It would be a little awkward, but we could more strongly enforce the buildpacks' assumption that there is a mutually exclusive relationship with the build tools & if multiple are detected then we have a more friendly error message. Possibly instructing the user how to proceed. I think this would be the most correct option, we'd never make the wrong choice, but also the least user-friendly as we'd require the user to resolve the conflict which is more work.

2. I think we could do something similar and provide a guard in the build tools buildpacks such that if multiple pass detection at the same time, only one would run at build time (the others would no-op). Basically, they would perform a similar check to detection prior to building. If that passed at detect, but failed at build then we could assume that another build tools buildpack ran and processed the application since the last thing a build tools buildpack does is delete the application files. This would result in whatever is first in the order group winning. That may or may not be what the user wants, but with demo apps it is probably the friendliest approach. They would at least build out-of-the-box. We'd then have to have some way of overriding the default behavior, so a user could force a particular build tool to be used.

3. A third possibility would be to make an indicator, possibly a hidden file, that you could embed in the project to indicate which you as the demo project author thing should be the default (unless I'm overlooking something that would naturally exist to differentiate). @dsyer mentioned that for PetClinic Maven should be the default, but I suspect for other demo authors Gradle might be the preferred default. Neither of the above two options would accommodate this author preferred default scenario. This is slightly different from an environment variable as well in that the demo author could pick this default and it's applied automatically, whereas with env variables the user would have to set something, possibly copied out of the README for the demo. That puts a little more work on the user of the demo.

Thoughts or preferences on the options above? I'm open to options I may have missed as well.

[kiwi-bui]

Has there been any development on an ability to specify what build pack to use by any chance?

[dmikusa]

@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.

[c0d1ngm0nk3y]

Thoughts or preferences on the options above? I'm open to options I may have missed as well.

How about adding the user the possibility to fix this at least?

Sure, it works by setting BP_MAVEN_POM_FILE, but it is not that intuitive and sounds a bit hacky, doesn't it? How about BP_MAVEN_ENABLED and BP_GRADLE_ENABLED?

[dsyer]

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.

[dmikusa]

Sure, it works by setting BP_MAVEN_POM_FILE, but it is not that intuitive and sounds a bit hacky, doesn't it? How about BP_MAVEN_ENABLED and BP_GRADLE_ENABLED?

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 _ENABLED flags could also potentially be confusing as it could be unclear if users need to always set these (i.e. even if there is just a pom.xml or build.gradle file, not both) to perform a build, so I worry it could impact new user experience in general, not just this specific use case.

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).

[c0d1ngm0nk3y]

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.

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 _ENABLED flags could also potentially be confusing as it could be unclear if users need to always set these (i.e. even if there is just a pom.xml or build.gradle file, not both) to perform a build, so I worry it could impact new user experience in general, not just this specific use case.

Would it though? The user only knows about these from the documentation and the default is then documented as true. And it would be very clear what they are doing. So I don't see any room for confusion what so ever.

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

Yes, I doubt that it is worth it for this quite specific case.

and because there is a fairly simple workaround (also not new-user friendly, but it does work).

When when talking about user experience, this "workaround" is far from ideal. TBH, I don't see any difference to _ENABLED other than it is harder to discover and understand. You could even argue that your point with the user confusion could be made here as well - do the user always have to set this?

[anthonydahanne]

For people returning to this issue in 2024; here's the current status:

Provided you have source code that includes both build.gradle(.kts) and pom.xml :

• The Java buildpack default order is to pick Gradle first, and then Maven; Maven won't do anything though
• If you only want Maven to be part of the build, then set: BP_GRADLE_BUILD_FILE=nope.gradle - gradle won't participate AT ALL
• If you only want Gradle to be part of the build, then set: BP_MAVEN_POM_FILE=nope.xml - maven won't participate AT ALL

If you believe there should be _ENABLED options, because those workarounds are not good enough, IMO you should probably first re consider having both build.gradle andpom.xml in your source.