On Sat, Dec 10, 2011 at 9:03 AM, Jason van Zyl <ja...@tesla.io> wrote: > > On Dec 10, 2011, at 8:24 AM, Benson Margulies wrote: > >> However, in 3043, the consumer leaves out the classifier from the >> dependency specification. Is anyone willing to explain why that bit of >> relaxation was considered a good idea? My inclination would be to >> change the test to specify the classifier. >> > > If it's an IT that has been in place for a while then please leave it. > Changing existing tests that express behaviour in the field is a very bad > idea. Make a new one, and if it needs to express a different behavior because > we feel it's wrong then assert that in the range of versions under which that > particular test runs. Changing tests to match behaviour, once established to > monitor behaviour, undermines the purpose of the tests. Cut/paste is cheap, > and you probably have no idea who might be relying on behavior expressed in > the form the test is in now even though the change you suggest may appear > simple and not much have impact. Once an IT has been created and been used to > vet a version of Maven that has shipped that IT should not be changed.
Jason, As it turns out, I left the test alone. I didn't need to tighten the classifier match to fix my original problem, since the very specific issue behind MNG-5214 involves no classifiers. I have yet to write a new IT that comprehensively investigates all the 'no I don't want it to match' cases to balance these test that are all testing for 'yes it does match'. Your suggestion about version ranges, in the event that the behavior does change beyond the tolerance of these tests, is helpful. It would be even more helpful if you and Benjamin would comment on the substantive issue at hand. In writing a new IT, I need to decide what to declare as correct behavior when a dependency names a classifier and the reactor has some other classifier (or the null classifier) of the same artifact. ReactorReader has special cases that know that some type values are the 'same kind of thing' and some aren't, and some type values should be considered equivalent to target/classes or target/test-classes, and some shouldn't. I understand the reasoning behind treating the jar-ish types as equivalent, but I don't understand how it's a good idea to spare some people from typing accurate classifiers and at the same time subject other people to incorrect results as a side-effect. Your names are on the @authors and the JIRA comments. Did you have any particular plan in mind for a longer-term, structural fix to all this? I was thinking of an extension point to allow a lifecycle plugin to explicitly announce that a type was of the same species as 'jar' or 'test-jar'. --benson > >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > What matters is not ideas, but the people who have them. Good people can fix > bad ideas, but good ideas can't save bad people. > > -- Paul Graham > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
