> in the long run
> it will be better to sacrifice some
> variability for a standard, even if
> some of the standard is ad hoc.
That's a good point Jason.
Dave Ford
Smart Soft - The Developer Training Company
http://www.smart-soft.com
-
On Sun, 2003-07-13 at 15:00, Mark R. Diggory wrote:
> This is all but one opinion on the subject. IMHO, as this is a user list
> and not a developer list, I'd advise that moderation should not be so
> restrictive when the subject matter is not at all off topic.
>
> I also think that "comparing t
On Sun, 2003-07-13 at 14:43, Mark R. Diggory wrote:
> Thanks Gilles,
>
> Its good to know that this is configurable, I'm working on another
> project where we're trying to get Maven working but cannot yet
> restructure the cvs to meet "assumed Maven best practices" without
> breaking the old bu
> Never going to happen and I make no apologies for that.
It's nice to see that you take user input so graciously
-
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
On Sat, 2003-07-12 at 14:43, Bill Lynch wrote:
> I agree - I prefer to manage 2 separate directories and I think it's easier to
> understand projects if they're structured that way. But, I do think you're right
> - it'd be great if Maven could handle either approach.
Well, I don't think it woul
On Sat, 2003-07-12 at 20:02, Dave Ford wrote:
> So, back to my question. Why is this a best practice?
It's what we have chosen for reasons I mentioned in my previous email
and we've embodied those choices in the test plugin.
> Maybe it's a common
> practices, possibly a standard practiced, but
On Sat, 2003-07-12 at 13:57, Brendan Lawlor wrote:
> I do exactly as Dave Ford does - I keep my unit test classes in the same
> packages as the production code under test. I find it good for the same
> reasons as Dave outlines, and separating them at delivery time using ant
> in a fileset is very
On Sat, 2003-07-12 at 12:20, Dave Ford wrote:
> The Maven web site lists "Keeping your test source code in a separate, but
> parallel source tree" as best practices.
>
> Q1: Why is this a best practice? It just seems like an extra thing to
> maintain to me, making package name refactoring for trou
