Better support for Quarkus.

[matejvasek]

Relates and depends on paketo-buildpacks/maven#76

This buildpack is little bit spring specific.
It search only for Start-Class not Main-Class it think we should try both
(Start-Class should be first so backward compatibility is preserved).
Quarkus produces file containing native-image flags, this buildpack could check whether the file is present and use those flags.

[salaboy]

@matejvasek I think we will save loads of time to people if we manage to align quarkus and spring native build packs.. so +1 to this issue .. I was looking at #83 and it seems related as well.

[jjbustamante]

Hi guys, I will try to help with this issue, I have a personal project running with Quarkus, I tried to build it using the Paketo Native Buildpack and the issue was reproduced

[dmikusa]

Yes, I think that is the blocking issue at the moment. @jjbustamante - You're hitting #83. Start-Class is a Spring Boot convention that's in the native-image buildpack because historically the two were very tightly coupled.

I submitted a PR for #83. That should get you past the present issue. I think we still need to address paketo-buildpacks/maven#76 though, so I'm not sure you'll get a successful build just yet. It would help to get feedback though, so I can see what needs to be done next.

See #83 (comment) for instructions on trying that PR.

Thanks

[jjbustamante]

Hi @dmikusa-pivotal.

Thanks for the tip regarding the PR you already have for this error, I was doing some tests with your image but I am facing some errors. I just left a comment here

[jjbustamante]

Hi guys.

Regarding this issue, I managed to generated a native-image from the Quarkus getting-started example application using the code from the PR in the maven Buildpack and some other changes I did for this native-image Buildpack.

Now, I would like to get feedback on the approach:

• I am assuming the native-image Buildpack is going to receive in the /workpsace layer all the files requires to invoke the native-image executable, for example:

getting-started-1.0.0-SNAPSHOT-runner.jar  
lib  
native-image.args

• Currently the native-image is generating the native from a Main-class but we can also generate a native image from a jar file see. For this particular case, I want to enable the option to do that instead of looking for a Manifest file already uncompressed in the /workspace I am invoking the native-image executable from a jar file.

Right now I have the problem of how to get the Classpath without having to uncompressed the jar and explore it, one way is to force to have a lib/ folder and that's it (that is how I am doing right now).

Another thing I would like to validate is if we can try to use the *.args it has some optimizations and maybe the buildpack can try to get something from there, but I am not sure yet.