Chore/upgrade spring to 5 3

[cbeach47]

Spring upgrade to 5.3.

• Brought in Liferay portlet support
• Fixed some deprecation warnings due to dependencies
  • Removed the json mapper view. The JSON portlet type does not appear to leverage that mapper view.
• Deprecated Gateway SSO portlet type
  • Compiles, but did not test runtime functionality
• Added lombok dependency and replace log instantiation with @Slf4j.
• Ensured all log4j dependencies/references were removed
• [EDIT]: Hook in uPortal parent pom and clean up deps.
  • parent pom PR: Add common deps from Webproxy Spring5 upgrade. Add and adjust plugins uportal-portlet-parent#3

Testing note: Due to available time, not all classes with the logging switch were tested. However - some were tested, and the logging switch was a simple switch across the board without logic adjustments.

[ChristianMurphy]

Thanks @cbeach47!
From skimming the code (I have not tested this locally) it looks good!

[groybal]

I see some issues with dependencies when I deploy the portlet to Tomcat. In WEB-INF/lib, I noticed:

• I see both of these jars but I think we only want the slf4j one: commons-logging-1.2.jar and
  jcl-over-slf4j-1.7.5.jar
• there are two jaxb-core jars (jaxb-core-2.2.7.jar and jaxb-core-2.3.0.1.jar)
• I see this jar,which I think is no longer needed: spring-webmvc-portlet-4.3.30.RELEASE.jar
• I see mockito-core-4.9.0.jar, which is only needed for testing and therefore should not be here

[groybal]

Why was this removed? When I deploy the portlet to Tomcat, I see both these jars in WEB-INF/lib, but I think we only want the slf4j one:

• commons-logging-1.2.jar
• jcl-over-slf4j-1.7.5.jar

[cbeach47]

For logging, the goal is logback (via the slf4j api). All other logging implementations (even transitive ones) should be removed. I'll look into how commons-logging is still getting deployed.

The JCL bridges (-over-) are now included in spring-jcl, so we don't have to explicitly declare them in the pom, however, I'll need to check if jcl-over-slf4j-1.7.5.jar is from spring-jcl, or a transitive dependency that should be excluded.

[groybal]

So, lines 201-206 actually prevent any dependency from pulling in commons-logging, which is why I think it should remain. Otherwise, you have to find which dependencies are pulling in commons-logging and add excludes.

[cbeach47]

As per our side discussion with @bjagg , I'm going in the direction of using the maven enforcer plugin, and then excluding the commons-logging jars as needed. @groybal - please let me know if you don't feel this is sufficient.

[cbeach47]

discussed in PR - change the parent pom to have a dependencies section with the excluded deps as 'provided'

[cbeach47]

@groybal -

• I see both of these jars but I think we only want the slf4j one: commons-logging-1.2.jar and
  jcl-over-slf4j-1.7.5.jar

I've now set up the maven enforcer to ban commons-logging, and adjusted the pom to not emit the commons-logging dep.

• there are two jaxb-core jars (jaxb-core-2.2.7.jar and jaxb-core-2.3.0.1.jar)

Took a deeper look at the jaxb-core jars - These 'duplicate' jars were present prior to upgrade, and deals with CAS and personDir flows. In order to control scope, I am to delay this. Added #217 for a future effort.

• I see this jar,which I think is no longer needed: spring-webmvc-portlet-4.3.30.RELEASE.jar

Good catch - I've removed it now.

• I see mockito-core-4.9.0.jar, which is only needed for testing and therefore should not be here

Ah - the scope was misconfigured. This is now removed in the deployment.

[cbeach47]

Since we only support Java 8+ , doclint is disabled at the maven-javadoc-plugin level in the parent pom.

[cbeach47]

Collapse dependencyManagement

[cbeach47]

Leave a note similar to SCP's plugin

[cbeach47]

Good to remove - note, that this locally builds, and pluto-izes the war file. Add this to the release notes.