Matthew Watson wrote:
I took a quick look at your posts (I am not a committer). Here is my 2c for what it is worth:Hi All, I posted source,doco and patches for 2 tasks, jspc and projectdependencies a while back now, subsequent to a discussion with several people on the list here, including Stefan Bodewig and Steve Loughran. My jspc task was implemented with a compiler factory a la javac, full dependency checking etc. I have heard nothing since then (15 August). I am aware that 1.4 was a big production, what sort of time frame can I expect for a response to my posts? Thanks, Matt
I like the idea of a JSPC task. We already have an optional <wljspc> task for the WebLogic
JSP compiler. Perhaps we could somehow create a single <jspc> task and make the weblogic
specific stuff a special case via a flag or something. There is something similar to this in "EJB Tasks."
Had you already considered this?
The next question is design/implementation. I did not look at the code, however, I noticed an attribute
"ieplugin: Java Plugin classid for Internet Explorer" That is problematic for us Linux/Solaris users--
the ant tasks I have seen are all cross-platform or multi-platform.
This issue is, I believe, the main reason that the ant development community has stayed
away from any type of browser integration-- it is complicated and non-portable
(Netscape 4.7.X, NS 6.X, Mozilla, Opera, IceBrowser, IE, Konquerer, Lynx, etc. etc.)
The <projectdependencies> task is another matter. I understand (all too well) the problem you are
trying to solve: build repeatability. This area includes requirements such as:
- record the versions of every project/technology upon which your project depends
- sort out the dependency tree-- make sure there are no incompatibilities or conflicting requirements
among subprojects/technologies
All buildmasters must solve this problem, one way or another. The issue I have with <projectdependencies>
is that it makes assumptions about how the build environment is organized and essentially implements
a management policy.
I believe this is in conflict with the ant philosophy of "policy-free" tasks. Note-- this is not a judgement on
the _quality_ of the task. In fact, I may try it out myself. Rather, IMHO I think this is the kind of value-added task
that could be featured in a "contrib" type of area. Someone mentioned www.taskdefs.org as a
possible future "task portal" for contributed tasks.
We are in the same boat here-- we have a task that manages property files in a cascading-override fashion.
You can specify arbitrary levels of defaults for any property (locale, company, division, department, project, person,
OS-platform, etc.) and <propgen> simply loads them in order. Property files are used to group arbitrary sets of
properties that apply in a given context. You control the whole shebang by specifying a "meta-property" which is the
propertyfile-path. Just like jar files in a class path, the first property file in the property path wins.
This solved for us the problem of having multiple projects with mostly-but-not-quite overlapping
properties (aka "once and only once").
We are quite happy with our <propgen> task, and there were one or two others who expressed an interest-- but it
probably does not belong in the ant distribution itself because it implements our particular policy for managing properties.
On the other hand, it would be cool to have <propgen> available in some publically accessible repository so others
would not have to reinvent it...
Just some thoughts....
--Craeg
