Drop Jackson dependency

[rcsilva83]

Hello!

I'm trying to use easy-random on my project but I'm getting an error:

"java.lang.ClassNotFoundException: com.fasterxml.jackson.annotation.JsonMerge"

I struggled to figure out that easy-random depends on Jackson and my project depends on a different Jackson version.

Would it be possible to remove the dependency from Jackson? I think utility libs should have as minimum dependencies as possible to avoid such conflicts and it is been used for just 1 single method (objectMapper.convertValue on ReflectionUtils).

Thank you very much for your attention and for developing easy-random!

Regards,

Rodrigo

[fmbenhassine]

Hi Rodrigo,

Thank you for opening this issue! I would be the first to remove any dependency!

Jackson is used to convert randomizer constructor arguments to their expected types, here is an example:

class Product {
    @Randomizer(value = DateRangeRandomizer.class, args = {
            @RandomizerArgument(value = "2016-01-10 00:00:00", type = Date.class),
            @RandomizerArgument(value = "2016-01-30 23:59:59", type = Date.class)
    })
    private Date date;

    @Randomizer(value = IntegerRangeRandomizer.class, args = {
            @RandomizerArgument(value = "200", type = Integer.class),
            @RandomizerArgument(value = "500", type = Integer.class)
    })
    private int price;
}

we basically need to create an instance of DateRangeRandomizer with the provided date values (same for IntegerRangeRandomizer).

Unless we are ready to implement String to "Any type" conversion in Easy Random (with all the joy of handling date/number formats, locales, etc), I fail to see how we can get rid of Jackson (or any other dependency that provides this conversion logic).

You can always exclude Jackson from Easy Random and use the one already in your classpath.

I'm closing this issue for now, but feel free to add a comment about your thoughts!

[rcsilva83]

Thanks for your response! Could you repackage Jackson and embbed it, so you could drop the Maven dependency?

[fmbenhassine]

No, that is not an option for now.

[chrisgleissner]

Hello @benas,

thanks for creating and maintaining this highly useful framework. I integrated it into another project and I am trying to get rid of the com.fasterxml.jackson.core dependency of J-Easy. I already wrote a custom RandomizerRegistry which I added at the highest priority and which handles date types such as LocalDate, among others. Moreover, I don't use the @Randomizer feature you mentioned further up in this thread. Nevertheless, when I run my J-Easy reliant tests that populate a simple Pojo, the J-Easy initialization returns null instead of a properly instantiated and populated class.

Also, like the original creator of this thread, I do agree that a general purpose framework like J-Easy would be even more useful if it would not depend on a framework like Jackson which is popular, but just one among many Json serializer frameworks. In our case, this design choice creates a clash with an already existing standard JEE 8 serializer framework and means we currently can't use J-Easy in parts of the application.

Which approach do you recommend for removing the Jackson dependency?

Thanks
Christian

[rcsilva83]

I don't use @Randomizer either.

[fmbenhassine]

Hi,

I managed to drop the dependency to jackson in favour of a small utility method to convert values to Java's built-in types (See 62b58cb). I think this is a good start for now and should cover the majority of use cases.

This will be part of the upcoming 4.2 release.

[chrisgleissner]

Thank you, this is excellent news! I had some trouble popularising your excellent tool in the project since the JEE reference implementation is Yasson which clashes with Jackson - so this will be useful.

…

On Sat, 14 Mar 2020 at 22:37, Mahmoud Ben Hassine ***@***.***> wrote: Hi, I managed to drop the dependency to jackson in favour of a small utility method to convert values to Java's built-in types (See 62b58cb <62b58cb>). I think this is a good start for now and should cover the majority of use cases. This will be part of the upcoming 4.2 release. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JA67SIN4MT7MWJB77NJDRHP2KRANCNFSM4HOU2UYQ> .