Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@jpschewe
Copy link

This resolves issue #10
Note that this requires JDK 17 due to the dependency on the spring-test library for mocked objects.
I did a fair amount of changes to try and remove warnings from the new compiler.
I haven't used the install task before, so that is commented out as the updated version of gradle is not happy with it.

- use sprint-test 6.0.0-M2 to support jakarta package names
- upgraded to require Java 17 (needed for new spring mock class)
When specifying a full time, the timezone is now written in words.
GGGG maps to the full form, which is using words
Full form of the timezone is words
- DateTimeFormatter does not pad fields with zero unless explicitly
specified
- full format uses words for month and timzone
The challenge is that the 'e' format specifier may start on Sunday or
Monday depending on the locale. The first day of the week has a value
of 1, each day after that increments by 1.
Newer versions of gradle have solved this.
The change to the jakarta package names makes this version
incompatible with previous versions.
- update readme with changelog entry
- finalize variables and parameters
- ensure that release calls super.release
- add missing javadoc
@sargue
Copy link
Owner

sargue commented Feb 2, 2022

Impressive PR, thanks.

I think this is too much for keeping the same artifact id as I expect this to break almost all current projects. The requirements are really recent. This project was meant as a transition. It feels a bit weird using this library with such newer environment.

This was created at a time Java, and Java EE specially, was kind of stalled. So the original JTSL didn't support Java 8 java.time classes nor did we have an ETA.

Now I can see there are newer versions under Eclipse EE that perhaps are working correctly: https://projects.eclipse.org/projects/ee4j.jstl

Did you check that library?

@jpschewe
Copy link
Author

jpschewe commented Feb 2, 2022

Yes, that's the standard JSTL library. There haven't been any new releases of it and looking at the source it still only supports java.util.Date.

build.gradle Outdated
}

repositories {
mavenLocal()
Copy link
Owner

Choose a reason for hiding this comment

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

Why the local repository?

Copy link
Author

Choose a reason for hiding this comment

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

That's the standard setup I use and I needed to publish it locally to use it elsewhere.

Copy link
Owner

Choose a reason for hiding this comment

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

I would prefer not to add this, it can be a source for inconsistencies and it's not recommended.

There are better ways to handle local dependencies with gradle.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the pointers. It's been removed from this PR and I'll be looking at my other projects.

Copy link
Owner

Choose a reason for hiding this comment

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

Are you sure you've removed the mavenLocal() repository? I still see it.

Copy link
Author

Choose a reason for hiding this comment

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

Sorry, I thought I had. It should be gone now.

@sargue
Copy link
Owner

sargue commented Feb 8, 2022

I'm trying to review this but there are several changes that I think are due to line endings. This makes the review really hard as the diff are not working.

Indeed the configuration, or lack thereof, and current line endings are probably not what they should be according to best practices. I'm not sure how to fix that with the least effort required on both parts (base project and PR).

@jpschewe
Copy link
Author

jpschewe commented Feb 9, 2022

I'm trying to review this but there are several changes that I think are due to line endings. This makes the review really hard as the diff are not working.

Indeed the configuration, or lack thereof, and current line endings are probably not what they should be according to best practices. I'm not sure how to fix that with the least effort required on both parts (base project and PR).

Try looking at commit by commit. I separated out the dos2unix and cleanup commits from others. The original repository has a mix of dos and unix line endings. Fixing that and then comparing will likely show a cleaner diff.

This also removes the reference to ben-manes.versions.
@sargue
Copy link
Owner

sargue commented Feb 9, 2022

Thanks for the follow-up. I will start with your other PRs to fix the line endings on the repository, then we can continue with this bigger PR.

Comment on lines 37 to 38
* Support for tag handlers for <formatDate>, the date and time formatting
* tag in JSTL 1.0.
Copy link
Owner

Choose a reason for hiding this comment

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

Why? This is just a reformatting change. I prefer to avoid non-relevant changes so the history of a file only contains useful information, as long as it's possible.

Copy link
Author

@jpschewe jpschewe Feb 9, 2022

Choose a reason for hiding this comment

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

It seemed like a good idea to have clear documentation. I can remove it if you'd prefer.

Copy link
Owner

Choose a reason for hiding this comment

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

Yes, thank you. I know I'm quite picky about keeping the change history as tidy as possible.

@Override
public void release() {
init();
super.release();
Copy link
Author

Choose a reason for hiding this comment

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

@sargue would you like this super.release() call removed? Given that this is overriding a parent class method it probably should be there.

Copy link
Owner

Choose a reason for hiding this comment

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

Yes please. This is code from the original library that it's supposed to be working perfectly fine, so I prefer not to modify it unless there's some specific problem.

Why the original author didn't call the parent method I don't know.

Copy link
Author

Choose a reason for hiding this comment

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

Done

// Releases any resources we may have (or inherit)
public void release() {
init();
super.release();
Copy link
Owner

Choose a reason for hiding this comment

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

Let's also remove this as discussed in the other equivalent change.

Copy link
Author

Choose a reason for hiding this comment

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

Done

The code was working before without these, so keep the PR as minimal
as possible.
@sargue sargue merged commit bf6ff39 into sargue:master Feb 19, 2022
@jpschewe jpschewe deleted the issue/10 branch February 19, 2022 21:32
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