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...@i3sp.com> on 2001/09/12 06:07:42 UTC
TASK SUBMISSION: jspc and projectdependencies
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
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
>
>
>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?
>
Agreed. I was not the proposer of taskdefs.org-- it was John Casey--
John can you
give us an idea of the status of this?
>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...
>
Excellent ideas. I am afraid our current implementation is rather
primitive. You simply
pass a "property path" to <propgen> consisting of a colon separated list
of files. The properties
from all of these files are combined in the order they appear in the
path. The nice feature is
that the properties are first combined, then resolved. This means that
properties can be
referenced in one file and defined in another. This is a very
important requirement if you
want to avoid duplicating property settings across related projects.
The resulting set of properties is either fully resolved, or
<propgen> craps out complaining of "unresolved properties." If all is
well, <propgen>
sets the resulting properties in the current ant project.
Alternatively, it can write them
out to a file. Writing them to a file has an important advantage--
<propgen> can test
whether the final set of properties for THIS run is different from that
of a PREVIOUS run.
You can tell it not to overwrite the output file if the result is
exactly the same as before.
This, combined with tasks such as <dependset>, enables you to correctly
require a rebuild
for a project when a property changes. This kind of change might
otherwise not be detected
by any of the normal tasks ( <javac>, <style>, etc.)
<target name="init">
<propgen
basedir = "${basedir}"
overwrite = "false"
xmlout = "temp/projecta-output-properties.xml">
<propertypath>
<pathelement
path="proposalB-settings.xml:project-settings.xml:department-settings.xml:company-settings.xml"/>
</propertypath>
</propgen>
</target>
You will notice that the property files in the above example are XML.
We made <propgen> recognize both the traditional
java.properties format as well as our simple XML format-- XML format is
convenient to parameterize
XSLT transformations. In this way, we have no duplication-- we can
specify single properties
used both in Java code and in XSLT transformations. For example:
<target name="doc" depends="init">
<style
in = "content.xml"
out = "index.html"
style= "front-page.xsl">
<param
name = "properties"
expression = "temp/projecta-output-properties.xml"/>
</style>
</target>
>Matt
>
--Craeg
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
>
>
>>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.
>
We have the same issues, but we also have some additional requirements
for our build environment:
- must be able to build while on the road (plane, train, etc.)
disconnected from servers
- must be able to build on "any" platform (where any in { mac OS/X,
Win32, Linux, Solaris, etc } )
- must be able to use client equipment where we do not have
root/administrator priviledge.
We therefore concluded that the most we can count in is a SINGLE
DIRECTORY. Therefore,
we created the concept of $TOP. $TOP is a "root context" within which
we copy all
technologies upon which we depend. In this way, we can actually use a
specific version of jboss,
tomcat, cocoon2, saxon/xerces, JDK, netbeans, Ant, etc. etc. -- all the
while leaving the client's machine with its
configuration totally undisturbed. When we leave, we simply remove
$TOP and we are done.
What we need, therefore, is a tool that enables us to copy the _relevant
portions_ of our tools and
technologies into $TOP (often a single jar file) and to create a
manifest file such that:
- we always know which versions of everything we are using
- can verify and validate the environment
- can upgrade/downgrade/install/remove technologies easily
Does this sound an awful lot like RPM (Redhat package manager)? We
thought so, too-- but
found to our chagrin that it is really problematic to use in this way,
on all these platforms.
We are therefore considering designing and building
a new Java-based package manager. Interestingly, it could reuse many
of the Ant Tasks.
We are looking forward to Ant 2.0 and pluggable Tasks which should make
this much easier.
I went into some detail here to illustrate my point about policies-- our
policy is clearly different from
yours, for good reason (our additional requirements). There are,
however, interesting common requirements
in the area of package management. What do you think?
--Craeg
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Matthew Watson <ma...@i3sp.com>.
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
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Craeg K. Strong" <cs...@arielpartners.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 13:36
Subject: Re: TASK SUBMISSION: jspc and projectdependencies
> 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 is explicitly part of the jasperc command parameters; it lets you spec
the classID of the activeX plugin you want to use when IE is present. Then
when you use <jsp:plugin> in your code, somehow the appropriate plugin
invocation mechanism is generated for the appopriate browser. So Matt's
inclusion of this property is a good thing for those people who need it.
I too like the idea of a jspc task, and as Matt's works in his projects, it
should be a good foundation, just needing rounding off with some tests. But,
as usual, I have been somewhat distracted, what with being out the country
and things. My current project is using taglibs and stuff for JSP dev, so
should should be a good test platform.
Give me a few days to get started and I'll post an update.
-steve
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
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
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Peter Donald <do...@apache.org>.
On Thu, 13 Sep 2001 17:34, Matthew Watson wrote:
> Peter Donald wrote:
> > Hi,
> >
> > jspc task sounds useful and has been requested lots. Often the best way
> > to get something into ant is just to make lots and lots of noise ;) It is
> > possible that none of the committers would use it and thus are hesitant
> > to commit ;)
>
> Something like:
> Subject: EXTREMELY HIGHLY DESIRED TASK SUBMITTED!!!!
>
> ;-)
Works for me ;)
> > Would you mind submitting it again. (I fubarred my local archives not
> > long ago).
>
> It is in the archive, or have a look here:
> http://www.i3sp.com/ant/jspc - the tgz has everything in it.
Okay looks good. I put it in the ant.taskdefs.optional.jsp package though
along with the wljpsc task. (Eventually this would hopefully be deprecated in
favour of generic jspc task).
Could you check it out and make sure I didn't stuff anything up ? ;)
--
Cheers,
Pete
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Matthew Watson <ma...@mortbay.com>.
Peter Donald wrote:
> Hi,
>
> jspc task sounds useful and has been requested lots. Often the best way to
> get something into ant is just to make lots and lots of noise ;) It is
> possible that none of the committers would use it and thus are hesitant to
> commit ;)
Something like:
Subject: EXTREMELY HIGHLY DESIRED TASK SUBMITTED!!!!
;-)
> Would you mind submitting it again. (I fubarred my local archives not long
> ago).
It is in the archive, or have a look here:
http://www.i3sp.com/ant/jspc - the tgz has everything in it.
Matt
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 13 Sep 2001, Peter Donald <do...@apache.org> wrote:
> It is possible that none of the committers would use it and thus are
> hesitant to commit ;)
It is also possible that one committer who would have done it has been
on vacation after the Ant 1.4 release 8-)
Stefan
Re: TASK SUBMISSION: jspc and projectdependencies
Posted by Peter Donald <do...@apache.org>.
Hi,
jspc task sounds useful and has been requested lots. Often the best way to
get something into ant is just to make lots and lots of noise ;) It is
possible that none of the committers would use it and thus are hesitant to
commit ;)
Would you mind submitting it again. (I fubarred my local archives not long
ago).
On Wed, 12 Sep 2001 14:07, 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
--
Cheers,
Pete
--------------------------------------------------------------
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it" -- Richard Feynman
--------------------------------------------------------------