Skip to content

Conversation

@SingingBush
Copy link
Contributor

@SingingBush SingingBush commented Jan 26, 2023

now that Java 11 is the minimum adding proper support for JPMS using a module-info.java instead of specifying Automatic-Module-Name is preferable. Unfortunately this will involve a fair amount of refactoring so this PR is a mix of both approaches.

As mentioned in JOHNZON-305, getting the Automatic-Module-Name configured using maven-jar-plugin was not working due to the bundle plugin. I ended up setting the auto module name using the maven-bundle-plugin itself in most all cases.

The core module is done properly with a module-info.java but adding that to all the maven modules won't work without a fairly large PR. I'd like to know if there's interest in merging this before making further changes.

In the projects that I've done previously with JPMS I've generally gone with the approach of putting unit tests into a different package name to prevent the split packages problem. For example, all the tests under org.apache.johnzon.core I'd change the package to something like ut.johnzon.core. That way a module-info.java can be defined in the main source and the test source. I noticed there are some tests in Johnzon that rely on test classes being in the same package as source files to get access to package private code. That would need some re-work.

Getting johnzon.core working with JPMS was fairly straight forward. I have a module info locally for johnzon.mapper that essentially works when compiling the main source but could not include it in the PR due to JsonGeneratorCloseTest using test code in the org.apache.johnzon.core package. That would be along the lines of:

module johnzon.mapper {
    requires java.desktop; // for java.beans

    requires jakarta.cdi;
    requires jakarta.json;
    requires jakarta.persistence;
    requires jakarta.transaction;

    requires johnzon.core;

    opens org.apache.johnzon.mapper.internal to johnzon.jaxrs;

    exports org.apache.johnzon.mapper;
    exports org.apache.johnzon.mapper.access;
}

Copy link
Contributor

@rmannibucau rmannibucau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think we should align info style+fix the naming for the asf

* under the License.
*/
module johnzon.jaxrs {
requires java.xml;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is optional

* specific language governing permissions and limitations
* under the License.
*/
module johnzon.core {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use org.apache in the naming

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure no problem, so for this one I'll update it to be org.apache.johnzon.core and the same convention for the others

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Automatic-Module-Name>johnzon.jsonb</Automatic-Module-Name>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To drop if we use module-info?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes using a module-info file is a better option if possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well module-info or automatic name but all modules should have the same option (it is the key). module-info has some pitfalls and will break some integration - why we dont have it yet - but since we move to 2.0 very soon I guess door can be opened now if preferred but clearly a single solution for the full project 🙏 .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok for this PR I'll keep it to simply using the Automatic-Module-Name approach. With the goal of moving over to using a module-info file in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@rmannibucau rmannibucau merged commit 157cedb into apache:master Jan 27, 2023
@SingingBush SingingBush deleted the feature/JOHNZON-305_automatic_module_names branch June 9, 2023 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants