Closed edeandrea closed 4 years ago
Thanks - this behaviour follows from the decision to not declare a default version of ScalaTest itself.
I chose not to supply a default version because ScalaTest releases were frequent and I didn't want to have to re-publish this plugin.
What sort of headaches are you describing please? As far as I can tell this is something that is done at plugin installation time and then remains in place. I agree that ScalaTest's failure message is not helpful (from memory it hangs the build?)
Cheers, Stu
So is the version of pegdown tied to the version of ScalaTest? If so I can completely understand the rationale here. If not - then adding the dependency to pegdown from scalaTest shouldn't be an issue I wouldn't think.
I work in a very large corporate environment and the more we don't have to do or declare the better for us. Simply declaring the dependency to scalaTest and getting pegdown transitively would be great.
You are correct - if you don't declare the dependency on pegdown you do get a ClassNotFoundException and it does hang the build.
Yes, it's only required if you want HTML reports (but those are enabled by default).
It might be better for this plugin to default to a safe behaviour, even if that means that users have to opt-in to the HTML report and then add the appropriate dependency.
On the other hand, this might be even more of a headache when they search for an explanation as to why there are no user-friendly reports.
It seems that the version currently required is 1.4.2, but this must be determined from the optional dependency expressed in the ScalaTest pom.
I'll do some reading and see if it's possible to walk the dependency tree at runtime when the requirements are fully known.
(I'll update the README to have a valid set of dependencies in the meantime)
I would definitely prefer if pegdown was added automatically as a dependency if a user specified that they want HTML reports.
The pegdown dependency had conflicts with other dependencies on my classpath that were annoying to resolve (it used a different version of ASM). I don't actually need the HTML reports so it was frustrating to have to workaround dependency conflicts for something I didn't need.
Note that in recent scalatest versions, they switched to flexmark instead of pegdown. So it was probably a good idea not to add pegdown automatically after all :)
Yeah, the flexmark thing threw me for a loop. Fortunately, it was an easy fix:
- testRuntime 'org.pegdown:pegdown:1.4.2'
+ testRuntime 'com.vladsch.flexmark:flexmark-all:0.35.10'
README has been updated to show the new flexmark dependency, thanks for highlighting it.
Rather than forcing users to declare
testRuntime 'org.pegdown:pegdown:1.6.0'
in their build file - this library should declare it as a runtime dependency so that users get it transitively. That would simplify a lot of headache for users.