Re: Keeping your test source code in a separate, but parallelsource tree

[Jason van Zyl <ja...@zenplex.com>]

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 build.
> 
> I'd caution on the use of default settings as a "rule" for what Maven 
> encourages/discourages. Developers are always going to have varying 
> requirements. 

That will always be true but why do we as developers demand consistent
APIs for everything we use and then ignore this rule when constructing
build systems? What is good about having N different ways a build system
works? And if you disagree you have plenty of tools to choose from.

> Forcing them into a box will only reduce your user base in 
> the long run. 

Much to my dismay this has not been the case. And the target for me has
always been newer users because anyone with an existing build has always
tried to demand to have their way incorporated as an option in Maven. It
has always been the intent to strive for consistency and coherence,
sometimes at the cost of other things. That was a conscious decision.

> The current defaults are great if your starting a new 
> project, they are far from adequate when attempting to "Mavenize" an 
> existing project. 

There has never been an attempt to accommodate the myriad ways of doing
things. Maven is not Ant. 

> The Maven team should avoid using "defaults" as some 
> sort of inflexible "standard".

The whole point of Maven is to provide some uniformity and coherence
from the ground up. Lots of people don't like the way Maven works and
that's perfectly fine.

> -- 
> jvz.
> 
> Jason van Zyl
> jason@zenplex.com
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Undocumented properties

[di...@multitask.com.au]

Maybe someone could integrate this into the Maven user's guide.

--
dIon Gillard, Multitask Consulting
Blog:      http://blogs.codehaus.org/people/dion/
Work:      http://www.multitask.com.au


Ben Walding <be...@walding.com> wrote on 15/07/2003 12:35:12 AM:

> 
> >>This actually flows back to an earlier discussion about documentation 
> >>and the werkz plugin.
> >> 
> >>
> >
> >I post some quicky docs to the list regarding Werkz and Ben challenged
> >the user to make an xdoc of it. It's in the archive if you want to
> >document it.
> >
> > 
> >
> >>http://www.mail-archive.com/users@maven.apache.org/msg00751.html
> >> 
> >>
> 
> Surprisingly, they rose to the challenge!
> 
> http://wiki.codehaus.org/maven/WerkzTagDocumentation
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

Re: Undocumented properties

[Ben Walding <be...@walding.com>]

>>This actually flows back to an earlier discussion about documentation 
>>and the werkz plugin.
>>    
>>
>
>I post some quicky docs to the list regarding Werkz and Ben challenged
>the user to make an xdoc of it. It's in the archive if you want to
>document it.
>
>  
>
>>http://www.mail-archive.com/users@maven.apache.org/msg00751.html
>>    
>>

Surprisingly, they rose to the challenge!

http://wiki.codehaus.org/maven/WerkzTagDocumentation



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Undocumented properties (was: Re: Keeping your test source code ...)

[Jason van Zyl <ja...@zenplex.com>]

On Sun, 2003-07-13 at 22:07, Mark R. Diggory wrote:
> Sorry, I made it sound like I was poking holes in the project in that 
> last thread, while in reality, I really appreciate Maven as a tool and 
> use it regularly.

Fear not, I have a very, very thick skin :-)

> I want to clarify that I understand that there are project.xml elements 
> that can be set ( unitTestSourceDirectory, 
> integrationUnitTestSourceDirectory, ...). And, these elements as well as 
> all the plug properties are well documented. I didn't want to make it 
> seem that there was a "lack of documentation" for Maven, there certainly 
> is alot of documentation going around.

The documentation is still lacking and that is for the most part my
doing. I do much of it in bursts when I get the time.

> My primary question is if there are undocumented properties that can be 
> set in project.properties or used in maven.xml that are not actually 
> defined by the plugins, but actually by the base architecture of Maven 
> itself? Like for instance properties used by werkz plugin or maven 
> plugin base?

Most of the base properties are in driver/default.properties. Some of
those actually belong in their respective plugins which I have done in
the refactoring I have which will be shoved into CVS soon.

> This actually flows back to an earlier discussion about documentation 
> and the werkz plugin.

I post some quicky docs to the list regarding Werkz and Ben challenged
the user to make an xdoc of it. It's in the archive if you want to
document it.

> http://www.mail-archive.com/users@maven.apache.org/msg00751.html
> 
> thanks,
> Mark
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Undocumented properties (was: Re: Keeping your test source code ...)

["Mark R. Diggory" <md...@latte.harvard.edu>]

Sorry, I made it sound like I was poking holes in the project in that 
last thread, while in reality, I really appreciate Maven as a tool and 
use it regularly.

I want to clarify that I understand that there are project.xml elements 
that can be set ( unitTestSourceDirectory, 
integrationUnitTestSourceDirectory, ...). And, these elements as well as 
all the plug properties are well documented. I didn't want to make it 
seem that there was a "lack of documentation" for Maven, there certainly 
is alot of documentation going around.

My primary question is if there are undocumented properties that can be 
set in project.properties or used in maven.xml that are not actually 
defined by the plugins, but actually by the base architecture of Maven 
itself? Like for instance properties used by werkz plugin or maven 
plugin base?

This actually flows back to an earlier discussion about documentation 
and the werkz plugin.
http://www.mail-archive.com/users@maven.apache.org/msg00751.html

thanks,
Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Keeping your test source code in a separate, but parallelsource tree

["Mark R. Diggory" <md...@latte.harvard.edu>]

Hmm, I think we need to remember here that Apache Projects are actually 
owned by the community at large. If someone wanted Maven to do something 
more, and a consensus of the developer community liked it enough to vote 
them in, then Maven would develop in the direction of those capabilities 
(look at the long term development of Tomcat and this process can 
clearly be seen). Individual opinion of the current developers factors 
into its path of growth, but only through the process of lazy consensus. 
Unfortunately, the smaller the group is, the less democratic and more 
dictatorial this process becomes.

I really just think the real here argument boils down to documentation. 
If there are configurable properties in Maven that are currently hidden 
from the user because of a lack of documentation, then this argument is 
pretty "moot" because the capabilities are already there. You can 
designate the location of your test directory, as such, the rule is that 
you can, the default is where the majority of the Maven development team 
would like to see it (especially when its undocumented).

Jason van Zyl wrote:
> There has never been an attempt to accommodate the myriad ways of doing
> things. Maven is not Ant. 

Yes, but Jelly is far more flexible a scripting env. than Ant. This 
makes Maven far more flexible, there will always be a myriad ways of 
doing things because you've based Maven on a Scripting platform which 
promotes "myriadity".

-Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org