Hi Jacob,

Thanks for raising this issue.

I think named will be important here, I'll throw out these ideas. A combination of the groupId and the key parts of the artifactId.

com.amazonaws.lambda.core
com.amazonaws.lambda.events
com.amazonaws.lambda.eventstransformer
com.amazonaws.lambda.log4j
com.amazonaws.lambda.log4j2

Thoughts?

Mark,

Thanks for the quick response.

I agree with the names you've suggested. However, I'm not sure if it's recommended to suffix a module name with a digit (com.amazonaws.lambda.log4j2), but I'm not able to suggest anything better.

I've done as PR using the following naming convention for module names:

aws.lambda.core
aws.lambda.events
aws.lambda.events.sdk.transformer
aws.lambda.log4j2
aws.lambda.runtime.interface.client
aws.lambda.serialization

I'm happy to rename them to com.amazonaws.lambda.* instead of aws.lambda.* if required.

I'm building a modular library that uses aws lambda core, it would be great if we could get this moving so that I don't constantly get these compiler warnings

all libraries in this repository compiled with java8

module-info.java is supported since java9. Is there a way to have the required entry in META-INF/MANIFEST.MF to enable modularisation, and at the same time keep java8 compiler?

You can have automatic modules with java 8. module-info.java is the only thing java 9+ exclusive

note that aws.lambda.runtime.interface.client isn't a valid module name as it contains a keyword. I've changed the PR to simply use aws.lambda.runtime.client

module-info.java is the only thing java 9+ exclusive

I said that, but there is a way to add a module-info.class to a java 8 jar without breaking compatibility. I have created a PR for the core module.

I'm in favour of using the moditect plugin over simply defining an automatic module name. Having a module-info is the better option.

So how are we feeling? Do we plan to merge that PR?