> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: mardi 3 janvier 2006 17:18 > To: [email protected] > Subject: working on and prioritizing dev issues > > Hi, > > Of late I think many issues are coming up on the lists and we're not > dealing with resolving them effectively because, as is natural, people > have different priorities or are generally just thinking about different > things that may be interesting or pressing. > > The three things of late I can think of is the development process > thread, the integration testing thread, and a discussion of best > practices which fell by the way side a month ago. So I intentionally > picked up Brett's start at codifying the dev process so that at least > two of us are on the same page and try and use that momentum to draw > other people into the discussion. I talked to a couple of subversion > developers (thanks to Garrett Rooney and Paul Querna), read Pragmatic > Version Control, talked to Jesse and Brett and found what useful links I > could find. I put it all together here: > > http://docs.codehaus.org/display/MAVEN/Development+Process
I'm all fine with that's in there. I had one comment that I have put as a todo in the document itself. It was about using some build number to uniquely identify any release (be it snapshot, rc, or final). > After this I think we should deal with the integration test issues, I'd love that :-) Right now I can think of 3 topics for discussion: 1/ Can we put the before-integration-test/after-integration-test phases in 2.0.2. I think you agreed and I think Brett also said that he was in agreement some time back. Who's the release manager for 2.0.2? Brett? So I guess it should be him adding to the the 2.0.2 branch if we follow the new dev process. 2/ I have some interesting use case in Cargo land for it tests. Basically I want the Cargo m2 plugin to generate some default container configuration (cargo:configure), allow users to modify it with any tool/plugin they want (for example by copying some custom jar files, by running the regexpreplace Ant task, execute their own plugin, etc), then run cargo:start to start the container, let the user choose what test plugin they want to run the tests (be it surefire, testng or whatever) and then call cargo:stop to stop the container. With the before-it and after-it phases I can do some of this: Before-it: execute cargo:configure Before-it: I need to execute the user's custom actions here. The user could use an execution bound to the same phase provided that it's located below the cargo:configure config Before-it: execute the cargo:start goal. How do I do this? Does it work to define a second time a config snippet for the cargo plugin to do this? However it won't be optimal as the 2 config snippets won't be able to share config and there's quite some redundancy. I can think of 2 solutions: - have m2 support a more flexible goal binding definition for users - modify the cargo plugin to circumvent the problem but I'm not sure how to best do this seen that I can't know all the different tools the user may use for both modifying the configuration and what test runner they'll use. WDYT? 3/ Ability to execute both unit tests and integration tests in the same run, both by the surefire plugin (see my other threar entitled "[discussion] Integration testing location"). 4/ Decide whether we need a functional-test phase or not. And again the question as to whether the surefire plugin could optionally be used for running those tests. [snip] Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
