I was preparing for a trip away and was checking through our old correspondence. I found one where you asked me about improving the description of the cc-buildloop target so "ant -projecthelp" became
self-explanatory. At the same time, I was downloading the latest source from CVS into a clean sandbox and needed to run that target. I was thinking about the issue when I saw this thread.
The cc-buildloop target is specifically designed as a paranoid project distribution mechanism because it begins with the clean target, which removes all the output folders. As such, it is ideal for someone who has
just checked out the source and so does not have the bundles prepared already, but is a bad idea as a routine activity.
On the other hand, the rebuild target specifically excludes the bundles target.
I think we have missed a key point that is part of the ant philosophy (and other make systems), which is "incremental building". Of course, there will be project dependencies that cannot always be properly
expressed in the build dependencies, which is why we need targets such as cc-buildloop (and any others that depend on the clean target). However, project developers will often want a fast-path build that isn't
100% reliable, but is as quick as possible. This fast-path should specifically NOT depend on clean, relying on ant to detect those targets that are needed to "replenish" objects that are out of date.
In particular, the bundles are unlikely to change, so we ought to be letting ant decide that they usually don't need building. However, each of the many bundle-xxx targets individually runs the ant jar task, which is
incremental but rather inefficient.
Such an "incremental build" target should be called something self-evident, such as "build" (yes, I know we already have one). Incidentally, we document the "make" target as incremental, but it doesn't depend on
bundles. In all, it is quite confusing for me... let alone for someone new to the project.
1. we have some (wiki) project documentation that tells users to run cc-buildloop to initialise a new sandbox. Unfortunately, the many posts to this forum show us there are very many new users who don't rtfm and so
immediately get into trouble using the run target.
2. we follow modern ant paractice by having the no-op target called "usage" as our default. This is intended to help new users by preventing them from blundering into a failed build by accident.
3. I have just committed 2 minor changes to build.xml that should help matters immediately... the usage target now puts cc-buildloop at the top of the list. I've also slightly reworded the description of the cc-buildloop
target to make it sound more important when viewed with "ant -projecthelp".
I am concerned about making the mainstream targets dependent on the bundles target. You are correct about the wasteful processing overheads for active developers. I think there isn't a simple solution, otherwise
we would have thought of it before!!
However, I'll take a look while I am away to see whether I can find a useful compromise... perhaps a new target called "test-fast" that could be used by developers who understand the risks, while making the
"obvious" tasks such as run and test depend on bundles to make them perfectly safe? (I don't think using a new, externally defined, property would be acceptable). I'm not sure of the details yet, because the build is
very complex (especially jmf preparation, netbeans debugging and javadoc targets).
I probably won't collect any follow-up posts for more than a week, but I will not commit any more changes until I've seen your response after I've returned.
On Thu, 20 Apr 2006 02:08:56 +0200, Emil Ivov wrote:
The only way I could get it to run was to manually do the bundles.
Indeed you need to execute the bundles target before actually running
the project as that's where code gets compiled and the jars created.
The run target does not include a dependency to bundles as it is often
necessary to run the project more than once before having to rebuild again.
This is not the first time we're having this kind of reports though. I
suppose that the confusion is due to the non common name of the bundles
target. Right now, the bundles target includes a dependency on the
rebuild target. The purpose was to let a possibility for recompiling the
code without losing the time to build the bundle jars. I am now thinking
though that this is really quite unnecessary and it might be a better
idea to include the bundles target as a dependency to rebuild. (Is this
what you were suggesting?)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org