Craeg, Thanks for your comments, good to hear back from somebody ;-) > 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? This is the idea of the compiler factory - copied from the way javac does it. I haven't looked at the others because I don't use them - I use only jasper and I know it works with that. I guess I am trying to offload the maintenance of this task onto the community as a whole, since I may not keep up and be in trouble when I want to use it again - also, I move around a lot and find it hard to keep all my add-ons in order.
> 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-- This is actually something I took from someone elses jpsc task - it is nothing to do with what platform you are on, but is an option you can pass to the jasper jspc class that does some sort of substitution in a jsp file or something, but is only specific to the jsps being generated and nothing to do with ant. I run on linux primarily also... > 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 Exactly - this is precisely what it does. > 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. It does to a degree - in posting it I was hoping to get this sort of feedback to hopefully make it more customisable and "policy free". I would be very interested to know how other people arrange there development environment and see if I can incorporate flexibility enough to incorporate those as possibilities, by making projectdependencies more flexible. > 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. I would love to see something like this and would happily contribute my task to this sort of distribution. Again, I would like to have it generally available to get feedback and available to me herever I work in a way that I don't have to support those sites in person - having some sort of central repository for contrib tasks would meet my needs. Surely a tiny bit of scoping would be good? www.ant-taskdefs.org? Your propgen task sounds interesting. So how does this work at runtime? I'd really like to see something similar working over JNDI, so I could use property files, ldap or whatever... Thanks, Matt
