Wow.. Now I wish I hadn't offered a fix ;)
Chad.. The main thing here (solely speaking from a user POV) is that
Maven is trying to enforce a 'standard' way of doing things. Remember
"Maven aims to make the developer's life easier by providing a well
defined project structure, well defined development processes to
follow."
Of course a standard way is supposed to be considerate of best practices
(well defined). Best practices would seem to dictate that you do not
have test classes along with application classes. If you are not going
to deploy it together then why confuse development by bundling it as
such?
As Jason said.. There are plenty of other tools out there than can
handle more of a hodpodge/adhoc style, but that is not the goal of
Maven.

Tim Chen
[EMAIL PROTECTED]


-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 08, 2003 11:01 PM
To: Maven Users List
Subject: Re: Is it possible to keep unit tests in the same directories
asproduction classes?


On Mon, 2003-12-08 at 22:12, Chad Woolley wrote:
> Hi,
> 
> Is there any particular reason for these vehement and draconian
> objections? :)

Yes, don't mix your concerns.

> What are the technical issues caused by this?

Trying to teach each test related plugin how to deal with what is a test
and what isn't is a major pain in the ass. The clover plugin for
example, trying to instruct it what to instrument and what not to. Why
bother? The answer is we don't both because we know the tests are in one
and the application code is in another. Makes things much easier.

>   I can understand how some
> plugins won't work, but this could be an acceptable price.  

No, it's not. Not to us anyway. Roll whatever you like with whatever you
like but Maven's isn't going to help you. You always have Ant if you
don't like what we're selling.

> I can
> understand that separate source trees is the "right" way, but does is 
> have to be the only way?

Here it does. There isn't a snowball's chance in hell that you'll ever
convince anyone where that allowing sources to exist in the same
directory as application code is a even a remotely good idea.

> In my particular case, I want to setup maven to illustrate it's 
> benefits
> to the rest of my team.  However, if I tell them I have to totally 
> reorganize the source tree before I can show off maven, I don't think 
> they are going to buy it.

Then they don't buy. Arguments like that will get you absolutely no
where here.

> It seems like it would be to maven's benefit to be as flexible as
> possible when people are migrating to it.  Otherwise, people may not 
> even want to go to the trouble of trying it...

Then they don't have to try it. If they don't see the benefit of the
separation of concerns then that's not our problem. This type of
discussion has come up over and over again and we're not likely to
budge. So if you don't like it then stick with your Ant build.

Really, if you're not flexible to and don't see the benefit then Maven
simply isn't the tool for your team. We're far from being the only show
in town. There are lots of choices out there.

> Thanks,
> Chad
> 
> Jason van Zyl wrote:
>   > Now I'm going to have add something that halts the build if any
> > derivatives of org.junit.Test* are found in the source directory
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational and
technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to