Currently Java8 template does not support Maven as build system

[kameshchauhan]

Currently Java8 template does not support Maven as build system. As a developer, I should be able to create OpenFaaS function using java that uses Maven as build system. I have created a java8-maven template to do the same. The template is forked from the main repo openfaas/templates into my repository here: https://github.com/kameshchauhan/templates/tree/master/template/java8-maven

@pmlopes Please review and share your comments.

[alexellis]

Hi Kamesh this sounds like a fair request to me. Thank you for working on your first OpenFaaS PR.

Please can you give me a quick example of how it works and a repo where you have used it?

I'd like to see an example where you have a dependency pulled in from jcenter and another one where you have a local jar that is being bundled as a dependency such as okhttp.

My initial thoughts were that this should be maintained in a separate repo, but subject to the above working I think perhaps we should have it in the official templates repo.

:+1:

Alex

[pmlopes]

Hi, I've a few comments here, having multiple build tools, will mean that we will start seeing lots of forks of the same code and it will become hard to maintain imho. For example, the same sub modules:

• model
• entrypoint

are now duplicated so if there is a bug or improvement changes, they must be duplicated in the 2 places. Why not push these 2 modules as maven dependencies to maven central which means that they can be referred as a jar dependency regardless of the build tool (maven or gradle)?

It will also simplify the build as there's less code to compile and projects are simpler (just a single module instead of a multi module project).

Another thing is that the maven project (if I read it correctly does not configure any repos, so it means it only pulls dependencies from maven central and the readme refers to jcenter).

Local jars are not really an issue, maven has the concept of system dependencies:

<dependency>
    <groupId>com.sshx</groupId>
    <artifactId>sshx</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${basedir}/lib/sshxcute-1.0.jar</systemPath>
</dependency>

Where you can refer to project base file references.

If we want to avoid pushing stuff to maven central, then it should be a matter of testing if we can use symbolic links, then we would just keep one source of java files and distinct project files...

[kameshchauhan]

I totally agree with your suggestion. Those common projects should be on maven central. This will also potential solve the below existing problems:

1. Currently, the normal build (e.g. via gradle) is failing when running under the context of the project/function. As a developer, it is important to test project/function first before running faas-cli build *
2. Because these two projects are not available as built/compiled dependency, the type references (e.g. IRequest, IResponse, IHandler) are not available. This is impacting developer experience
3. The only build mechanism available is via faas-cli build, which is actually compiling/building the code much later in the process, resulting in very late detection of even compilation errors. This issue is also because of the point number 2.

About the use of local repo in maven template is work under progress.

[devongleeson]

I think this is related to the changes I suggested #137. If the interfaces in model were published to jCenter or maven-central, you could use whatever build tool you wanted for development of this. It might requires a few changes to how the Docker Builder works, but I don't think it would be too hard.

[kameshchauhan]

Let's agree on below:

1. Move projects of "model" and "entrypoint" from /templates/template/java8 to github.com/openfaas/templates/dependency/~ . The project can be kept as gradle or convert to maven --- Kamesh to work on it
2. Prepare above two projects artifacts to be hosted on "maven central" to start with. Follow Maven Central repo. hosting procedure. --- Kamesh to work on it 3.Set the following in build.gradle: sourceCompatibility = 1.8, targetCompatibility = 1.8 --- Devon to work on it
3. As Devon suggested "The app should be configurable, so that the function can be, for example com.tripwire.faas.MyHandler, which would make it easier to have reuse of code. I propose that the App look for configuration and reflectively call the function handler it is configured to call, and default to com.openfaas.function.Handler". --- Devon to try this

[kameshchauhan]

@alexellis I have submitted a claim of repository in Central Maven via Nexus. In order approver repository starting with com.openfaas.*, we need to prove that domain is owned by submitter. Please read comment and help resolve in the JIRA issue at : https://issues.sonatype.org/browse/OSSRH-47615

[pmlopes]

I suggest to avoid reflection for 3, and instead use ServiceLoaders, the reason is if one would prefer to build a native image, reflection will require manual configuration while service loaders won't. Also when moving to a module world (java >=9) reflection might be blocked if a module does not allow access to a specific class.

[alexellis]

Closing this issue in favour of - https://github.com/openfaas/templates/issues/210

I haven't seen a lot of acitivty on this from the community, but I am pressing ahead with it this week and would welcome your input and contributions.