Yes.
Unfortunately the use of ${maven.build.dir} was not adopted by all parties else this
discussion would have been moot.
The source of our discomfort are the odors eminating from the use of hard-coded
directory names like "src" and "target"
in some templates and jelly scripts.
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 2:40 PM
To: Maven Users List
Subject: RE: How set maven.build.dest in project.xml ?
On Fri, 2003-12-12 at 17:00, W. Sean Hennessy wrote:
> A point of order..
> "currently flexible property with a rigid standard"
> is not entirely accurate.
> "target/" is not a property, it is hard coded.
> The discussion is about changing this hard coded directory name to a
> property like ${target-dir-nm}.
It's already ${maven.build.dir} it's just that many people use the hard-coded target/.
>
> -----Original Message-----
> From: Lester Ward [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 12, 2003 12:38 PM
> To: 'Maven Users List'
> Subject: RE: How set maven.build.dest in project.xml ?
>
>
> > Your analysis is simply erroneous. We don't make changes arbitrarily
> > for the sake of making changes or to cause users long-term grief. So
> > far I think I've done all right in OSS using similiar practices that
> > I employ for Maven.
>
> I agree. Maven is a wonderful piece of technology.
>
> > Velocity, Apache XmlRpc, OJB, BCEL are all and
> > haven't fallen prey to disuse yet.
>
> Nor has Maven. Sorry if I gave the impression that I thought it had.
> My point was only that I've seen projects disintegrate when they began
> to insist that the rest of the world conform to them _unnecessarily_.
>
> I think the basic issue I (and, I think, some of the other posters)
> have is that they don't see why fixing the target directory in place
> is _necessary_. What benefit does it provide to fix it in place? Why
> is that benefit worth more than the flexibility of the current system?
>
> > Again, I believe you are wrong and that given the benefits users
> > derive from Maven they will eventually start asking makers of tools
> > to accommodate Maven's methods of development.
>
> Some will. Some won't. That will cause pain (if Maven becomes less
> flexible) for those who want to use the systems that won't conform. My
> experience is that open source developers tend not to have to deal
> with such pain, so are overly unsympathetic towards it. I can agree to
> disagree here, though.
>
> > I don't feel compelled to defend my philosophy because it manifests
> > itself in Maven and you're obviously using it so you must already
> > agree to some extent. And I can see that you care because you're
> > arguing with me which I take as a compliment.
>
> I do care. The reason I am posting is that you appear to be on the
> verge of changing the philosophy used in Maven (i.e. replacing a
> currently flexible property with a rigid standard).
>
> Wordman
>
> ---------------------------------------------------------------------
> 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]
--
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]
