Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant Main.java Project.java

[Ken Wood <kw...@i2.com>]

On a related note, while I'm thrilled to see more and
more people using Ant, I'm worried that we keep
adding subtle variations of the same thing just
to meet a specific need. Look at the number
of variations of "available" that have been proposed
in recent weeks, or the variety of logger issues, as
just two examples.

Or, someone submits a patch to add functionality that
is already there, they just didn't know it.

I believe the committers are doing a good job of
screening out duplicate work, but I still fear that
if we, as a group, aren't careful, we'll end up
with a 10,000 lb gorilla that can do the same thing
30 different ways, but can do anything well or
efficiently. Ant started out as a lean, mean, building
machine, and I hope we keep it that way rather than
burdening it with every subtle variation under the
sun. Some things belong IN ant, and some things belong
in the surrounding infrastructure in which ant is used.
We have to be careful to keep the line between the two
clean.

Well, enough soap box....

Diane Holt wrote:
> 
> --- Conor MacNeill <co...@m64.com> wrote:
> > I'm not that keen on this change. I prefer things to be explicit and not
> > to go implicitly wandering up the filesystem trying to find a build
> > file.
> 
> I agree. (I'm not a voter, tho, just a user.) I can already run 'ant' from
> anywhere in my source-tree and have it do the right thing -- my
> wrapper-script just 'cd's to the root of the current workspace (as defined
> in the user environment) before the java call to ant.
> 
> Diane
> 
> =====
> (holtdl@yahoo.com)
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/

Get emacs to find the correct build.xml and automatically pass it to ant.

[Barrie Treloar <Ba...@camtech.com.au>]

On 20 Sep 2000, Stefan Bodewig wrote:

> It is useful for a lot of people I know - those using (X)Emacs/JDE can
> now simply say "build using make" and set the make command to ant and
> it will always pick up build.xml without the need to explicitly
> specify the -buildfile switch, for example.

To do this with Emacs/JDE do the following:

(I'll add this to FAQ when its working :)

        Customize jde-build-use-make and set it to true.
        [This makes jde use make instead of its own internal builder]

        Customize jde-read-make-args and set it to true.
        [This makes jde prompt you for the arguments to give to make.
        You can just hit return if you dont want to pass any arguments
        (the common case), otherwise you can include the target you
        want invoked.  Dont specify the build file to use, we will do
        this another way]

        Customize jde-make-program and set it to "ant".
        [This makes jde use "ant" instead of "make" as the build program]

        To your .emacs files add the following, this causes jde to try
        and load a prj.el file whenever you open a .java file.  This
        allows us to do some black magic a bit later.
            ;;
            ;; JDE mode
            ;;
            (require 'jde)
                     (add-hook 'jde-mode-hook 
                               '(lambda ()
                                        (jde-load-project-file)
                     ))

        For each project hierarchy create a prj.el file at the top
        level.  JDE will search the directory hierarchy to find the
        prj.el file and use the first one it finds.  For example, if
        you are in <TOP>/src/org/apache/tools/ant/ and you load
        Main.java and the file <TOP>/prj.el exists it will load it.
        The prj.el file will customize the jde-make-args to include
        the correct build file based on the java file that was
        loaded.

        The prj.el file should contain the following lisp code:

;;;
;;; BEGIN prj.el
;;;

;;
;; This file is loaded by JDE-mode via JDE->Project->Project File->Load.
;; The only value that requires changing is the jde-make-args variable
;;
;; Notes:  It is important to use make-local-variable as this allows
;; each buffer to have its own version of the build.xml file.
;; Therefore two source files from two different projects will
;; correctly use the write build.xml file.
;;

; The location of the Ant build file.
(make-local-variable 'jde-make-args)
(setq jde-make-args "-f <TOP>/build.xml")

;; You may want to add the following (this allows C-z C-z or
;; "compile" to use ant instead of "make")  This is more natural to
;; old emacs hackers than C-c C-v C-b.
;
; Set C-z C-z to be the same as C-c C-v C-b inside jde major modes
;
(local-set-key "\C-z\C-z" 'jde-build)

;;;
;;; END prj.el
;;;        

Happy hacking,
Barrie
--
Barrie Treloar
____________________________________________________________________

  Barrie Treloar                      Phone: +61 8 8303 3300
  Senior Analyst/Programmer           Fax:   +61 8 8303 4403 
  Electronic Commerce Division        Email: barrie@camtech.com.au
  Camtech (SA) Pty Ltd                http://www.camtech.com.au
 --- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________

Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant Main.java Project.java

[Stefan Bodewig <bo...@bost.de>]

>>>>> "KW" == Ken Wood <kw...@i2.com> writes:

 KW> I'm worried that we keep adding subtle variations of the same
 KW> thing just to meet a specific need.

Thanks for getting us back to the primary goals of Ant, Ken.

I'm more than reluctant to add anything that affects the core of
Ant. Searching upwards for build.xml is a border case.

It is useful for a lot of people I know - those using (X)Emacs/JDE can
now simply say "build using make" and set the make command to ant and
it will always pick up build.xml without the need to explicitly
specify the -buildfile switch, for example.

On the other hand you could view this as a gimmick that's not really
needed, because you could always use -buildfile and don't have to rely
on implicit behavior.

I'm willing to remove this functionality again if this would open the
way for everybody's "yet another feature".

Adding all tasks as they come is more of "give them a home until we
have the extension task mechanism in place". Actually I'm even
thinking about removing all tasks that are not really part of the core
and move them to a new jakarta-ant-tasks project. But this is only
thinking loud for the moment.

And yes, I'll keep fighting duplication wherever possible.

Stefan