ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gert Driesen" <gert.drie...@pandora.be>
Subject Re: cvs commit: jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs/optional JspcTest.java
Date Wed, 13 Mar 2002 19:56:26 GMT
responses inline ...

----- Original Message -----
From: "Steve Loughran" <steve_l@iseran.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Wednesday, March 13, 2002 6:12 AM
Subject: Re: cvs commit:
jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs/optional
JspcTest.java

>
> ----- Original Message -----
> From: "Gert Driesen" <gert.driesen@pandora.be>
> To: "Ant Developers List" <ant-dev@jakarta.apache.org>
> Sent: Tuesday, March 12, 2002 1:08 PM
> Subject: Re: cvs commit:
> jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs/optional
> JspcTest.java
>
>
> > Hi Steve,
> >
> > I looked at the javac implementation and I definitely can see how this
> could
> > work, but I don't know if this is how it should work.
> >
> > Should users actually have to specify the commandline options themselves
> (as
> > javac task does with compiler arguments) ?
>
> I think commonality should be extracted out; per-back end options left as
> extras to specify as arguments.,

It's not the best solution, but I can agree with you on this ... just for
once :-)

The best solution would be something similar to what has been accomplished
with the ejbjar task ...

for compiling with the weblogic jsp compiler it would look something like
this :

<jspc srcDir="<directory>" destDir="<directory>" webAppDir="<directory>"
verbose="true|false" package="..." failonerror="true|false"
encoding="<encodingtype>">
    <classpath>
        ....
    </classpath>
    <include name="*.jsp"/>
    <weblogic noTryBlock="true|false" keepgenerator="true|false" .....>
        <wlclasspath>
            ....
        </wlclasspath>
    </weblogic>
</jspc>

and for the jasper jsp compiler it could look something like this :

<jspc srcDir="<directory>" destDir="<directory>" webAppDir="<directory>"
verbose="true|false" package="..." failonerror="true|false"
encoding="<encodingtype>">
    <classpath>
        ....
    </classpath>
    <include name="*.jsp"/>
    <jasper uriroot="<directory>" uribase="...." webxml="..."  webinc="...."
ieplugin="..." mapping="...">
        <jasperclasspath>
            ....
        </jasperclasspath>
    </jasper>
</jspc>

don't you agree that this would provide the greatest level of flexibility ?

>
>
> > I think the JspC task should support the following attributes, which are
> > usefull for all (?) jsp compilers :
> >
> > classpath
> >   already available
>
> agreed
>
> > verbose
> >   already available, but is current an int value, would be better to
make
> it
> > a boolean value
>
> ah, ok. jspc takes a range of values; which ones should we use for true
and
> false

perhaps use the verbose attribute on the task to specify a "normal" level of
verbosity and allow a more precise level to be set using a jasper specific
option

>
> > rebuild
> >   boolean value to indicate that all jsp pages should be rebuild, so :
> >     for the Jasper compiler : don't perform a check on the last modified
> > time, just pass all jsp pages to the compiler
>
> could do; we would be consistent if we didnt do this but relied on a clean
> target to clean up for a forced rebuild. This lets you go "ant clean
build"
> without having separate rebuild=true, rebuild=false targets

ok, but that means that the jsp name mangler should be per-compiler ...

>
> >
> >     for the weblogic compiler : don't add the -depend commandline
argument
> > package
> >   already available
>
> > webAppDir
> >       why didn't you just use a simple attribute (eg. webAppDir) for
this
> in
> > the current implementation ?
>
>
>
> > srcDir
> >   already available
> > failonerror
> >   already available
> >
> > That leaves use with the following attributes which are specific to the
> > jasper compiler :
> >
> > uriroot
> > uribase
> > ieplugin
> > mapping
> > webinc
> > webxml
> >
> > and the following attributes which are specific to the weblogic compiler
:
> >
> > noTryBlock
> >
> > (and perhaps encoding)
>
> yes, we should do encoding
>
> >
> >
> > Can you please comment on (all of) this ?
>
>
> >
> > now with regards to your last message :
> >
> > - I don't really understand what you mean with the dir naming issue ...
> can
> > you please elaborate on that ?
>
> If I have a jsp page in a subdirectory, how is that turned into a java
file?
> Is it stored in a package name relative to the webapp base? What if the
path
> name is 'illegal' and needs mangling itself?

I think jsp pages in subdirectories should use the package name the user
specified or use no package name at all if the user didn't specify one

>
> >
> > - I also don't understand why you would make uriroot mandatory, but I
> guess
> > you'll explain further :-)
>
> Uriroot is the jasper term for the base of the webapp. The compiler will
try
> and work it out if none is given, but its error messages are uninformative
> ('empty stack exception') and I dont want to duplicate the code in jspc.
If
> we mandate that the base of the webapp; (your term webAppDir seems ok),
then
> all is well.
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>

Best regards,

Gert Driesen


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message