On Feb 10, 2014, at 7:07 PM, Hervé BOUTEMY <[email protected]> wrote:
> I understand the value of core ITs and fear about such changes > I both think such a change has a value to keep existing ITs written a long > time ago easier for newcomers to understand > > But yes, I see my update wasn't careful enough > It's not that it wasn't careful, there's always little glitches when working with the ITs. That's not really a big deal, stuff happens. It's more that it's not necessary or generally desired to change an IT or its surrounding support code. You stand to gain very little for changing a body of tests which has remained very constant over time. It's going to be one of us looking at something if it fails and it's not like it's hard for us to figure out. I don't think this particular change is going to make it easier to decipher a problem. > In the next days, I'll check that generated plugin.xml is exactly the same > before and after the change, and report > If I can't get precise comparison (or of course get some diffs), I'll revert > my > commit, since stability is the major concern > > Please let me a few days, and eventually ping me back if I don't report > > Regards, > > Hervé > > Le dimanche 9 février 2014 21:21:38 Jason van Zyl a écrit : >> On Feb 9, 2014, at 2:45 PM, Hervé BOUTEMY <[email protected]> wrote: >>> I ran the ITs before comitting, it was ok >>> I'm running them once again on my machine, to check if something is now >>> failing >>> >>> ITs need maintenance like every piece of code, old "expression" field of >>> plugin-tools is now part of past and is every day harder to understand >> >> For external, consumer facing projects I would agree. But the purpose of the >> ITs is stability and multiple points of variation doesn't help with this. >> The ITs should remain immutable or they can cause issues like we see today >> where an IT working against released versions functions correctly for years >> and then all of a sudden doesn't work. If you want to use new versions of >> tools for newer ITs, I think having a diversity of versions is fine in the >> ITs but when an IT is created it should remain the way it is when it's >> created. >> >> I don't agree with this change and I think it potentially destabilizes the >> most valuable resource we have for testing stability, but if you don't see >> this as an issue then I leave it to you to decide. >>> Regards, >>> >>> Hervé >>> >>> Le dimanche 9 février 2014 14:05:20 Jason van Zyl a écrit : >>>> Hervé, >>>> >>>> The following IT fails after your changes: >>>> >>>> Tests run: 732, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 450.697 >>>> sec <<< FAILURE! >>>> testit0064(org.apache.maven.it.MavenIT0064MojoConfigViaSettersTest) Time >>>> elapsed: 0.547 sec <<< FAILURE! junit.framework.AssertionFailedError: >>>> Expected file was not found: >>>> /Users/jvanzyl/js/tesla/maven-integration-testing/core-it-suite/target/te >>>> st >>>> -classes/it0064/target/fooValue at >>>> junit.framework.Assert.fail(Assert.java:47) >>>> >>>> at org.apache.maven.it.Verifier.assertFilePresent(Verifier.java:1014) >>>> at >>>> >>>> org.apache.maven.it.MavenIT0064MojoConfigViaSettersTest.testit0064(MavenI >>>> T0 >>>> 064MojoConfigViaSettersTest.java:51) >>>> >>>> Do you get the same? >>>> >>>> Why did you change so many plugins in the ITs? They are supposed the be a >>>> (mostly) immutable set of tests and not a body of code that should be >>>> updated just because there are new versions. They should remain constant >>>> over time, which they have been up until now. >>>> >>>> I don't think it's particularly useful and when we get a failure like >>>> this >>>> now it's really hard to tell, with multiple points of variation, whether >>>> it's a change in Maven itself or a change in the ITs >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder, Apache Maven >>>> http://twitter.com/jvanzyl >>>> http://twitter.com/takari_io >>>> --------------------------------------------------------- >>>> >>>> We all have problems. How we deal with them is a measure of our worth. >>>> >>>> -- Unknown >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> To do two things at once is to do neither. >> >> -- Publilius Syrus, Roman slave, first century B.C. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
