You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jason van Zyl <ja...@zenplex.com> on 2003/07/13 14:49:09 UTC
Re: Keeping your test source code in a separate, but
parallelsource tree
On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
> > Never going to happen and I make no apologies for that.
> It's nice to see that you take user input so graciously
Give me a break.
When I think something is categorically a bad practice then the dialog
is cut short. I am not trying to win any popularity contests and I'm
don't care if every single user is happy. It's just not possible. But I
have taken loads of suggestions for Maven and they have found there way
into Maven. But there are several issues like multiple sources
directories, mixing test and application code and several other issues
which I will not change my mind on.
Maven is but one solution for building your project. I encourage anyone
not happy with it to go find something else.
I also take into consideration the number of downloads in constrast with
the number of people who complain about certain limitations. I certainly
don't think mixing test/application code is a good idea but I think
given that I've only seen a few people want this out of the thousands
that have downloaded Maven is a good indicator that most users think
it's not a very good idea. I'm not a politician, I could care less if
all users like me because most users are selfish and only consider their
own methods and own desires when requesting features while generally
never considering larger issues. As always there are the valued and
treasured exceptions by users who have genuinely taken into
consideration all users and the larger issues. Just because a user makes
a suggestion doesn't mean it's a good one. If you're looking for grace
go somewhere else.
>
> ---------------------------------
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
--
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: Keeping your test source code in a separate,but parallelsource tree
Posted by Dave Ford <df...@smart-soft.com>.
> 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
---------------------------------------------------------------------
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
Posted by Jason van Zyl <ja...@zenplex.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 total downloads against any discussion" is
> a very poor and biased measure of user needs/requirements.
One data point used along side many others, it's certainly not my
guiding light.
> If you go
> around cutting discussions short, then your biasing such a measure in
> favor of your own personal opinion
Of course I am biasing some decisions on my own personal opinion, isn't
that obvious? Who creating a piece of software, being intimately
involved from day one doesn't transfer some personal opinions into the
software?
> and as such it does not reflect the
> true opinion of your userbase.
There have been many user opinions I don't care to reflect. I've been
involved in many open source projects and it is a rare day indeed when a
user actually contributes something other than complaints. When users
phrase things like "I think Maven should make this an option ... "
really means "I can't do things the way I've always been doing them so
Maven should support my way of doing it". And that particular user
doesn't really give a shit about other users and is certainly not
thinking about what it means to have an infinite level of variability.
When users come along and go "Oh #$!&!&! Maven, why can't I do this X"
then they are forced to ask why Maven doesn't allow something if they
wish to continue using Maven. For the most part I'm the biggest hard ass
and generally unrelenting. I've even wanted to go so far as not even
letting the source directory be configurable but I do listen and it's
configurable. I'm not trying fuck every user by not letting them do
everything they want. I truly and honestly believe that in the long run
it will be better to sacrifice some variability for a standard, even if
some of the standard is ad hoc. Some consistency across the board in the
build system so people can stop farting around with this mundane shit
and allow ideas to flourish in great applications.
This approach has proven immensely distasteful to people with existing
builds, lots of people hate Maven for that reason. But I think almost
anyone building apps doesn't want to waste their time on this boring
shit. If there was a way to build java projects in a consistent way,
produce some standard artifacts and doco I probably never would have
started this thing. If there was something that allowed this I probably
could have lived with what I thought were a few inconveniences where I
disagreed with some usage pattern in order not to ever have to look at a
build again. I think the vast majority of users are the same.
> -Mark Diggory
> http://jakarta.apache.org/commons/sandbox/math/index.html
>
> Jason van Zyl wrote:
> > On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
> >
> >>>Never going to happen and I make no apologies for that.
> >>
> >>It's nice to see that you take user input so graciously
> >
> >
> > Give me a break.
> >
> > When I think something is categorically a bad practice then the dialog
> > is cut short. I am not trying to win any popularity contests and I'm
> > don't care if every single user is happy. It's just not possible. But I
> > have taken loads of suggestions for Maven and they have found there way
> > into Maven. But there are several issues like multiple sources
> > directories, mixing test and application code and several other issues
> > which I will not change my mind on.
> >
> > Maven is but one solution for building your project. I encourage anyone
> > not happy with it to go find something else.
> >
> > I also take into consideration the number of downloads in constrast with
> > the number of people who complain about certain limitations. I certainly
> > don't think mixing test/application code is a good idea but I think
> > given that I've only seen a few people want this out of the thousands
> > that have downloaded Maven is a good indicator that most users think
> > it's not a very good idea. I'm not a politician, I could care less if
> > all users like me because most users are selfish and only consider their
> > own methods and own desires when requesting features while generally
> > never considering larger issues. As always there are the valued and
> > treasured exceptions by users who have genuinely taken into
> > consideration all users and the larger issues. Just because a user makes
> > a suggestion doesn't mean it's a good one. If you're looking for grace
> > go somewhere else.
> >
> >
> >>---------------------------------
> >>Do you Yahoo!?
> >>SBC Yahoo! DSL - Now only $29.95 per month!
>
>
> ---------------------------------------------------------------------
> 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
Re: Keeping your test source code in a separate, but parallelsource
tree
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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 total downloads against any discussion" is
a very poor and biased measure of user needs/requirements. If you go
around cutting discussions short, then your biasing such a measure in
favor of your own personal opinion and as such it does not reflect the
true opinion of your userbase.
-Mark Diggory
http://jakarta.apache.org/commons/sandbox/math/index.html
Jason van Zyl wrote:
> On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
>
>>>Never going to happen and I make no apologies for that.
>>
>>It's nice to see that you take user input so graciously
>
>
> Give me a break.
>
> When I think something is categorically a bad practice then the dialog
> is cut short. I am not trying to win any popularity contests and I'm
> don't care if every single user is happy. It's just not possible. But I
> have taken loads of suggestions for Maven and they have found there way
> into Maven. But there are several issues like multiple sources
> directories, mixing test and application code and several other issues
> which I will not change my mind on.
>
> Maven is but one solution for building your project. I encourage anyone
> not happy with it to go find something else.
>
> I also take into consideration the number of downloads in constrast with
> the number of people who complain about certain limitations. I certainly
> don't think mixing test/application code is a good idea but I think
> given that I've only seen a few people want this out of the thousands
> that have downloaded Maven is a good indicator that most users think
> it's not a very good idea. I'm not a politician, I could care less if
> all users like me because most users are selfish and only consider their
> own methods and own desires when requesting features while generally
> never considering larger issues. As always there are the valued and
> treasured exceptions by users who have genuinely taken into
> consideration all users and the larger issues. Just because a user makes
> a suggestion doesn't mean it's a good one. If you're looking for grace
> go somewhere else.
>
>
>>---------------------------------
>>Do you Yahoo!?
>>SBC Yahoo! DSL - Now only $29.95 per month!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Undocumented properties
Posted by 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
Posted by 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 ...)
Posted by 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 ...)
Posted by "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
Posted by "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
Re: Keeping your test source code in a separate,
but parallelsource tree
Posted by 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: Keeping your test source code in a separate, but parallelsource
tree
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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. Forcing them into a box will only reduce your user base in
the long run. The current defaults are great if your starting a new
project, they are far from adequate when attempting to "Mavenize" an
existing project. The Maven team should avoid using "defaults" as some
sort of inflexible "standard".
Note: Much of this argument could be easily avoided if the core maven
properties and capabilities were clearly documented somewhere. Somehow
this documentation is lacking as "maven" itself is not in the pluggins
documentation and such properties are documented nowhere.
-Mark Diggory
Gilles Dodinet wrote:
> Dave, brendan,
>
> Just a quick note about this. it seems that maven actually does allow to
> keep all main and test sources under one dir .
> just make sourceDirectory and unitTestSourceDirectory point to the same
> dir, then your test will be run.
> About the artifact generation, when building jar, you just can exclude
> your test files files using ${maven.jar.excludes}.
> ive just tried it with a dummy example and it seems to work.
>
> its not that im using this layout (i have parallel source trees), so it
> might eventually require additional efforts for other artifacts generation.
>
> So i think that maven doesnot strictly forbids the all-in-one-dir
> practice, it s more that it just discourages it. tho perhaps im missing
> something.
>
> -- gd
>
>
> Jason van Zyl wrote:
>
>> On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
>>
>>
>>>> Never going to happen and I make no apologies for that.
>>>>
>>>
>>> It's nice to see that you take user input so graciously
>>>
>>
>>
>> Give me a break.
>>
>> When I think something is categorically a bad practice then the dialog
>> is cut short. I am not trying to win any popularity contests and I'm
>> don't care if every single user is happy. It's just not possible. But I
>> have taken loads of suggestions for Maven and they have found there way
>> into Maven. But there are several issues like multiple sources
>> directories, mixing test and application code and several other issues
>> which I will not change my mind on.
>> Maven is but one solution for building your project. I encourage anyone
>> not happy with it to go find something else.
>> I also take into consideration the number of downloads in constrast with
>> the number of people who complain about certain limitations. I certainly
>> don't think mixing test/application code is a good idea but I think
>> given that I've only seen a few people want this out of the thousands
>> that have downloaded Maven is a good indicator that most users think
>> it's not a very good idea. I'm not a politician, I could care less if
>> all users like me because most users are selfish and only consider their
>> own methods and own desires when requesting features while generally
>> never considering larger issues. As always there are the valued and
>> treasured exceptions by users who have genuinely taken into
>> consideration all users and the larger issues. Just because a user makes
>> a suggestion doesn't mean it's a good one. If you're looking for grace
>> go somewhere else.
>>
>>
>>
>>> ---------------------------------
>>> Do you Yahoo!?
>>> SBC Yahoo! DSL - Now only $29.95 per month!
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
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
Posted by Gilles Dodinet <rh...@wanadoo.fr>.
Dave, brendan,
Just a quick note about this. it seems that maven actually does allow to
keep all main and test sources under one dir .
just make sourceDirectory and unitTestSourceDirectory point to the same
dir, then your test will be run.
About the artifact generation, when building jar, you just can exclude
your test files files using ${maven.jar.excludes}.
ive just tried it with a dummy example and it seems to work.
its not that im using this layout (i have parallel source trees), so it
might eventually require additional efforts for other artifacts generation.
So i think that maven doesnot strictly forbids the all-in-one-dir
practice, it s more that it just discourages it. tho perhaps im missing
something.
-- gd
Jason van Zyl wrote:
>On Sat, 2003-07-12 at 20:14, Bob Cumbers wrote:
>
>
>>>Never going to happen and I make no apologies for that.
>>>
>>>
>>It's nice to see that you take user input so graciously
>>
>>
>
>Give me a break.
>
>When I think something is categorically a bad practice then the dialog
>is cut short. I am not trying to win any popularity contests and I'm
>don't care if every single user is happy. It's just not possible. But I
>have taken loads of suggestions for Maven and they have found there way
>into Maven. But there are several issues like multiple sources
>directories, mixing test and application code and several other issues
>which I will not change my mind on.
>
>Maven is but one solution for building your project. I encourage anyone
>not happy with it to go find something else.
>
>I also take into consideration the number of downloads in constrast with
>the number of people who complain about certain limitations. I certainly
>don't think mixing test/application code is a good idea but I think
>given that I've only seen a few people want this out of the thousands
>that have downloaded Maven is a good indicator that most users think
>it's not a very good idea. I'm not a politician, I could care less if
>all users like me because most users are selfish and only consider their
>own methods and own desires when requesting features while generally
>never considering larger issues. As always there are the valued and
>treasured exceptions by users who have genuinely taken into
>consideration all users and the larger issues. Just because a user makes
>a suggestion doesn't mean it's a good one. If you're looking for grace
>go somewhere else.
>
>
>
>>---------------------------------
>>Do you Yahoo!?
>>SBC Yahoo! DSL - Now only $29.95 per month!
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org