On 3/31/02 1:56 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
> on 3/31/02 10:27 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > >> Why didn't you leave the defaults in place in there? Makes it much easier >> to read... > > I have been through this a bazillion times now on other lists... > > Essentially, I equate a build.xml to a ./configure. You wouldn't expect > someone to cat/more/edit/pico/emacs a ./configure script in order to figure > out the defaults, now would you? Why would you expect anyone to look inside > a build.xml? With a ./configure, people will ./configure --help to figure > out the defaults. > > If you want to print the defaults, then we should have a <target> that > prints out the defaults in a nice format from the default.properties. Just > like ./configure --help. I equate build.xml to be a smart make file, which is complete. Now, it's not complete because the damn defaults are in another file. It think that it's good to have the default.properties to its easy for a user to copy that to their own build.properties, but the build.xml should be complete. The point is that when reading or modifying, you have no clue what the defaults are because they are in a different file. I can't search for anything - I need to have the other file also in the editor and switch back and forth. Not a major problem, of course, but I can't see the downside to having the build.xml self contained and complete, extensible via the build.properties file specified by the user if desired. > > Also, to you they are easier to read in the build.xml...to me, they aren't. > To me, it is easier to read in the default.properties...to someone else, it > may be another way... Are you kidding? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting My inner cowboy needs to yodel. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
