On Dec 10, 2011, at 9:47 AM, Benson Margulies wrote: > 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. >
When you decide, at least in a first pass, what you think is right then encode that in an IT and I'd be happy to take a look. > 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. I would start with what you think the behaviour should be if you think it's incorrect. A lot of what was done was to preserve existing behaviour to which my argument is you live with your baggage even if it's not the most elegant or strictly correct. > > 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'. Take a look at the MavenRepsoitorySystemSession and ArtifactHandler to see how the handling of particular types is dealt with. Many of the types that do the mapping are hard-coded as not to require changes in user POMs. You can make your own handlers and users just need to load the plugins with the right flag so they get into the core classloader. The maven-bundle-plugin does this for example: https://github.com/apache/felix/blob/trunk/bundleplugin/src/main/resources/META-INF/plexus/components.xml > > --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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
