Normalize core profile dependencies in web profile

[lprimak]

Summary

Conclusion of #133 Bug fix train
Makes Core profile a true dependency of Web profile and plays nice with MicroProfile POM
fixes #138

Goals

• Make jakartaee-api and jakartaee-web-api depend on jakartaee-core-api to be consistent with maven resolution rules, and thus make it intuitive to application both app devs and MicroProfile.
• Remove *-api.cp.version properties, as they are now overridable with 'regular' maven pom directives, and thus no longer necessary.
• Remove duplicate dependencies from jakartaee-web-api that are already in jakartaee-core-api (this can now be done safely because empty JARs are now shipped.
• Make the minimum changes necessary to accomplish the goal.
• Make this suitable as a patch release for Jakarta EE 10 (ex: 10.0.1)
• Remove unnecessary <optional> tags from POMs
• Preserve generation of javadoc as it is now (jakarta-api includes platrorm, web and core javadocs, jakartaee-web-api includes web and core javadocs, etc)
• Make javadoc generation errors fail the build. Otherwise, they fail silently generating invalid javadocs (possibly leading to invalid releases)

Non-Goals

• Not intended as a complete refactoring of the POM files

[lprimak]

@Emily-Jiang This is the PR that you may have concerns with.
Thank you!

[Emily-Jiang]

@Emily-Jiang This is the PR that you have concerns with. Thank you!

I did a quick troll through the core profile pom.xml and you were right that the CDI dependency did not have exclusion. However, I have concerns with the core profile without any exclusion for CDI as in MicroProfile, we specified exclusion deliberately. See here. @starksm64 I thought the EL and EJB dependencies were excluded from Core Profile. Why was it not the case?

[lprimak]

Emily, please see

jakartaee-api/jakartaee-core-api/pom.xml

Line 111 in 10c5894

<groupId>jakarta.enterprise</groupId>

In core profile, cdi-api excludes all dependencies, so I think what you are saying is correct. Both in current core API and after this PR is merged.

[lprimak]

Thanks for looking into this Emily!
Also, just FYI the reason I started looking into this is that Jakarta EE APIs as they currently are not playing nice with MicoProfile maven dependencies. After these PRs are merged, both Jakarta EE and MP will play much nicer with each other!

[starksm64]

@Emily-Jiang This is the PR that you have concerns with. Thank you!

@starksm64 I thought the EL and EJB dependencies were excluded from Core Profile. Why was it not the case?

The exclusion was at the spec level and could not be done at the api jar level due to the fact that we were rebuilding the jar from source. With the move to using empty jars these can be excluded.

[arjantijms]

See also jakartaee/cdi#640

[lprimak]

I want to make sure that jakartaee/cdi#640 is only tangentially related to this one, there are no dependencies between them, and certainly, this one is (or should) not be controversial.
I view this issue as a simple bug fix, that doesn't break anything, nor introduce any design or architecture changes.

This simply fixes a maven hierarchy error that doesn't make Jakarta EE currently play well with MicroProfile.
After this is merged, MP and Jakarta EE can be mixed better and will play nice together without overriding each other's dependencies or requiring exclusions or inclusions of multiple already-included Jakarta EE APIs

[JanWesterkamp-iJUG]

I have two findings here:

The BOM misses a separate Core Profile list of dependencies, that should be defined first before the Web Profile ones, so they can be managed easier.

We should get rid of this plugin here, may be in a separate PR:

    <plugins>
        <plugin>
            <groupId>org.glassfish.build</groupId>
            <artifactId>glassfishbuild-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>generate-pom</id>
                    <goals>
                        <goal>generate-pom</goal>
                    </goals>
                </execution>
                <execution>
                    <id>attach-all-artifacts</id>
                    <goals>
                        <goal>attach-all-artifacts</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

[lprimak]

yes, great idea. Also probably not part of this particular PR though

[lprimak]

@JanWesterkamp-iJUG If you want to create a separate issue for that, I can volunteer to create a PR there too

[JanWesterkamp-iJUG]

May be we can change the comment reflecting this behaviour as explanation.

[lprimak]

@starksm64 Would love your feedback here... thank you!

[lprimak]

Thank you @Emily-Jiang !
Still waiting for feedback from @JanWesterkamp-iJUG and @starksm64

[lprimak]

Thank you Scott!
@JanWesterkamp-iJUG you are the last one :)

[lprimak]

@JanWesterkamp-iJUG ping please :)

[JanWesterkamp-iJUG]

@lprimak I added some comments - sorry for the delay.

[JanWesterkamp-iJUG]

I think, this should become a required part in the Core (or Web Profile) in a future release (Jakarta EE 11) because XML is still in heavy use and is also required for some configurations (like Persistence and optionally in Servlet) - but that's a separate issue.

Good to fix it here now! But is the exclusion required - I don't think so. But I can verify this with a jQA run, to be sure.

[JanWesterkamp-iJUG]

Jakarta XML Binding got dependency to Jakarta Activation 2.1.0 - this need to be maintained. So it looks like we need this exclusion until we have that solved first unfortunately.

[lprimak]

@JanWesterkamp-iJUG I granted you write permissions for this PR so you can try some language or you can comment here

[lprimak]

Also, this PR has been open for 3 months with minimal changes and no issues. Let's merge this in and then we can work on the other, very valid, issues.

Thank you @edburns and @JanWesterkamp-iJUG !

[edburns]

Hello @lprimak , I have merged #140 from @lukasj . Can you please revise this PR to take this fact into account?

[lprimak]

@edburns done thank you

[JanWesterkamp-iJUG]

As dicussed in the Jakarta Platform call on 2023-08-22 the remaining chages will be handled in separate PRs - so this on could be merged.

Meanwhile #140 was merged before, but this one is rebased and remaining issues in #140 can be done after merging this on first.

@edburns when you agree on this, I will do this merge then.

[JanWesterkamp-iJUG]

@edburns thanks for your approval!
I will merge this now.
Further (required) updates will be done is a separate PR, as updating comments or potential updates to optional dependency handling (some are updated in #140).