Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

7054 payara bom #7064

Merged
merged 2 commits into from
Jul 13, 2020
Merged

7054 payara bom #7064

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3348723
Make pom.xml use Payara BOM to keep dependencies inline with provided…
poikilotherm Jul 8, 2020
b584a06
Move Payara patches repo to top of the repo list, being used first. #…
poikilotherm Jul 8, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 19 additions & 12 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,11 +26,8 @@
<skipUnitTests>false</skipUnitTests>

<jakartaee-api.version>8.0.0</jakartaee-api.version>
<!-- Make this correspond to the version used in Payara: 5.201 uses (patched) 2.3.14 -->
<mojarra.version>2.3.14</mojarra.version>
Copy link
Member

Choose a reason for hiding this comment

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

Does the version of Mojarra no longer matter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does, but it is already included in the BOM. It should be kept the same as the appserver anyway, so that updating is now obsolete.

Instead, we change the appserver version in payara.version.

<payara.version>5.2020.2</payara.version>
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean that this new "payara.version" property needs to be bumped every time we want to move to a new version of Payara?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should be moved. This is not a must, but a strong should.

This hasn't happened in the past with GF 4.1, as that appserver hadn't any updates. It won't be much of a hassle to do this and it makes testing with newer appserver versions easier.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By the way, as the article outlined, too: you would do this with the Wildfly/Jetty/Liberty BOM when using those appservers.

You might think about creating different maven profiles when multi appserver compatibility becomes a feature.

Copy link
Member

Choose a reason for hiding this comment

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

Ok. Maybe after we've done a few of these Payara upgrades (pull request #7036 was the last one), we'll get into a nice pattern of which files need to be touched (similar to how we know which files to touch when making a release, and even document them). So heads up here to @donsizemore (who made the last bump) that a new line is being added.

<aws.version>1.11.762</aws.version>
<!-- Should always correspond with Payara bundled version: 5.201 uses 2.10.2 -->
<jackson.version>2.10.2</jackson.version>
<commons.logging.version>1.2</commons.logging.version>
<httpcomponents.client.version>4.5.5</httpcomponents.client.version>
<junit.version>4.12</junit.version>
Expand Down Expand Up @@ -63,6 +60,17 @@
<!--Maven checks for dependendies from these repos in the order shown in the pom.xml
This isn't well documented and seems to change between maven versions -MAD 4.9.4 -->
<repositories>
<repository>
<id>payara-patched-externals</id>
Copy link
Member

Choose a reason for hiding this comment

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

Does this further tie us to Payara? Would it be harder to switch to Liberty or Wildfly, for example?

Copy link
Member

Choose a reason for hiding this comment

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

Whoops. I asked this twice. Here's the answer from @poikilotherm from #7064 (comment)

"Yes. But we are pretty bound to Payara anyway, as we rely on their patched lib releases. As long as those don't hit upstream, it would lead to troubles when deploying to Wildfly/Liberty/... anyway."

<name>Payara Patched Externals</name>
<url>https://raw.github.com/payara/Payara_PatchedProjects/master</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>central-repo</id>
<name>Central Repository</name>
Expand Down Expand Up @@ -96,18 +104,18 @@
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-bom</artifactId>
<version>${aws.version}</version>
<groupId>fish.payara.api</groupId>
<artifactId>payara-bom</artifactId>
<version>${payara.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
<version>${jackson.version}</version>
<scope>import</scope>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-bom</artifactId>
<version>${aws.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
Expand Down Expand Up @@ -268,7 +276,6 @@
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>jakarta.faces</artifactId>
<version>${mojarra.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
Expand Down