feat: Add cron expression assertion, Related to #3212

[neilwangweili]

It contains following apis:

CronExpression cronExpression = new CronExpression("* * * * * *"); 
assertThat(cronExpression).isValid();
assertThat(cronExpression).containsExactlySeconds(...); 
assertThat(cronExpression).containsExactlyMinutes(...); 
assertThat(cronExpression).containsExactlyHours(...); 
assertThat(cronExpression).containsExactlyDayOfMonth(...); 
assertThat(cronExpression).containsExactlyMonth(...); 
assertThat(cronExpression).containsExactlyDayOfWeek(...); 
assertThat(cronExpression).containsExactlyYear(...);

Check List:

• Fixes Add cron expression assertion support in assertj-core #3212 (ignore if not applicable)
• Unit tests : YES
• Javadoc with a code example (on API only) : YES
• PR meets the contributing guidelines

Following the contributing guidelines will make it easier for us to review and accept your PR.

[scordio]

Thanks, @neilwangweili! We'll review it shortly.

Two initial thoughts:

• I'd avoid additions to the internal package and I'd rather favor package-private classes in the api package, if they are required
• I'm not sure we should expose CronExpression publicly, I'd rather keep it as an implementation detail so CronExpressionAssert and the abstract parent would be applied to String values instead of CronExpression objects. This should give good interoperability with CronExpression types from third parties, like the one from Spring, where a toString. However, this would trigger the addition of a navigation method to AbstractCharSequenceAssert (maybe asCronExpression), similar to AbstractStringAssert::asBase64Decoded.

WDYT?

[scordio]

Related to my comment, having this new type in the internal package and exposing it as part of the public API like in assertThat(CronExpression) will cause trouble in module-path and OSGi based applications.

[neilwangweili]

Thanks, @neilwangweili! We'll review it shortly.

Two initial thoughts:

• I'd avoid additions to the internal package and I'd rather favor package-private classes in the api package, if they are required
• I'm not sure we should expose CronExpression publicly, I'd rather keep it as an implementation detail so CronExpressionAssert and the abstract parent would be applied to String values instead of CronExpression objects. This should give good interoperability with CronExpression types from third parties, like the one from Spring, where a toString. However, this would trigger the addition of a navigation method to AbstractCharSequenceAssert (maybe asCronExpression), similar to AbstractStringAssert::asBase64Decoded.

WDYT?

Okay, I'll look into it and do what you want. I don't have time this week so I'll do it next week.

[scordio]

No worries, take your time of course, and let's also wait for some thoughts from @joel-costigliola.