ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <cstr...@arielpartners.com>
Subject Re: TASK SUBMISSION: jspc and projectdependencies
Date Wed, 12 Sep 2001 20:36:18 GMT
Matthew Watson wrote:

>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 took a quick look at your posts (I am not a committer).   Here is my 
2c for what it is worth:

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


Mime
View raw message