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.

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

Bump io.takari:takari from 51 to 55 #303

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Bump io.takari:takari from 51 to 55 #303

wants to merge 4 commits into from

Conversation

cstamas
Copy link
Member

@cstamas cstamas commented May 23, 2024

This involves full reformat of the sources using spotless maven pluging. If this commit enters master, it MUST be followed by another one that sets this commit hash as "git blame ignore".

Changes:

  • POM parent uses takari-pom 55
  • no any other source change
  • format of java, scala and kotlin sources

Fixes #262 implicitly, by a minor cleanup among deps

@cstamas cstamas self-assigned this May 23, 2024
@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

@lefou @headius WDYT?

@lefou
Copy link
Contributor

lefou commented May 23, 2024

Lets wait for CI. I suspect removed support for Java 8.

@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

Yes, spotless-maven-plugin is 11+ so it needed Java 8 hacks (to NOT run)

@lefou
Copy link
Contributor

lefou commented May 23, 2024

I think spotless can also format Scala code, but I have no idea how to enable it. If it is based on scalafmt, I can provide a reasonable scalafmt.conf though.

Copy link
Contributor

@lefou lefou left a comment

Choose a reason for hiding this comment

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

Looks good to me.

@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

So, this is the "price" of latest Takari parent POM: spotless (palantir) formatted source code, and build will fail if unformatted code is being built: to reformat mvn spotless:apply (but you need Java 11+).

@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

Personally I love this format, whole Maven 3.9 and 4 and all plugins went to this source format as well. POM are formatted as well (element order BUT NOT like "sortpom" that is very bad idea, as dep ordering DOES MATTER).

@lefou
Copy link
Contributor

lefou commented May 23, 2024

So, this is the "price" of latest Takari parent POM: spotless (palantir) formatted source code, and build will fail if unformatted code is being built: to reformat mvn spotless:apply (but you need Java 11+).

Sounds good to me. Formatted code makes maintenance and PR management easier!

@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

Lets give some time to @headius and others to chime in...

@lefou
Copy link
Contributor

lefou commented May 23, 2024

If you want to enable spotless for scala files, you could use this config file.

@cstamas
Copy link
Member Author

cstamas commented May 23, 2024

@lefou done, pls review

<artifactId>spotless-maven-plugin</artifactId>
<configuration>
<scala>
<scalafmt />
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you need to refer to the .scalafmt.conf here. Maybe, because it's not in the repository root directory. The format of the files doesn't match the config.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup, realized that, but conf file needed change: error was:

Caused by: java.util.NoSuchElementException: version [expected 3.7.3 or 3.7.3]: 3.7.15

Comment on lines 1 to 2
# Newer versions won't work with Java 8!
version = "3.7.15"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
# Newer versions won't work with Java 8!
version = "3.7.15"
version = "3.8.1"

Copy link
Member Author

Choose a reason for hiding this comment

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

Whatever else is here than "3.7.3" the plugin pukes, with error above, unsure why.

Copy link
Contributor

@lefou lefou May 23, 2024

Choose a reason for hiding this comment

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

Maybe, we need an explicit version in the plugin config?

<version>3.8.1</version>

But I think we can live with that older version too.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right, set for wanted 3.8.1

Copy link
Contributor

@lefou lefou left a comment

Choose a reason for hiding this comment

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

Looks reasonable.

* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
* Copyright (c) 2012 to original author or authors All rights reserved. This
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks a bit ugly and is unexpected (the merged lines). Maybe, because it was formatted without any config before? Not a showstopper, but maybe you could retry with the original files?

Copy link
Member Author

Choose a reason for hiding this comment

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

Seems you were right, re-reformatted with master checkout first and looks better

Copy link
Contributor

Choose a reason for hiding this comment

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

Very nice. 👏

@headius
Copy link
Contributor

headius commented May 23, 2024

Worth it for fixing 2-space indent on all the Java files alone. 👍

This involves full reformat of the sources using spotless
maven pluging. If this commit enters master, it MUST
be followed by another one that sets this commit
hash as "git blame ignore".

No code change, just reformat of Java, Scala and Kotlin source.
@cstamas
Copy link
Member Author

cstamas commented May 24, 2024

Now, Java, Scala and Kotlin sources are formatted. Will let this PR one more day (to get possible feedback from any interested party) and will merge after.

@cstamas cstamas changed the title Bump io.takari:takari from 51 to 54 Bump io.takari:takari from 51 to 55 Jul 10, 2024
@cstamas
Copy link
Member Author

cstamas commented Jul 10, 2024

Updated PR to parent 55. Not merging yet to not stir things with polyglot-ruby, let's see is their issue fixed for start, and then will continue on this path.

@cstamas
Copy link
Member Author

cstamas commented Jul 11, 2024

@lefou can you remind me... AFAIR, you insist on Java 8 build time... Due that we are stuck on Takari Lifecycle 2.0.x (as 2.1.x lifts build time requirement to Java 11, but still can produce Java 8 bytecode).

Latest Takari Lifecycle brings among other things updated GPG signing, so this "hack" by involving maven-gpg-plugin would become unnecessary as well. Just to be clear, build time we could use Java 11+ (like a matrix of 11, 17, 21, without 8 as today), but the artifacts produced would still be Java 8 bytecode. Simply put "build time Java requirement" would be raised to Java 11.

So, do you still insist on Java 8 build time?

@lefou
Copy link
Contributor

lefou commented Jul 15, 2024

@lefou can you remind me... AFAIR, you insist on Java 8 build time... Due that we are stuck on Takari Lifecycle 2.0.x (as 2.1.x lifts build time requirement to Java 11, but still can produce Java 8 bytecode).

Most discussion happened in #257.

In summary. I'm not against dropping Java 8 build time. But since the Scala dialect supports Java 8 runtime, we also should maintain a usable integration test suite. IIUC, if we drop Java 8 build time, we can no longer run Java 8 integration tests unless we add some toolchain setup, which isn't trivial and beyond my maintenance resources.

Latest Takari Lifecycle brings among other things updated GPG signing, so this "hack" by involving maven-gpg-plugin would become unnecessary as well. Just to be clear, build time we could use Java 11+ (like a matrix of 11, 17, 21, without 8 as today), but the artifacts produced would still be Java 8 bytecode. Simply put "build time Java requirement" would be raised to Java 11.

So, do you still insist on Java 8 build time?

No.

So, if we drop Java 8 build time support, we better also drop Java 8 runtime support for the Scala dialect due to a missing test setup. Or someone contributes an integration test setup for Java 8.

Supporting an untested product is pure evil. There is no way to reproduce issues anymore.

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.

ClassNotFoundException: org.apache.commons.lang3.StringEscapeUtils
3 participants