You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/22 12:52:35 UTC
Javac task design problems
Let me give you some context: Cocoon has one of the most complex builds.
Our entire build files reached 250Kb. Half of which were dynamically
generated thru an XSLT transformation (for those optional modules we
call "blocks").
The build system was simply too complex to be maintained and I decided
to redesign it.
Build time went from 25 minutes to 5 minutes on my machine (a pentium II
366 ronzputer). Other people experienced equivalent speedups and
everybody is joyful, singing and dancing and with renewed faith on mankind.
Now, during refactoring, people started to question the need for copying
files in the build dirs when only a few required filtering because not
only the process uses time and disk space but because...
> you copy a source code filename from a stack trace, open the file,
> correct the bug and you're happy. Except you've been working on the copy
> from the build subdir, and on the next build your changes are gone.
I think almost all cocoon developers experienced the pain of this, so I
decided to design a 'copy-free' design. Unfortunately, I found out that
it's not so simple. And it's probably my fault!
Let me remember you that I'm the one responsible for the introduction of
the <filter> task and subsystem in Ant. The design pattern was:
1) prepare the build by copying the source files (so that filter acts)
2) compile the filtered version
I was perfectly aware of the fact that this doubled the use of disk
space, but disk space is not that big of a problem nowadays so I decided
not to care (and nobody complained).
But the 'lost-update' issue is a much more serious one. Dead serious, I
might say, the problem is that the way the javac task is designed
(again, it could well be my fault since I enhanced that task a lot in
the past) is that is path based.
Now, suppose that you have a codebase with 580 java files, but only one
of them "Constants.java" requires filtering (for stuff like @version@
and @year@).
The ideal solution to the problem (without requiring to filter
everything out would be)
<copy todir="${build.src}" filtering="on">
<fileset dir="${src}">
<include name="**/Constants.java"/>
</fileset>
</copy>
<javac destdir="${build.dest}">
<src>
<fileset dir="${src}">
<exclude name="**/Constants.java"/>
</fileset>
<path location="${build.src}"/>
</src>
</javac>
too bad it doesn't work because the <javac> tasks assumes that each file
in its fileset is a directory!
Now: did I overlook something or javac has to be modified to allow this
to happen?
[please, keep me CC-ed since I'm not subscribed to ant-dev. Thank you]
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Problem using Ant install command
Posted by Parimah MehrRostami <pa...@hotmail.com>.
Hi everyone.
I have installed Apache Tomcat 4.06. Have been successful running the
examples. Tried to build my own servlet by creating the following
c:\my <--- index.html
c:\my\web <---- same copy of index.html (!!!)
c:\my\src <--- LoginServlet.Java
Using "ant install" I compiled the program fine which have created the following subdirs
c:\my\build\WEB-INF\classes <----- LoginServlet.class
c:\my\build\WEB-INF\lib <----- empty
When I check the Tomcat Manager "my" path has been installed but it has "stopped" status. So using manager tool, I remove and install it which changes the status to "running"- Great I am home free... Not really, when I goto http://localhost:8080/my I do get the login page but when I click on submit which should invoke ACTION=LoginServlet, I get the nasty
STATUS 404 - /build/LoginServlet
type Status report
message /build/LoginServlet
description The requested resource (/build/LoginServlet) is not available.
I have tried manually compiling the code and used Tomcat manager to install and run the servlet but the same result.
I have a feeling I am doing something very basic wrong. I have checked to see if others have had the same problem and I get pages and pages of search result and after checking 6 or 7 pages I gave up.
This is the only user group email I could find, have a feeling this is not a right place to send this problem to, but if anyone out there could show me the light or send me a user group email address which is the right one I would really appreciate it.
I have spend a few days trying to figure it out. Have messed around with build.xml, no good. Thought maybe I should add LoginServlet to servlet.xml but could not get result out of that one either.
Thanks
Parimah
Re: Javac task design problems
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Conor MacNeill" <co...@cortexebusiness.com.au>
Cc: "Ant Developers List" <de...@ant.apache.org>
Sent: Sunday, February 23, 2003 01:31
Subject: Re: Javac task design problems
> Conor MacNeill wrote:
> > Stefano Mazzocchi wrote:
> >
> >>
> >> Build time went from 25 minutes to 5 minutes on my machine (a pentium
> >> II 366 ronzputer). Other people experienced equivalent speedups and
> >> everybody is joyful, singing and dancing and with renewed faith on
> >> mankind.
> >
> >
> > If you keep that up, the government will declare it illegal.
>
> LOL :)
>
> >>
> >> The ideal solution to the problem (without requiring to filter
> >> everything out would be)
> >>
> >> <copy todir="${build.src}" filtering="on">
> >> <fileset dir="${src}">
> >> <include name="**/Constants.java"/>
> >> </fileset>
> >> </copy>
> >>
> >> <javac destdir="${build.dest}">
> >> <src>
> >> <fileset dir="${src}">
> >> <exclude name="**/Constants.java"/>
> >> </fileset>
> >> <path location="${build.src}"/>
> >> </src>
> >> </javac>
> >>
> >> too bad it doesn't work because the <javac> tasks assumes that each
> >> file in its fileset is a directory!
> >
> >
> > Not quite true, I think. The problem is more likely to come from javac
> > itself since it will go looking for files based on the source paths.
>
> then how do the exclude/include work?
>
> > IOW, there is a disconnect between javac the task and javac the
compiler.
>
> Did you guys ever thought about usign the Eclipse java compiler? It's
> *very* nice, fast as hell and entirely embeddable and incremental. Plus
> is IBM public license so its totally legal to redistribute with Ant.
>
> > Why not this:
> > <javac destdir="${build.dest}">
> > <src>
> > <path location="${build.src}"/>
> > <path location="${src}"/>
> > </src>
> > </javac>
> >
> > That should cause javac to pick up the changed files first and ignore
> > the other copy in src. Well I haven't tried it, so YMMV ...
>
> Nop, tried that and doesn't work. Javac tries to compile both copies of
> the file, complians about the duplication and fails.
Why have Constants.java in the primary source tree at all? Keep it somewhere
else, copy/filter/autocreate it in build/generated alongside all the castor,
axis, and xdoclet generated source
Re: Javac task design problems
Posted by Stefano Mazzocchi <st...@apache.org>.
Conor MacNeill wrote:
> Stefano Mazzocchi wrote:
>
>>
>> Build time went from 25 minutes to 5 minutes on my machine (a pentium
>> II 366 ronzputer). Other people experienced equivalent speedups and
>> everybody is joyful, singing and dancing and with renewed faith on
>> mankind.
>
>
> If you keep that up, the government will declare it illegal.
LOL :)
>>
>> The ideal solution to the problem (without requiring to filter
>> everything out would be)
>>
>> <copy todir="${build.src}" filtering="on">
>> <fileset dir="${src}">
>> <include name="**/Constants.java"/>
>> </fileset>
>> </copy>
>>
>> <javac destdir="${build.dest}">
>> <src>
>> <fileset dir="${src}">
>> <exclude name="**/Constants.java"/>
>> </fileset>
>> <path location="${build.src}"/>
>> </src>
>> </javac>
>>
>> too bad it doesn't work because the <javac> tasks assumes that each
>> file in its fileset is a directory!
>
>
> Not quite true, I think. The problem is more likely to come from javac
> itself since it will go looking for files based on the source paths.
then how do the exclude/include work?
> IOW, there is a disconnect between javac the task and javac the compiler.
Did you guys ever thought about usign the Eclipse java compiler? It's
*very* nice, fast as hell and entirely embeddable and incremental. Plus
is IBM public license so its totally legal to redistribute with Ant.
> Why not this:
> <javac destdir="${build.dest}">
> <src>
> <path location="${build.src}"/>
> <path location="${src}"/>
> </src>
> </javac>
>
> That should cause javac to pick up the changed files first and ignore
> the other copy in src. Well I haven't tried it, so YMMV ...
Nop, tried that and doesn't work. Javac tries to compile both copies of
the file, complians about the duplication and fails.
> BTW, the other thing to consider is why you need to copy and filter at
> all at the java source level. Ant's own build approach is to stick all
> that sort of stuff in a resource and filter it.
yeah, well, if I start fixing all those things in half a million lines
of code, I will never finish :)
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Javac task design problems
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Stefano Mazzocchi wrote:
>
> Build time went from 25 minutes to 5 minutes on my machine (a pentium II
> 366 ronzputer). Other people experienced equivalent speedups and
> everybody is joyful, singing and dancing and with renewed faith on mankind.
If you keep that up, the government will declare it illegal.
>
> The ideal solution to the problem (without requiring to filter
> everything out would be)
>
> <copy todir="${build.src}" filtering="on">
> <fileset dir="${src}">
> <include name="**/Constants.java"/>
> </fileset>
> </copy>
>
> <javac destdir="${build.dest}">
> <src>
> <fileset dir="${src}">
> <exclude name="**/Constants.java"/>
> </fileset>
> <path location="${build.src}"/>
> </src>
> </javac>
>
> too bad it doesn't work because the <javac> tasks assumes that each file
> in its fileset is a directory!
Not quite true, I think. The problem is more likely to come from javac
itself since it will go looking for files based on the source paths. IOW,
there is a disconnect between javac the task and javac the compiler.
Why not this:
<javac destdir="${build.dest}">
<src>
<path location="${build.src}"/>
<path location="${src}"/>
</src>
</javac>
That should cause javac to pick up the changed files first and ignore the
other copy in src. Well I haven't tried it, so YMMV ...
BTW, the other thing to consider is why you need to copy and filter at all
at the java source level. Ant's own build approach is to stick all that sort
of stuff in a resource and filter it.
Conor
RE: Javac task design problems
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> Or, if filtering is removed (didn't follow the ongoing discussion), this
> can be used to exclude source files specific to a particular JDK version.
>
Yes, filtering has been removed - we don't need it any more and therefore
we don't copy any source files anymore. This is not only a faster building
time, but it makes it also much easier to directly compile the cocoon code
inside any(?) ide.
Carsten
Re: Javac task design problems
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
<snip/>
> The ideal solution to the problem (without requiring to filter
> everything out would be)
>
> <copy todir="${build.src}" filtering="on">
> <fileset dir="${src}">
> <include name="**/Constants.java"/>
> </fileset>
> </copy>
>
> <javac destdir="${build.dest}">
> <src>
> <fileset dir="${src}">
> <exclude name="**/Constants.java"/>
> </fileset>
> <path location="${build.src}"/>
> </src>
> </javac>
>
> too bad it doesn't work because the <javac> tasks assumes that each
> file in its fileset is a directory!
Fortunately, it *does* work ;-)
Read Ant's javac task documentation and you will see that it supports
includes and exclude patterns.
I checked if the doc is right (you never know ;) with the following
change on build.xml (added the <exclude>) and it works just fine :
<!-- compile core source files -->
<javac destdir="${build.dest}"
debug="${compiler.debug}"
optimize="${compiler.optimize}"
deprecation="${compiler.deprecation}"
target="${target.vm}"
nowarn="${compiler.nowarn}"
compiler="${compiler}"
classpathref="classpath">
<src>
<!-- [FIXME] THE DEPENDENCY ON DEPRECATED SHOULD GO AWAY!!!! -->
<path location="${deprecated.src}"/>
<path location="${build.src}"/>
<path location="${java}"/>
</src>
<exclude name="org/apache/cocoon/acting/Request*.java"/>
</javac>
This means that we can handle source files filtering without copying the
full source tree : only filter those files that require it and exclude
them from the main source tree in the javac task.
Or, if filtering is removed (didn't follow the ongoing discussion), this
can be used to exclude source files specific to a particular JDK version.
Sylvain
(on vacation, trying to follow the huge flood with a slow modem)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Javac task design problems
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 24/02/2003 13.17:
> There are currently three properties used in Constants.java: the name,
> the copyright year and the version. Ok, the first one could be simply
> hard-coded because it is fixed. (And I think we can remove this name
> property completly from the build system).
>
> Now, if this is the only place in the java code where filters are
> used, I personally have no problems with
> hardcoding the version and the copyright in Constants.java, so that
> the filters are not required. This would (unfortunately) lead to
> the fact that we define these two pieces of information in two
> places and both have to be updated accordingly. But fortunately
> I'm currently doing the releases and I'm updating the information
> in the build files, so I can also update them in Constants.java
> as well. No problem.
>
> What do you think?
+1
Also, we should not use filtering for copyright years, they must be set
by hand, since CVS *does* deliver them, and without filtering.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Javac task design problems
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> > There are currently three properties used in Constants.java: the name,
> > the copyright year and the version. Ok, the first one could be simply
> > hard-coded because it is fixed. (And I think we can remove this name
> > property completly from the build system).
> >
> > Now, if this is the only place in the java code where filters are
> > used, I personally have no problems with
> > hardcoding the version and the copyright in Constants.java, so that
> > the filters are not required. This would (unfortunately) lead to
> > the fact that we define these two pieces of information in two
> > places and both have to be updated accordingly. But fortunately
> > I'm currently doing the releases and I'm updating the information
> > in the build files, so I can also update them in Constants.java
> > as well. No problem.
> >
> > What do you think?
>
> Besides the lack of elegance and the increased complexity of making the
> distribution, the real problem is the 'databases' block that uses source
> filtering. Also the other problem is the scratchpad which has so many
> dependencies on libraries that we can't ship, so it would be great to
> tell javac to skip those files if the library is not available but
> without having to copy them.
>
Ok, we should not mix the problems here - one is filtering and the other
one deals with libraries. I currently see now solution for the databases
block. Has anyone else a good suggestion here? I really don't have thought
about it, but would it help to split the source directory of the block
into three sections (common, jdk1.3 compliant, jdk1.4 compliant) and the
ant script only selects the correct directories for the sources (either
common and jdk1.3 or common and jdk1.4). Does this make sense?
Carsten
Re: Javac task design problems
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> There are currently three properties used in Constants.java: the name,
> the copyright year and the version. Ok, the first one could be simply
> hard-coded because it is fixed. (And I think we can remove this name
> property completly from the build system).
>
> Now, if this is the only place in the java code where filters are
> used, I personally have no problems with
> hardcoding the version and the copyright in Constants.java, so that
> the filters are not required. This would (unfortunately) lead to
> the fact that we define these two pieces of information in two
> places and both have to be updated accordingly. But fortunately
> I'm currently doing the releases and I'm updating the information
> in the build files, so I can also update them in Constants.java
> as well. No problem.
>
> What do you think?
Besides the lack of elegance and the increased complexity of making the
distribution, the real problem is the 'databases' block that uses source
filtering. Also the other problem is the scratchpad which has so many
dependencies on libraries that we can't ship, so it would be great to
tell javac to skip those files if the library is not available but
without having to copy them.
Chris, how complex would be to write new <javac> ant task using your
JavacAPI and the eclipse compiler? I think it could even speed up our
compilation times and memory usage.
Anybody else has ideas on how to solve this issue?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
RE: Javac task design problems
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
There are currently three properties used in Constants.java: the name,
the copyright year and the version. Ok, the first one could be simply
hard-coded because it is fixed. (And I think we can remove this name
property completly from the build system).
Now, if this is the only place in the java code where filters are
used, I personally have no problems with
hardcoding the version and the copyright in Constants.java, so that
the filters are not required. This would (unfortunately) lead to
the fact that we define these two pieces of information in two
places and both have to be updated accordingly. But fortunately
I'm currently doing the releases and I'm updating the information
in the build files, so I can also update them in Constants.java
as well. No problem.
What do you think?
Carsten
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Saturday, February 22, 2003 12:53 PM
> To: Apache Ant
> Cc: cocoon-dev@xml.apache.org
> Subject: Javac task design problems
>
>
> Let me give you some context: Cocoon has one of the most complex builds.
> Our entire build files reached 250Kb. Half of which were dynamically
> generated thru an XSLT transformation (for those optional modules we
> call "blocks").
>
> The build system was simply too complex to be maintained and I decided
> to redesign it.
>
> Build time went from 25 minutes to 5 minutes on my machine (a pentium II
> 366 ronzputer). Other people experienced equivalent speedups and
> everybody is joyful, singing and dancing and with renewed faith
> on mankind.
>
> Now, during refactoring, people started to question the need for copying
> files in the build dirs when only a few required filtering because not
> only the process uses time and disk space but because...
>
> > you copy a source code filename from a stack trace, open the file,
> > correct the bug and you're happy. Except you've been working on
> the copy
> > from the build subdir, and on the next build your changes are gone.
>
> I think almost all cocoon developers experienced the pain of this, so I
> decided to design a 'copy-free' design. Unfortunately, I found out that
> it's not so simple. And it's probably my fault!
>
> Let me remember you that I'm the one responsible for the introduction of
> the <filter> task and subsystem in Ant. The design pattern was:
>
> 1) prepare the build by copying the source files (so that filter acts)
> 2) compile the filtered version
>
> I was perfectly aware of the fact that this doubled the use of disk
> space, but disk space is not that big of a problem nowadays so I decided
> not to care (and nobody complained).
>
> But the 'lost-update' issue is a much more serious one. Dead serious, I
> might say, the problem is that the way the javac task is designed
> (again, it could well be my fault since I enhanced that task a lot in
> the past) is that is path based.
>
> Now, suppose that you have a codebase with 580 java files, but only one
> of them "Constants.java" requires filtering (for stuff like @version@
> and @year@).
>
> The ideal solution to the problem (without requiring to filter
> everything out would be)
>
> <copy todir="${build.src}" filtering="on">
> <fileset dir="${src}">
> <include name="**/Constants.java"/>
> </fileset>
> </copy>
>
> <javac destdir="${build.dest}">
> <src>
> <fileset dir="${src}">
> <exclude name="**/Constants.java"/>
> </fileset>
> <path location="${build.src}"/>
> </src>
> </javac>
>
> too bad it doesn't work because the <javac> tasks assumes that each file
> in its fileset is a directory!
>
> Now: did I overlook something or javac has to be modified to allow this
> to happen?
>
> [please, keep me CC-ed since I'm not subscribed to ant-dev. Thank you]
>
> --
> Stefano Mazzocchi <st...@apache.org>
> Pluralitas non est ponenda sine necessitate [William of Ockham]
> --------------------------------------------------------------------
>
>
RE: Javac task design problems
Posted by didge <di...@foundrylogic.com>.
> Oh, and how about "stale" files. I mean, if I vppcopy a file, then
> delete the original vpp, is the filtered resulting java file still
> there? IIRC there was a lsync task floating around that synched
> correctly, maybe a vppsynch could be the *final* solution?
Yes, if you use <vpp> (see vpp.sourceforge.net), to preprocess .java.vpp
files to .java files, and then delete a source .java.vpp, the corresponding
.java file becomes 'stale' as you describe and will sit in your gen
directory until it is cleared out. This is also true with <vppjavac>.
Another artifact of not having preprocessing integrated into JavaTM :(
It's funny you should ask this. The other night I spent a couple hours
thinking about this and before realizing that ant can better do this already
without any additional work on vpp's part.
Generally, it's easy enough to clean the gen directory completely and
rebuild, thus purging any stale files, along with everything else. But if
for some reason you don't want to purge everything, then a combination of
<delete>, <fileset>, <present>, <mapper> and will remove the stale files
nicely.
I've never actually needed to do this before, but just for fun, I created an
example that shows how such a purge of stale files might be done:
<project name="purge" default="purge" basedir=".">
<target name="purge">
<mkdir dir="gen"/>
<mkdir dir="src"/>
<echo file="gen/deleteme.java" message="Delete me!"/>
<echo file="gen/foo.java" message="Don't delete me!"/>
<echo file="src/foo.java.vpp" message="Don't delete me!"/>
<delete>
<fileset dir="gen" includes="**/*.java">
<present present="srconly" targetdir="src">
<mapper type="glob" from="*.java" to="*.java.vpp"/>
</present>
</fileset>
</delete>
</target>
</project>
didge
RE: Javac task design problems
Posted by didge <di...@foundrylogic.com>.
> Oh, and how about "stale" files. I mean, if I vppcopy a file, then
> delete the original vpp, is the filtered resulting java file still
> there? IIRC there was a lsync task floating around that synched
> correctly, maybe a vppsynch could be the *final* solution?
Yes, if you use <vpp> (see vpp.sourceforge.net), to preprocess .java.vpp
files to .java files, and then delete a source .java.vpp, the corresponding
.java file becomes 'stale' as you describe and will sit in your gen
directory until it is cleared out. This is also true with <vppjavac>.
Another artifact of not having preprocessing integrated into JavaTM :(
It's funny you should ask this. The other night I spent a couple hours
thinking about this and before realizing that ant can better do this already
without any additional work on vpp's part.
Generally, it's easy enough to clean the gen directory completely and
rebuild, thus purging any stale files, along with everything else. But if
for some reason you don't want to purge everything, then a combination of
<delete>, <fileset>, <present>, <mapper> and will remove the stale files
nicely.
I've never actually needed to do this before, but just for fun, I created an
example that shows how such a purge of stale files might be done:
<project name="purge" default="purge" basedir=".">
<target name="purge">
<mkdir dir="gen"/>
<mkdir dir="src"/>
<echo file="gen/deleteme.java" message="Delete me!"/>
<echo file="gen/foo.java" message="Don't delete me!"/>
<echo file="src/foo.java.vpp" message="Don't delete me!"/>
<delete>
<fileset dir="gen" includes="**/*.java">
<present present="srconly" targetdir="src">
<mapper type="glob" from="*.java" to="*.java.vpp"/>
</present>
</fileset>
</delete>
</target>
</project>
didge
Re: Javac task design problems
Posted by Nicola Ken Barozzi <ni...@apache.org>.
(ccing to cocoondev to see if they like the idea)
(ccing to krysalis-dev because it seems like the solution to the
jdk filtering stuff)
didge wrote, On 24/02/2003 22.23:
>>But the 'lost-update' issue is a much more serious one. Dead serious, I
>>might say, the problem is that the way the javac task is designed
>>(again, it could well be my fault since I enhanced that task a lot in
>>the past) is that is path based.
>
>
> The problem is not with the <javac> task, it is with JavaTM itself. I've
> said it on this list before, I know, but I just can't stop myself...
>
> <soapbox>
> JavaTM <em>needs</em> an integrated preprocessor.
> Without anyway to instruct IDEs (such as with a #line directive),
> IDEs simply cannot distinguish between the preprocessed and source
> files, leaving developers to figure it out themselves.
> </soapbox>
This is IMHO a *very* good point. If I see a .java file, I assume that I
can compile it with javac, but with filtering it's not the case! I agree
with you.
...
> 1. Any file that needs preprocessing gets a .java.vpp extension.
> 2. Preprocess all files with the .java.vpp extension sending output to an
> gen directory _not_ in your regular source directory.
> 3. Compile everything normally, including the gen directory as an additional
> src path.
>
> Using the extension both identifies the file as needing preprocessing and
> also prevents it from being compiled directly.
Yes. And also makes it automatic. I mean that we son't need to copy
*all* files, or select them one by one by hand. Simple, clean effective.
I like it :-)
Oh, and how about "stale" files. I mean, if I vppcopy a file, then
delete the original vpp, is the filtered resulting java file still
there? IIRC there was a lsync task floating around that synched
correctly, maybe a vppsynch could be the *final* solution?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Javac task design problems
Posted by Nicola Ken Barozzi <ni...@apache.org>.
(ccing to cocoondev to see if they like the idea)
(ccing to krysalis-dev because it seems like the solution to the
jdk filtering stuff)
didge wrote, On 24/02/2003 22.23:
>>But the 'lost-update' issue is a much more serious one. Dead serious, I
>>might say, the problem is that the way the javac task is designed
>>(again, it could well be my fault since I enhanced that task a lot in
>>the past) is that is path based.
>
>
> The problem is not with the <javac> task, it is with JavaTM itself. I've
> said it on this list before, I know, but I just can't stop myself...
>
> <soapbox>
> JavaTM <em>needs</em> an integrated preprocessor.
> Without anyway to instruct IDEs (such as with a #line directive),
> IDEs simply cannot distinguish between the preprocessed and source
> files, leaving developers to figure it out themselves.
> </soapbox>
This is IMHO a *very* good point. If I see a .java file, I assume that I
can compile it with javac, but with filtering it's not the case! I agree
with you.
...
> 1. Any file that needs preprocessing gets a .java.vpp extension.
> 2. Preprocess all files with the .java.vpp extension sending output to an
> gen directory _not_ in your regular source directory.
> 3. Compile everything normally, including the gen directory as an additional
> src path.
>
> Using the extension both identifies the file as needing preprocessing and
> also prevents it from being compiled directly.
Yes. And also makes it automatic. I mean that we son't need to copy
*all* files, or select them one by one by hand. Simple, clean effective.
I like it :-)
Oh, and how about "stale" files. I mean, if I vppcopy a file, then
delete the original vpp, is the filtered resulting java file still
there? IIRC there was a lsync task floating around that synched
correctly, maybe a vppsynch could be the *final* solution?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Javac task design problems
Posted by didge <di...@foundrylogic.com>.
> But the 'lost-update' issue is a much more serious one. Dead serious, I
> might say, the problem is that the way the javac task is designed
> (again, it could well be my fault since I enhanced that task a lot in
> the past) is that is path based.
The problem is not with the <javac> task, it is with JavaTM itself. I've
said it on this list before, I know, but I just can't stop myself...
<soapbox>
JavaTM <em>needs</em> an integrated preprocessor.
Without anyway to instruct IDEs (such as with a #line directive),
IDEs simply cannot distinguish between the preprocessed and source
files, leaving developers to figure it out themselves.
</soapbox>
Short of modifying javac, there is no real solution to this. My projects
that require preprocessing use one of two strategies:
1. Use preprocessing on all files in the project.
2. Separate, by extension, those java source files in the project that
require preprocessing and handle them separately before compiling everything
else.
I use 1 when virtually every file in a project requires preprocessing (think
jdbc) and 2 when only a few files do, such as a Constants.java file.
To handle the first strategy, I just replace <javac> with <vppjavac> (see
vpp.sourceforge.net) which nicely handles my preprocessing needs.
For the second strategy:
1. Any file that needs preprocessing gets a .java.vpp extension.
2. Preprocess all files with the .java.vpp extension sending output to an
gen directory _not_ in your regular source directory.
3. Compile everything normally, including the gen directory as an additional
src path.
Using the extension both identifies the file as needing preprocessing and
also prevents it from being compiled directly.
Changes of course can still be made to the generated code, but at least they
will have to be made to a file outside the normal source directory path,
cluing you into the fact that the file was preprocessed. I also include a
comment in the file that says something to the effect, "This file was
preprocessed, changes made to it will be lost, the source for this file is
located at ...".
Here's essentially the kind of target I use for building:
<target name="build" >
<vpp todir="gen" overwrite="true">
<fileset dir="src" includes="**/*.java.vpp"/>
<mapper type="glob" from="*.java.vpp" to="*.java"/>
</vpp>
<javac destdir="build/classes">
<src path="src"/>
<src path="gen"/>
</javac>
</target>
I used <vpp>, but I'm sure this example could be easily changed to use a
<copy> with filtering, as well.
didge