On Thu, 2003-12-11 at 16:21, Lester Ward wrote: > > Ok, in your opinion what would be the advantage of making these things > > above configurable? Do you really care that much if all classes are > > output to target/ ? > > It is sometimes useful to have classes be output outside the project > directory. This is more useful with docs than code, but I used to build > directly into JBoss's deploy folder when debugging. This was much faster > than doing a full deploy every time something changed, so helped debugging > immensely. Naturally, I'd never do that on a build machine, just a dev box. > (As far as docs go, our CruiseControl build process updates all of our > products and overrides the build target for the docs to the main web server > directory on the machine. We do this rather than use all the web deploy > stuff, which I find irritating, buggy and slow.)
Fair enough, development ease is certainly a valid use case but I honestly see this as a limitation of the tools being used that aren't flexible enough themselves to deal with different locations i.e. a development mode and deployment mode. I debug all my applications reloading classes, velocity templates and such and in most cases I can get away with it in situ by changing some configurations. Classworlds deals with arbitrary locations for classes/jars and for Velocity it's simply a matter at pointing the resource loader in a different location. I find this much safer than pushing the classes off to another location. > It also is extremely useful when forced to integrate your project with > project that is not Mavenized. Not all projects have the luxury of full > control over all of the code they use. At one point, for example, we were > using Jetspeed which used Ant for builds (though it has since been > Mavenized) and for various reasons it was easier to override our project's > build target. Sure, we probably .could. have done it differently, but speed > mattered to us more than beauty at that point. I realize this is a concern now but for me it's a balance between limiting options and making everything possible. It is not necessary to provide myriad options in order to make everything possible. I honestly think in a lot of cases providing too many options is harmful. > Next, one of Maven's strengths is its configurability. Interesting to hear a different perspective, that was certainly never one of the comments I was ever trying illicit or a facet of Maven I tried to promote. > In spite of the fact > that there are some strongly followed conventions in Maven (e.g. "one > project, one artifact"), Maven manages (mostly) to avoid the stigma of being > a One True Way cult that drives people away by virtue of the fact that you > can deviate from the One True Way any time you like. I think some already see Maven as that but no one here is particularly miffed. I've told people to find and use whatever suits their project best. > When I first started > using Maven, I read the description of the recommended project structure. If > I hadn't seen a phrase to the effect of "of course, you can override any of > these paths if you like", I probably would never have started using Maven at > all, even though at the time I would not have been able to justify why I > would want to change them. I would honestly like to do a little survey of use (which will be to a large extend possible with deployed POMs) and I would imagine that most people don't deviate much from the defaults. > Being able to configure everything except the > build directory would severely weaken Maven in probably functional ways and > definitely reputational ways. I truly and honestly doubt that. I think people love not having to think about it for the most part and as tools crop up that take advantage of the way Maven works you will see even less people deviating from the defaults. > Lastly, it is very unclear to me what forcing /target buys you. Consistency which lends itself to comprehension and allowing developers to navigate any project after seeing one Maven project. I would wager for the most part when people download a project using Maven and build they first look in the target/ directory for the results. That's a very good thing, and far out weighs what configurability gets you. It also would make tool developers think about why there is only one location and would force them to make adaptable tools. To me it makes more sense to standardize the build which has an impact on far more people and nudge tools and frameworks to be flexible in how they approach resources. > Worse, it is > even less clear what forcing /target buys _me_. That's because most users often only think about what they want which is entirely natural and how we get use cases. In your particular case it obviously doesn't buy you anything. But that's why we look at all our users and to me the primary motivation is ease of use and comprehension. The less users have to think about with respect to the build the better. > Wordman > > --------------------------------------------------------------------- > 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]
