Date assertions: Also for Joda DateTime?

[Ted Young]

I've finally merged my code with the (not so recent) JUnit test
restructuring that Alex did, so now I'm finishing up the
DateTimeAssert, but I'm finding that in our codebase we're using the
Joda time libraries much more and I was wondering what the best way to
support the org.joda.time.DateTime class might be:

1. Add a method to Assertions that takes a org.joda.time.DateTime as
an argument and simply converts it to a java.util.Date and use the
Date version of the Assert class.
2. Convert the Assert class to use DateTime internally, and provide a
method in Assertions that takes a Date and converts it to DateTime.
3. Create a new assert class that uses DateTime in addition to one
that takes Date.

The advantage of #1 is very little duplicate code. The advantage of #2
& #3 is the ability to use DateTime's better methods for comparing
dates. The disadvantage of #1 and #2 is we're creating at least one
(probably two) additional objects as we convert from/to Date and
DateTime. The obvious disadvantage of #3 is the duplication.

Also, there's the question of having a dependency on the Joda library
at all. I'm not sure if that's a concern.

;ted

[Ted Young]

So I'd like to get this checked in, my main concern is about creating a dependency on the Joda time library. Is this a valid concern, or not a big deal?

If it's not a big deal to depend on Joda time, then I'm probably going to go with #1 because it's easiest. If it's a problem, then, well, I'm not sure what to do.

;ted

[Alex Ruiz]

Hi Ted,

Sorry for the late reply :(

It's a tough decision, and I don't have an opinion yet. On one hand, as part of the FEST-Assert team, I wouldn't mind having FEST-Assert depend on Joda. But as a user of FEST-Swing (which has a "compile" dependency on FEST-Assert,) I wouldn't want an extra dependency, especially since the client project (FEST-Swing) has little to do with dates.

Even though I'm still thinking about it, I leaning towards adding Joda as dependency. Please give me a little time to think about it :D

FEST-Assert users, would any of you mind adding Joda-time as dependency?

Cheers!
-Alex

--
You received this message because you are subscribed to the Google Groups "easytesting" group.
To post to this group, send email to easyt...@googlegroups.com.
To unsubscribe from this group, send email to easytesting...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/easytesting?hl=en.

[Ansgar Konermann]

On 25.02.2010 00:33, Alex Ruiz wrote:

FEST-Assert users, would any of you mind adding Joda-time as dependency?

Sorry for the late reply.

I'd really appreciate if we could figure out a nicer way to incorporate Joda time into FEST.

I'm thinking of an "optional" dependency, i. e. if you want to use joda-related functionality, you need joda time on your classpath, if you don't want to, you needn't.

Don't have any real ideas how to implement this (yet), but maybe we can do some brainstorming together.

Regards

Ansgar

[szczepiq]

Hey guys

I agree with Ansgar. I do have a strong opinion here :) It would be
very annoying for me as a User to be forced to put jars I don't use on
the classpath. Seriously. I don't even like the fact that I need both
utils + asserts to use assertions. I'm not a maven fan-boy - I prefer
sustainable builds with libraries checked in to VCS (with gradle, ant,
etc.).

Also, additional 3rd party dependency might be troublesome in future.
For example you guys decide to be OSGi'ed. You need all your
dependencies to be OSGi'ed as well. What if joda guys change the api
at some point, etc. etc.

Here is what I suggest. You can put joda-assertion methods in some
different class (e.g. not Assertions). If this class is not imported
then compiler will not complain of missing dependency. If the class is
imported it means someone already uses joda so he has joda on
classpath anyway.

Cheers!
Szczepan

[Peter Murray]

I would also find it very annoying to have a direct dependency on joda library from the fest assertions library.
Our company requires that every library, and dependency has to be analyzed and signed off for use in our projects, even if only for testing.
It makes sense to me that this is an extension to the assertions library, so why don't you create a separate library for it?
Sent from my BlackBerry® wireless device

[JoCosti]

+1 with Peter.

> > On Wed, Feb 24, 2010 at 2:31 PM, Ted Young <tedyo...@gmail.com> wrote:
>
> >> So I'd like to get this checked in, my main concern is about creating a
> >> dependency on the Joda time library. Is this a valid concern, or not a big
> >> deal?
>
> >> If it's not a big deal to depend on Joda time, then I'm probably going to
> >> go with #1 because it's easiest. If it's a problem, then, well, I'm not sure
> >> what to do.
>
> >> ;ted
>

[Alex Ruiz]

Thanks guys for the feedback! very appreciated :)

What do you think about creating a separate project, (e.g. fest-assert-jodatime)? If we take this route, I think we have two choices:

1. Assertion for DateTime can implement AssertExtension, with a static factory method. Code using this assertion would look like this:

DateTime dt = calendar.dateTime(); // something silly
assertThat(dateTime(dt)).is..

The only downside (IMHO) is the verbosity of typing the static factory method "dateTime".

or,

2. Have the DateTimeAssert have its own "assertThat"

Looking forward to getting more feedback! :)

Thanks!
-Alex

[Ansgar Konermann]

On 27.02.2010 00:49, Alex Ruiz wrote:
>
> 1. Assertion for DateTime can implement AssertExtension, with a static
> factory method. Code using this assertion would look like this:
>
> DateTime dt = calendar.dateTime(); // something silly
> assertThat(dateTime(dt)).is..
>
> The only downside (IMHO) is the verbosity of typing the static factory
> method "dateTime".
>
> or,
>
> 2. Have the DateTimeAssert have its own "assertThat"

I preferr option 2.

Regards

Ansgar

[szczepiq]

>What do you think about creating a separate project, (e.g. fest-assert-jodatime)? If we take this route, I think we have two choices:

I don't know. As a user I'd like to be able to start using joda
assertions without any hassle (e.g. without downloading new library,
updating dependecies configuration, etc.). Why cannot we have
JodaAssert.assertThat in some ....joda package? Go for simplicity...

What if more 'jodas' appear in future - new project for every 3rd
party assertion?).

Just feedback - you decide and I will play along ;)

>> 2. Have the DateTimeAssert have its own "assertThat"
>
> I preferr option 2.

+1

Obviously (I don't know the code enough :) when I want to do asserThat
with JDK's DateTime I don't need joda on classpath, right guys? :)

Cheers,
Szczepan

[Mark Derricutt]

The problem with that is you can't statically import two assertThat's from different classes.  AFAIK.

--
Pull me down under...

[Alex Ruiz]

(Thanks everybody for your feedback!)

Mark has a good point. For some it wouldn't be a big deal not to be able to use the "assertThat" method of DateTimeAssert and the ones from Assertion, but since we are into this "fluent API" thing, I'd say we prefer to keep using static imports. Does everybody agree? :)

Something I'd like to give a try (I don't know if this will work, hopefully at least makes sense)

1. Have the DateTimeAssert as a regular assertion class like any other (in the main package)
2. Have also an 'assertThat(DateTime)' in class Assertions.
3. Since we are using Maven, joda-time can have a "provided" scope. So FEST-Assert users that use Maven won't have joda-time added to their classpath

I'll give it a try between today and tomorrow. Any thoughts?

Thanks!
-Alex

[Ansgar Konermann]

Alex Ruiz wrote:

(Thanks everybody for your feedback!)

Mark has a good point. For some it wouldn't be a big deal not to be able to use the "assertThat" method of DateTimeAssert and the ones from Assertion, but since we are into this "fluent API" thing, I'd say we prefer to keep using static imports. Does everybody agree? :)

Something I'd like to give a try (I don't know if this will work, hopefully at least makes sense)

1. Have the DateTimeAssert as a regular assertion class like any other (in the main package)
2. Have also an 'assertThat(DateTime)' in class Assertions.
3. Since we are using Maven, joda-time can have a "provided" scope. So FEST-Assert users that use Maven won't have joda-time added to their classpath

I'll give it a try between today and tomorrow. Any thoughts?

Hi all,

from what I know from our FEST-Assert use at my employer, Java does support multiple imports of static methods with the same name, but from different classes. This would also be supported by the Java Language Specification [1]. However, depending on your favorite IDE you're using and version thereof, you might need to "tune" the import optimizer/code reformatter (IIRC, some older version of IDEA combined multiple imports of the same name into one import - throwing away all except one. Reconfiguring the code style for imports to not combine static imports into *-imports solved the problem).

Regarding maven, I believe the scope of joda-time should still be "compile"; there's another dependency configuration setting which allows making the dependency "optional" [2]. I've seen this in action in the slf4j [3] logging library: it allows you to use the "native" logging library you want to use (log4j, java logging, ...), and the dependencies for these native libraries declared "optional". You just have to provide an explicit declaration in your project's pom.xml for the library you chose. We could use this approach for Joda support in FEST-Assert, and maybe we can do with *one* subproject of FEST-Assert for all the additional assertions requiring new dependencies. I still have an XmlAssert class in the pipeline ;-) If we declare the new dependencies all as "optional", the user of FEST-Assert-Extra (?) could chose which of the additional assertion classes he wants to use and include explicit dependency declarations in his pom.xml exactly for those dependencies required by the assertions he needs.

Regards,
Ansgar

[1] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12.2.1 ("In addition, if the method invocation has...")
[2] http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
[3] http://www.slf4j.org/

[JoCosti]

Hi all,

I confirm that multiple static import of the same method from
different classes works well.
I had no problem with eclipse (3.5.2) regarding to optimize/organize
import feature.

The downside of multiple static imports would be, for a user point of
view, to remember all the classes offering 'asserThat' static methods
(Assertions, DatetimeAssert, ...).
If including 'assertThat(DateTime)' in class Assertions is possible
without users projects being forced to depends on Joda time library,
it would be perfect; one single entry point for all assertions is
appealing for lazy users ;-)

After reading Ansgar link, I think this may be possible using maven
optional dependencies scope.
Last (minor) point, if I had to choose between 'provided' and
'optional' dependencies scope, I would pick 'optional' scope since,
IMHO, it expresses our need more naturally (i.e optional assertions).

Regards,
Joel

On Feb 28, 9:22 am, Ansgar Konermann <ansgar.konerm...@googlemail.com>
wrote:

> Alex Ruiz wrote:
> > (Thanks everybody for your feedback!)
>
> > Mark has a good point. For some it wouldn't be a big deal not to be
> > able to use the "assertThat" method of DateTimeAssert and the ones
> > from Assertion, but since we are into this "fluent API" thing, I'd say
> > we prefer to keep using static imports. Does everybody agree? :)
>
> > Something I'd like to give a try (I don't know if this will work,
> > hopefully at least makes sense)
>
> > 1. Have the DateTimeAssert as a regular assertion class like any other
> > (in the main package)
> > 2. Have also an 'assertThat(DateTime)' in class Assertions.
> > 3. Since we are using Maven, joda-time can have a "provided" scope. So
> > FEST-Assert users that use Maven won't have joda-time added to their
> > classpath
>
> > I'll give it a try between today and tomorrow. Any thoughts?
>
> Hi all,
>

> from what I know from our FEST-Assert use at my employer, *Java* does

> support multiple imports of static methods with the same name, but from
> different classes. This would also be supported by the Java Language

> Specification [1]. However, depending on your favorite *IDE* you're

> using and version thereof, you might need to "tune" the import
> optimizer/code reformatter (IIRC, some older version of IDEA combined
> multiple imports of the same name into one import - throwing away all
> except one. Reconfiguring the code style for imports to not combine
> static imports into *-imports solved the problem).
>
> Regarding maven, I believe the scope of joda-time should still be
> "compile"; there's another dependency configuration setting which allows
> making the dependency "optional" [2]. I've seen this in action in the
> slf4j [3] logging library: it allows you to use the "native" logging
> library you want to use (log4j, java logging, ...), and the dependencies
> for these native libraries declared "optional". You just have to provide
> an explicit declaration in your project's pom.xml for the library you
> chose. We could use this approach for Joda support in FEST-Assert, and
> maybe we can do with *one* subproject of FEST-Assert for all the
> additional assertions requiring new dependencies. I still have an
> XmlAssert class in the pipeline ;-) If we declare the new dependencies
> all as "optional", the user of FEST-Assert-Extra (?) could chose which
> of the additional assertion classes he wants to use and include explicit
> dependency declarations in his pom.xml exactly for those dependencies
> required by the assertions he needs.
>
> Regards,
> Ansgar
>

> [1]http://java.sun.com/docs/books/jls/third_edition/html/expressions.htm...

> ("In addition, if the method invocation has...")

> [2]http://maven.apache.org/guides/introduction/introduction-to-optional-...

> [3]http://www.slf4j.org/
>
>
>
> > Thanks!
> > -Alex
>

> > On Sat, Feb 27, 2010 at 4:04 PM, Mark Derricutt <m...@talios.com
> > <mailto:m...@talios.com>> wrote:
>
> >     The problem with that is you can't statically import two
> >     assertThat's from different classes.  AFAIK.
>
> >     --
> >     Pull me down under...
>
> >     On Sun, Feb 28, 2010 at 8:34 AM, Ansgar Konermann

> >     <ansgar.konerm...@googlemail.com

> >     <mailto:ansgar.konerm...@googlemail.com>> wrote:
>
> >             2. Have the DateTimeAssert have its own "assertThat"
>
> >         I preferr option 2.
>
> >     --
> >     You received this message because you are subscribed to the Google
> >     Groups "easytesting" group.
> >     To post to this group, send email to easyt...@googlegroups.com

> >     <mailto:easyt...@googlegroups.com>.

> >     To unsubscribe from this group, send email to
> >     easytesting...@googlegroups.com

> >     <mailto:easytesting%2Bunsu...@googlegroups.com>.

[Alex Ruiz]

Thanks guys so much for the feedback!

I'm going to set up the fest-assert to have the optional joda-time dependency. And I'll test it with fest-swing (client of fest-assert.)

Cheers!
-Alex

[Alex Ruiz]

I just looked at dependency scopes and the optional one doesn't show up (both docs and m2eclipse.) I'll try with "provided".

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Cheers!
-Alex

[Alex Ruiz]

Done! I tested it and in fest-swing, it didn't bring joda-time as dependency. I just checked-in. I'd appreciate if somebody else can give it a try :)

BTW, I created this task http://jira.codehaus.org/browse/FEST-313

Thanks!
-Alex

[Alex Ruiz]

Oh, I forgot to mention. I think this solution would satisfy all the points brought in this thread :)

Thanks everybody for the feedback!

Cheers,
-Alex

[Ansgar Konermann]

On 28.02.2010 18:18, Alex Ruiz wrote:

I just looked at dependency scopes and the optional one doesn't show up (both docs and m2eclipse.) I'll try with "provided".

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Cheers!
-Alex

Hi Alex,

"optional" is not a dependency scope, but an additional property a dependency can have, independently from its scope. In a pom.xml, the XML snippet would look like this (impudently stolen from the maven website):

<project>
  ...
  <dependencies>
    <!-- declare the dependency to be set as optional -->
    <dependency>
      <groupId>sample.ProjectA</groupId>
      <artifactId>Project-A</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <optional>true</optional> <!-- value will be true or false only -->
    </dependency>
  </dependencies>
</project>

m2eclipse has a tiny check box in the dependency details editor labeled "optional".

Regards

Ansgar

[szczepiq]

>>>I think this solution would satisfy all the points brought in this thread :)

Awesome ;)

[Joel Costigliola]

that's cool :)

Ansgar, thanks for pointing that optional was not a dependency scope
but a property.

On Feb 28, 11:27 pm, szczepiq <szcze...@gmail.com> wrote:
> >>>I think this solution would satisfy all the points brought in this thread
>
> :)
>
> Awesome ;)
>

> On Sun, Feb 28, 2010 at 6:31 PM, Alex Ruiz <alex.ruiz...@gmail.com> wrote:
> > Oh, I forgot to mention. I think this solution would satisfy all the points
> > brought in this thread :)
>
> > Thanks everybody for the feedback!
>
> > Cheers,
> > -Alex
>

> > On Sun, Feb 28, 2010 at 9:30 AM, Alex Ruiz <alex.ruiz...@gmail.com> wrote:
>
> >> Done! I tested it and in fest-swing, it didn't bring joda-time as
> >> dependency. I just checked-in. I'd appreciate if somebody else can give it a
> >> try :)
>

> >> BTW, I created this taskhttp://jira.codehaus.org/browse/FEST-313
>
> >> Thanks!
> >> -Alex

>
> >> On Sun, Feb 28, 2010 at 9:18 AM, Alex Ruiz <alex.ruiz...@gmail.com>wrote:
>
> >>> I just looked at dependency scopes and the optional one doesn't show up
> >>> (both docs and m2eclipse.) I'll try with "provided".
>

> >>>http://maven.apache.org/guides/introduction/introduction-to-dependenc...
>
> >>> Cheers!
> >>> -Alex

>
> >>> On Sun, Feb 28, 2010 at 9:03 AM, Alex Ruiz <alex.ruiz...@gmail.com>wrote:
>
> >>>> Thanks guys so much for the feedback!
>
> >>>> I'm going to set up the fest-assert to have the optional joda-time
> >>>> dependency. And I'll test it with fest-swing (client of fest-assert.)
>
> >>>> Cheers!
> >>>> -Alex
>

> >>>>> > >     easytesting...@googlegroups.com<easytesting%2Bunsu...@googlegroups.com>
> >>>>> > >     <mailto:easytesting%2Bunsu...@googlegroups.com<easytesting%252Buns...@googlegroups.com>

> >>>>> >.
> >>>>> > >     For more options, visit this group at
> >>>>> > >    http://groups.google.com/group/easytesting?hl=en.
>
> >>>>> > > --
> >>>>> > > You received this message because you are subscribed to the Google
> >>>>> > > Groups "easytesting" group.
> >>>>> > > To post to this group, send email to easyt...@googlegroups.com.
> >>>>> > > To unsubscribe from this group, send email to

> >>>>> > > easytesting...@googlegroups.com<easytesting%2Bunsu...@googlegroups.com>

> >>>>> .
> >>>>> > > For more options, visit this group at
> >>>>> > >http://groups.google.com/group/easytesting?hl=en.
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "easytesting" group.
> >>>>> To post to this group, send email to easyt...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to

> >>>>> easytesting...@googlegroups.com<easytesting%2Bunsu...@googlegroups.com>

> >>>>> .
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/easytesting?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "easytesting" group.
> > To post to this group, send email to easyt...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > easytesting...@googlegroups.com<easytesting%2Bunsu...@googlegroups.com>

[Alex Ruiz]

Thanks Ansgar! I'll be fixing the pom shortly :)

Cheers,
-Alex