You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matthew Watson <ma...@mortbay.com> on 2001/07/16 05:40:49 UTC
Task Submissions
Hi All,
I have written some tasks that I am interested in getting feedback on
whether people consider them worthy to be included as standard/optional
tasks. Briefly these are:
JavaH (http://www.i3sp.com/ant/JavaH.html) : run javah - not tested on
WinXX though
JspC (http://www.i3sp.com/ant/JspC.html) : Run the (jasper) jsp
precompiler to turn jsp files into java classes
MungeJar (http://www.i3sp.com/ant/MungeJar.html) : Build a jar file from
a whole CLASSPATH - extends Jar, so supports include/exclude.
ProjectDependencies (http://www.i3sp.com/ant/ProjectDependencies.html) :
Supports interdependencies amongst projects and third-party products -
builds CLASSPATH for the user, supports variable setting from other
projects, build accounting, exporting variables to shell, emacs, perl etc.
The doco for these tasks is at the given urls.
Please have a look. The code is developed according to the ant standards
etc. But is in my own namespace at the moment, so if people are
interested, I will port it and make it available as well.
Looking forward to hearing from people,
Matt
Task Submission: Project inter-dependency classpath builder and version verifier
Posted by Matthew Watson <ma...@i3sp.com>.
I have tidied up my code for this task. It is a pretty complex one, but
one that I use extensively and have had requests from multiple
organisations/people to ask if they could use it. I figure the best way
of doing this is to get it included in ant!
This task does dependency checking between multiple projects/products
that may have multiple versions. It allows you to specify which version
you want, what path elements from the project/product you would like in
your classpath/path/manpath/libpath or specify them from the
depended-upon project/product itself.
It also does recursive version verification (looking for clashes) and
recording of what other projects/products were used during a build - and
it does all this amazingly fast.
The full source tree is here:
http://www.i3sp.com/ant/projectdependencies/
The projectdependencies.tgz is the full source with the patches for the
defaults.properties and the optional.html
the html doc for it is here:
http://www.i3sp.com/ant/projectdependencies/docs/manual/OptionalTasks/projectdependencies.html
There is a rudimentary test in
http://www.i3sp.com/ant/projectdependencies/src/main/org/apache/tools/ant/taskdefs/optional/projectdependencies/test/
Check the readme.txt file for what it does and how to run it - sorry it
is not automated... No time at present.
Matt
Re: Task Submissions
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Matthew Watson" <ma...@i3sp.com>
To: <an...@jakarta.apache.org>
Sent: Thursday, July 19, 2001 11:35 PM
Subject: Re: Task Submissions
> Stefan Bodewig wrote:
>
> >>Buts its key weaknesses are
> >> -does not (yet) do dependency based invocation.
> >> -doesnt use any javac choice (a feature of the jasperc library
> >> which I dont want to look at)
> >>
> >
> > I think both are important features - depending on the number of JSPs
> > of course. Users will also want that the chosen javac is the same the
> > <javac> task would use.
>
>
> I'm not sure I follow what you guys are talking about here. What do you
> mean by dependency based invocation? What has javac got to do with
anything?
I was causing confusion here. I was under the mistaken impression that the
jasper code does the compile too -it doesnt seem to, so a handoff to javac
comes next in the process.
I dont know what jasperc does when you spec a -webapp <directory> -either
it transforms everything or it does dependency based translation. I'll need
to test.
>
>
> >>One issue to worry about first: what use cases are we addressing
> >>with this task
> >>
> >>1. compilation of jsp pages purely as a syntax checker before
> >>bothering to deploy
> >>
> >>2. precompilation of jsp pages into java files /.class files for
> >>inclusion in war files
>
>
> For me, I definitely need this task for 2, and that is what my
> implementation does (We are not allowed to have things like
> javac/tools.jar on our production machines). I am simply running
> org.apache.jasper.JspC on the given fileset. I took the code from javac,
> added in a package="" attribute to pass to JspC and use that to
> calculate the generated .java file name from the fileset of jsp files. I
> only use the basename of the jsp file combined with the package name to
> get the generated file name and then do dependency checking based on
> that mapping to decide what to build.
> I run javac seperately. I have a seperate tree next to classes, usually
> called gensrc (I also use javacc and others) that these file go into and
> then run javac on both my source and generated source trees:
>
> <jspc srcdir="${src.dir}/war"
> destdir="${gensrc}"
> package="com.i3sp.sso.jsp"
> verbose="9">
> <include name="**/*.jsp" />
> </jspc>
> <javac srcdir="${src.dir};${gensrc}"
> destdir="${classes}"
> debug="on"
> optimize="off"
> deprecation="on"
> >
> <include name="com/i3sp/**/*.java"/>
> <exclude name="RegisterClient.java"/>
> </javac>
If Matt had already been using his code for production generation of
servlets, rather than sanity checking, then it is much more mature than
mine. I would propose that we use that codebase (when we get to see it),
pulling in any extra parameters from my version. Then we need some complex
test case .jsp files to build -some with custom classpaths, taglibs, etc.
It'd be nice if we had some real stuff there -is there a collection of pages
for the tomcat/JSP test suite.
> I'm off to the snow for a week!
> Matt
I've been off in the hills too, maintaining strict email/radio silence. In
fact my return to civilisation is still an undocumented secret, till I find
out on monday whether the death march has slowed to a strolled or been
ramped up to a death jog. Its likely I wont have much time to work on this
in the next few weeks, but I may be able to scrape a bit of calm in here or
there.
Matt, now that you are back and reading this, can you post your source?
-steve
Re: Task Submissions
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 20 Jul 2001, Matthew Watson <ma...@i3sp.com> wrote:
> What do you mean by dependency based invocation?
Only compile a .jsp to .java file(s) if it is newer than the output
files - tricky as different implementations use different naming
schemes for the generated files.
> What has javac got to do with anything?
To take that a step further, compile the .java files to .class files,
using the compiler the user would chose for a javac task as well.
>>>2. precompilation of jsp pages into java files /.class files for
>>>inclusion in war files
>
> For me, I definitely need this task for 2, and that is what my
> implementation does
As I said, I haven't looked into any of the submitted tasks yet.
> I run javac seperately.
Sure, this always is an option, but you could make the task do that
automatically as well.
> I'm off to the snow for a week!
Have fun
Stefan
Task Submission: JspC w/ CompilerFactory & Dependency checking
Posted by Matthew Watson <ma...@i3sp.com>.
> If Matt had already been using his code for production generation of
> servlets, rather than sanity checking, then it is much more mature than
> mine. I would propose that we use that codebase (when we get to see it),
> pulling in any extra parameters from my version. Then we need some complex
> test case .jsp files to build -some with custom classpaths, taglibs, etc.
> It'd be nice if we had some real stuff there -is there a collection of pages
> for the tomcat/JSP test suite.
http://www.i3sp.com/ant/jspc is the root of the source. the jspc.tgz has
it all, including the patches for optional.html and defaults.properties.
The doco is at
http://www.i3sp.com/ant/jspc/docs/manual/OptionalTasks/jspc.html
And the main source is at
http://www.i3sp.com/ant/jspc/src/main/org/apache/tools/ant/taskdefs/optional/JspC.java
but it requires
http://www.i3sp.com/ant/jspc/src/main/org/apache/tools/ant/taskdefs/optional/jspcompilers/
as well.
Sorry it took so long - I have been pretty busy.
I have added in a classpath attribute, so you can specify the classpath
for running the compiler without having to have it in your ant classpath
and added the ieplugin and mapped attributes from japser.
Also, it is now similar to javac in that it has a CompilerFactory etc.
To support multiple compilers. I only use jasper, so others will have to
pick that up - This should really be done by a properties file, but... time!
Haven't had time to set up formal testing - I've tested it with my jsp
files and it works fine (I notice javac has not tests either ;-).
>>I'm off to the snow for a week!
>>Matt
And I'm off again saturday week :-)
Matt
Re: Task Submissions
Posted by Matthew Watson <ma...@i3sp.com>.
Stefan Bodewig wrote:
>>Buts its key weaknesses are
>> -does not (yet) do dependency based invocation.
>> -doesnt use any javac choice (a feature of the jasperc library
>> which I dont want to look at)
>>
>
> I think both are important features - depending on the number of JSPs
> of course. Users will also want that the chosen javac is the same the
> <javac> task would use.
I'm not sure I follow what you guys are talking about here. What do you
mean by dependency based invocation? What has javac got to do with anything?
>>One issue to worry about first: what use cases are we addressing
>>with this task
>>
>>1. compilation of jsp pages purely as a syntax checker before
>>bothering to deploy
>>
>>2. precompilation of jsp pages into java files /.class files for
>>inclusion in war files
For me, I definitely need this task for 2, and that is what my
implementation does (We are not allowed to have things like
javac/tools.jar on our production machines). I am simply running
org.apache.jasper.JspC on the given fileset. I took the code from javac,
added in a package="" attribute to pass to JspC and use that to
calculate the generated .java file name from the fileset of jsp files. I
only use the basename of the jsp file combined with the package name to
get the generated file name and then do dependency checking based on
that mapping to decide what to build.
I run javac seperately. I have a seperate tree next to classes, usually
called gensrc (I also use javacc and others) that these file go into and
then run javac on both my source and generated source trees:
<jspc srcdir="${src.dir}/war"
destdir="${gensrc}"
package="com.i3sp.sso.jsp"
verbose="9">
<include name="**/*.jsp" />
</jspc>
<javac srcdir="${src.dir};${gensrc}"
destdir="${classes}"
debug="on"
optimize="off"
deprecation="on"
>
<include name="com/i3sp/**/*.java"/>
<exclude name="RegisterClient.java"/>
</javac>
I'm off to the snow for a week!
Matt
Re: Task Submissions
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 19 Jul 2001, Steve Loughran <st...@iseran.com> wrote:
> Yes, a facade would work, although there is always the issue of how
> to have non standard options.
Yep, an issue all these facade tasks share.
The easiest (but incomplete) solution is to allow arbitrary additional
arguments to be specified, I'm going to provide this for javac unless
somebody gets there faster than me. That way, you can specify
non-standard options if you know which implementation will be chosen -
I don't think we'll have some means other than magic properties or
finally defining and implementing the user preferences system right
now.
> Buts its key weaknesses are
> -does not (yet) do dependency based invocation.
> -doesnt use any javac choice (a feature of the jasperc library
> which I dont want to look at)
I think both are important features - depending on the number of JSPs
of course. Users will also want that the chosen javac is the same the
<javac> task would use.
> One issue to worry about first: what use cases are we addressing
> with this task
>
> 1. compilation of jsp pages purely as a syntax checker before
> bothering to deploy
>
> 2. precompilation of jsp pages into java files /.class files for
> inclusion in war files
I agree with you, first (1) and do it properly, then (2). I think (2)
may also need knowledge about the target container as there is no
standard location for compiled JSPs AFAIK. I'm not sure whether we
can assume that the jspc implementation will always be coupled to a
specific target container.
Stefan
Re: Task Submissions
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, July 18, 2001 10:40 PM
Subject: Re: Task Submissions
> On Thu, 19 Jul 2001, Matthew Watson <ma...@i3sp.com> wrote:
>
> >>>JspC (http://www.i3sp.com/ant/JspC.html) : Run the (jasper) jsp
> >>>precompiler to turn jsp files into java classes
> >> Seems as if several people would be working on this in parallel 8-)
> >
> > This is definitely possible. I developed this about 5 months ago in
> > isolation.
>
> Steve Loughran just submitted a sketch of his jasper jspc task the
> same day your mail arrived and there's been a jspc task at ant-user
> last Saturday, that's where my comment comes from.
>
> We already have a Weblogic jspc task in CVS (it's an undocumented part
> of Ant since 1.2) and it seems obvious that <jspc> would be a
> candidate for a facade task just like <javac> and <rmic> are today.
Yes, a facade would work, although there is always the issue of how to have
non standard options.
> Hope I'll find time to look into all three of them 8-(.
well, if you look at mine its core features are
-directly calls jasperc for speed and ease of turning jasperExceptions into
BuildExceptions
-supports all the current document jasperc options, even if jasperc fails
on one of them (ieplugin)
-uses an explicit fileset (<source>) rather than an implicit one.
-has some unit tests pencilled in
Buts its key weaknesses are
-being coupled to jasperc could make it less stable
-does not (yet) do dependency based invocation.
-doesnt use any javac choice (a feature of the jasperc library which I dont
want to look at)
>From the test build file, It looks like jasper doesnt like it when I hand in
multiple files to get compiled; I may just do it one at a time..if that
works then basic dependency based invocation (dest file older than source
file) might work, provided we steal the jsp to java filename algorithm from
jasper.
One issue to worry about first: what use cases are we addressing with this
task
1. compilation of jsp pages purely as a syntax checker before bothering to
deploy
2. precompilation of jsp pages into java files /.class files for inclusion
in war files
use case (1) is all I need now; if the jspc tasks work reliably I might
think about (2), but not yet. What about anyone else interested in jsp
compilation from ant?
-steve
Re: Task Submissions
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 19 Jul 2001, Matthew Watson <ma...@i3sp.com> wrote:
>>>JspC (http://www.i3sp.com/ant/JspC.html) : Run the (jasper) jsp
>>>precompiler to turn jsp files into java classes
>> Seems as if several people would be working on this in parallel 8-)
>
> This is definitely possible. I developed this about 5 months ago in
> isolation.
Steve Loughran just submitted a sketch of his jasper jspc task the
same day your mail arrived and there's been a jspc task at ant-user
last Saturday, that's where my comment comes from.
We already have a Weblogic jspc task in CVS (it's an undocumented part
of Ant since 1.2) and it seems obvious that <jspc> would be a
candidate for a facade task just like <javac> and <rmic> are today.
Hope I'll find time to look into all three of them 8-(.
Stefan
Re: Task Submissions
Posted by Matthew Watson <ma...@i3sp.com>.
Stefan Bodewig wrot
> some first comments only, I'll look at your pages during the next
> days.
>
>>JavaH (http://www.i3sp.com/ant/JavaH.html) : run javah - not tested
>>on WinXX though
> How is this different from the optional <javah> task already present?
>
Well, mine isn't as good. Whoops - I thought I'd checked whether 1.3 had
one of these. Good, one less thing to maintain!
>>JspC (http://www.i3sp.com/ant/JspC.html) : Run the (jasper) jsp
>>precompiler to turn jsp files into java classes
> Seems as if several people would be working on this in parallel 8-)
This is definitely possible. I developed this about 5 months ago in
isolation.
Mine is fully functional as far as my requirements go. It is based on
the javac task from 1.2, so may need some improvements, since I believe
javac has evolved a lot since then. Support for multiple jsp compilers
is a bit sketchy, in that it needs to be added to the class...
Matt
Re: Task Submissions
Posted by Stefan Bodewig <bo...@apache.org>.
Hi Matthew,
some first comments only, I'll look at your pages during the next
days.
On Mon, 16 Jul 2001, Matthew Watson <ma...@mortbay.com> wrote:
> JavaH (http://www.i3sp.com/ant/JavaH.html) : run javah - not tested
> on WinXX though
How is this different from the optional <javah> task already present?
> JspC (http://www.i3sp.com/ant/JspC.html) : Run the (jasper) jsp
> precompiler to turn jsp files into java classes
Seems as if several people would be working on this in parallel 8-)
Stefan