If this would help with MRELEASE-564 and other equivalent issues I'm all
ears.
The issue I'm facing is that the maven-release-plugin can't detect
dependencies/artifacts specified within the configuration. These are files
you can't just add to the dependencies of the plugin, because they have
Doesnt each plugin needs its own handling?
Maybe some event base siluyion with just a spi yo register listeners is
better (like in arquillian)
Le 9 avr. 2013 21:49, "Baptiste MATHUS" a écrit :
> +1. Would be great.
> I was recently thinking about this when designing an enforcer rule about
> nam
+1. Would be great.
I was recently thinking about this when designing an enforcer rule about
naming & dependency rule. I want to define some simple config through XML,
but also considered being able to inject some kind of
DependencyNamingRulesStrategy by anyone who would not have enough with the
st
How does the wicket-style approach look like?
I think we should end up with something that allows to have:
* multiple implementations of the same interface, e.g. different test
filters, different test run listeners
* configurable extensions, e.g. configure details for the filters or run
listener
surefire (and quite a few other plugins) seem to be screaming for a
simple way to add user-defined extension points for easy ability to
modify/extend capabilities without forking the plugin or further
bloating it for yet more marginal use cases.
Conceptually I'm thinking somewhere along these line
