On Mon, 01 May 2006 17:24:50 +0200, Emil Ivov wrote:
>>
>> I was a bit shocked by your change to the run
target. It no longer
>> has ANY dependents! Isn't that too extreme? Isn't
that too
>> counter-intuitive for newbies? It means the run
target has "no
>> insight" into changes made to the source
base... an observer could
>> download a source change from CVS and still execute
the "old"
>> version.
>
>Well, I understand what you mean but the way I see it,
having the
>possibility to do a light run (one that would not
inherently rebuild all
>your project) is more important than requiring the user
to do a make
>before the run. I don't think this is very counter
intuitive since most
>users accustomed to building projects from source are
used to the
>concept of having to "make" before running
and to the fact that running
>the project at any given moment would run the latest
binaries without
>taking into account any changes in the source that have
occurred since
>the last build. I even think that some people (me
included) count on
>such behavior.
Well, I hear what you say and don't agree. However, I
realise that a) our positions are mutually exclusive and b)
they are equally valid. Therefore, we have to take a
decision quickly and move on.
I think our difference arises from the state of the project
at this particular moment, as well as our different degrees
of experience with linux. Many linux distributions have
followed the {make clean; make; make test;
run} pattern, but in my experience this is becoming less
common as products become more portable (across operating
systems and across individual implementations of an
operating system). I think it is fair to say
that almost all other O/S's (and many recent linux
distributions) use the {make; deploy; install; run} pattern,
which assumes the product will be developed in one place and
deployed in many others.
Even our pre-1.0-sip-communicator used a binary installation
and I remember being particularly impressed by the web-based
"no-installation" demo. Ever since I joined the
project, I have assumed that we would
use the binary installer pattern for the new 1.0 system,
even though we do not have one yet... perhaps I've made the
wrong assumption?
I see it this way :-
If ordinary users will eventually be able to download and
run a "binary" installation package, then ant
will revert to being the tool of just the developers. If
most developers understand (and enjoy) the distinction
between "ant run" and "ant make run"
and "ant clean run", then I agree the run target
should have no dependents (i.e. your revision 1.32, which is
the latest). Personally, I don't like this scheme, but I'm
smart enough
to remember when I'm playing with knives and need to be
careful. A couple of extra lines in the usage target ought
to allow us to warn other developers of the potential
danger.
On the other hand, If ordinary users will always be expected
to download the source and make the product on their own
machines, then it follows that ant will remain as the
launcher for every stage of the process. In
this case, I feel we need to make the probability of
mistakes as low as possible for these inexperienced users.
We got into this whole discussion because a new user tried
the intuitively obvious "ant run", but it
didn't
work. It is a PR disaster if newbies can't successfully run
the product and so keep asking us for help (or complaining)
on the mailing list.
>Most IDEs would let you specify an option and choose
whether or not the
>project is to be built before every time it is run. We
could easily add
>the same thing in the build.xml. If other people on the
list agree that
>a run should also build by default and that the opposite
would confuse
>new users, then I'll agree to setting this option to
true by default
>(and keep it false for my sandbox  ).
Yes, this is true. You will see the sample netbeans
project.xml has three ide actions: "Build
Project" is mapped to the make target; "Clean
Project" is mapped to the clean target; "Clean
and Build" maps to BOTH
the clean and make targets (i.e. "ant clean
make"). You will also see that the "test",
"debug" and "run" ide-actions map
directly to the corresponding single ant targets and so
inherit the dependencies within
build.xml. In other words, Netbeans is neutral - it does
what it says whether we do it your way or mine.
So, please think about my question... who will be the
majority of the users of build.xml for the next year or so?
We should cater to the needs of that community. You are the
project manager and the only person
qualified (and entitled) to make the statement.
I will be happy to make the build dependency, usage target
and wiki changes to consistently reflect your decision.
Regards,
Brian
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|