You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/20 21:44:50 UTC
The new build system
The new build system has landed on CVS.
Do a 'cvs update' to get it.
I've done major refactoring of almost everything touched, so things
might be a little shaky for a while. I copied the old build into
build.old.xml so that I can copy/paste the stuff that is missing in the
next days.
I wanted to release early so that you people can play with it.
For the record, I went from some 20 minutes down to 3 minutes and 20
seconds on my machine simply by tweaking the ant dependencies and using
ant better.
Since I normally work on a pentium II 366 you guys should see even
faster build times, expecially after the first run.
I suggest you to:
read BUILD.txt
cp blocks.properties local.blocks.properties
cp build.properties local.build.properties
[modify the local copies as you like, leaving the original intact]
build webapp [this will generate the webapp]
build run [this will run jetty]
the fire your browser to http://localhost:8888
I tweaked jetty to be as small as possible. I'm now able to get a cocoon
up and running with as low as 22 Mb memory!
If you exclude all blocks from build, the resulting webapp is the
cleanest possible.
This should make many of you happy.
now, off for a drink :)
ciao
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Leszek Gawron wrote:
>>
>>> On czw, lut 20, 2003 at 09:44:50 +0100, Stefano Mazzocchi wrote:
>>>
>>>
>>>> The new build system has landed on CVS.
>>>>
>>>> Do a 'cvs update' to get it.
>>>>
>>>> I've done major refactoring of almost everything touched, so things
>>>> might be a little shaky for a while. I copied the old build into
>>>> build.old.xml so that I can copy/paste the stuff that is missing in
>>>> the next days.
>>>>
>>>> I wanted to release early so that you people can play with it.
>>>>
>>>
>>>
>>> I'm getting this error when building databases block
>>> databases-compile:
>>> Copying 40 files to
>>> C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src
>>>
>>>
>>
>> While we're at refactoring the build system, what's the real need for
>> _copying_ the source files before compiling them ? AFAIK, only a few
>> files really need Ant preprocessing : these are the ones that deal
>> with JDBC 2/JDBC 3 incompatibilities.
>
>
> Good point.
>
>> We could compile all source files in their home location _except_
>> those that require preprocessing that would follow the current but
>> time-consuming copy process. This would shorten the edit/compile/test
>> cycle and avoid something that happens to me quite often : editing
>> source files in the build directory !
>
>
> You are absolutely right (all but in one thing, copying is done only
> once).
I was referring to the copy of _modified_ files, which are precisely
those that you want to be recompiled ;-)
> I'll try to do that ASAP.
Cool !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> On czw, lut 20, 2003 at 09:44:50 +0100, Stefano Mazzocchi wrote:
>>
>>
>>> The new build system has landed on CVS.
>>>
>>> Do a 'cvs update' to get it.
>>>
>>> I've done major refactoring of almost everything touched, so things
>>> might be a little shaky for a while. I copied the old build into
>>> build.old.xml so that I can copy/paste the stuff that is missing in
>>> the next days.
>>>
>>> I wanted to release early so that you people can play with it.
>>>
>>
>> I'm getting this error when building databases block
>> databases-compile:
>> Copying 40 files to
>> C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src
>>
>
> While we're at refactoring the build system, what's the real need for
> _copying_ the source files before compiling them ? AFAIK, only a few
> files really need Ant preprocessing : these are the ones that deal with
> JDBC 2/JDBC 3 incompatibilities.
Good point.
> We could compile all source files in their home location _except_ those
> that require preprocessing that would follow the current but
> time-consuming copy process. This would shorten the edit/compile/test
> cycle and avoid something that happens to me quite often : editing
> source files in the build directory !
You are absolutely right (all but in one thing, copying is done only once).
I'll try to do that ASAP.
> I'm currently lacking time to dive in this stuff now...
>
> Keep up the good work !
thank you.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ovidiu Predescu wrote:
> If you're an Emacs user it's trivial to set it up to automatically copy
> the file from the source directory in the build area. This way you edit
> the source file and when you save it, it's automatically updated in the
> running system.
I have a slightly modified compile function which checks if there
is a "\build\" in the error message, and if there is a file without
the build path element, it is thrown out.
I really love IDEs which can be configured to do everything imaginable...
J.Pietschmann
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
Javac task design problems
Posted by Stefano Mazzocchi <st...@apache.org>.
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]
--------------------------------------------------------------------
Javac task design problems
Posted by Stefano Mazzocchi <st...@apache.org>.
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: The new build system
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Samedi, 22 fév 2003, à 06:37 Europe/Zurich, Ovidiu Predescu a écrit :
> ....If you're an Emacs user...
not yet, but you're tempting us regularly, so it might happen sooner or
later ;-)
> ... This way you edit the source file and when you save it, it's
> automatically updated in the running system...
Cool. I think Sylvain was mentioning another scenario, however, like:
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.
But as I understand Emacs would make it easy to handle this case too,
maybe with a warning if you open a file that has "build" in the
pathname...
-Bertrand
Re: The new build system
Posted by Ovidiu Predescu <ov...@apache.org>.
First of all, great job Stefano! We certainly needed something like
this, it got to the point where was unbearably slow to develop anything
:(
On Friday, Feb 21, 2003, at 06:35 US/Pacific, Bertrand Delacretaz wrote:
>> ...This would shorten the edit/compile/test cycle and avoid something
>> that happens to me quite often : editing source files in the build
>> directory !
>
> I know what you feel, Sylvain. Been there ;-)
If you're an Emacs user it's trivial to set it up to automatically copy
the file from the source directory in the build area. This way you edit
the source file and when you save it, it's automatically updated in the
running system.
I'm using this setup with flow scripts, which are reloaded
automatically in the running system if they're modified on the disk. It
makes implementing applications a real breeze.
Let me know if you're interested in this setup, and I'll email you the
configuration.
Cheers,
Ovidiu
Re: The new build system
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> ...This would shorten the edit/compile/test cycle and avoid something
> that happens to me quite often : editing source files in the build
> directory !
I know what you feel, Sylvain. Been there ;-)
-Bertrand
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Leszek Gawron wrote:
>On czw, lut 20, 2003 at 09:44:50 +0100, Stefano Mazzocchi wrote:
>
>
>>The new build system has landed on CVS.
>>
>>Do a 'cvs update' to get it.
>>
>>I've done major refactoring of almost everything touched, so things
>>might be a little shaky for a while. I copied the old build into
>>build.old.xml so that I can copy/paste the stuff that is missing in the
>>next days.
>>
>>I wanted to release early so that you people can play with it.
>>
>>
>I'm getting this error when building databases block
>databases-compile:
>Copying 40 files to C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src
>
While we're at refactoring the build system, what's the real need for
_copying_ the source files before compiling them ? AFAIK, only a few
files really need Ant preprocessing : these are the ones that deal with
JDBC 2/JDBC 3 incompatibilities.
We could compile all source files in their home location _except_ those
that require preprocessing that would follow the current but
time-consuming copy process. This would shorten the edit/compile/test
cycle and avoid something that happens to me quite often : editing
source files in the build directory !
I'm currently lacking time to dive in this stuff now...
Keep up the good work !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> ...BUILD FAILED
> file:///Users/jermq/Checkouts/Secure/xml-cocoon2/build.xml:669:
> IOException: java.io.FileNotFoundException:
> /Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/webapp/
> samples/sitemap.xmap (No such file or directory)
>
Same here, but I'm out of time to investigate further today.
-Bertrand
Re: The new build system
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, February 21, 2003, at 12:58 PM, Jeremy Quinn wrote:
>
> On Friday, February 21, 2003, at 12:41 PM, Bertrand Delacretaz wrote:
>
>>
>> Le Vendredi, 21 fév 2003, à 13:36 Europe/Zurich, Jeremy Quinn a écrit
>> :
>>> ...
>>> #exclude.webapp.documentation=true
>>> #exclude.webapp.javadocs=true
>>> ...
>>> these are not excluding individual 'blocks' ....
>>
>> Just have a look at "blocks.properties" instead of "build.properties"
OK, I worked my way through, un-commenting the following to get rid of
compile errors:
exclude.block.databases=true
exclude.block.jsp=true
exclude.block.php=true
exclude.block.python=true
exclude.block.web3=true
but get this final build error:
BUILD FAILED
file:///Users/jermq/Checkouts/Secure/xml-cocoon2/build.xml:669:
IOException: java.io.FileNotFoundException:
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/webapp/
samples/sitemap.xmap (No such file or directory)
There is no 'samples' directory in 'build/cocoon-2.1-dev/webapp'.
I actually need the 'databases' block in my projects, what do I need to
do to get it to compile? Is this a problem with the 'mocks'?
thanks
regards Jeremy
Re: The new build system
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, February 21, 2003, at 12:41 PM, Bertrand Delacretaz wrote:
>
> Le Vendredi, 21 fév 2003, à 13:36 Europe/Zurich, Jeremy Quinn a écrit :
>> ...
>> #exclude.webapp.documentation=true
>> #exclude.webapp.javadocs=true
>> ...
>> these are not excluding individual 'blocks' ....
>
> Just have a look at "blocks.properties" instead of "build.properties"
> ;-)
>
> -Bertrand
>
Ugh!!
Thanks ;)
regards Jeremy
Re: The new build system
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 21 fév 2003, à 13:36 Europe/Zurich, Jeremy Quinn a écrit :
> ...
> #exclude.webapp.documentation=true
> #exclude.webapp.javadocs=true
> ...
> these are not excluding individual 'blocks' ....
Just have a look at "blocks.properties" instead of "build.properties"
;-)
-Bertrand
Re: The new build system
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, February 21, 2003, at 10:31 AM, Stefano Mazzocchi wrote:
> Josema Alonso wrote:
>> Stupid me, I forgot the way properties go in command line. I'm so bad
>> at
>> syntax at times...
>> Please, forgive me.
>> The right way is:
>> build webapp -Dexclude.block.databases=yes
>> But this doesn't build either cause it stops at the jsp, php, python,
>> web3
>> blocks. I've tried then:
>> build
>> webapp -Dexclude.block.databases=yes -Dexclude.block.jsp=yes
>> -Dexclude.block
>> .php=yes -Dexclude.block.python=yes -Dexclude.block.web3=yes
>> But it doesn't work either. It seems it doesn't like more than three
>> properties in the command line as it is ignoring the last one and
>> stopping
>> when building web3 block. It doesn't mind if If I change the order of
>> the
>> properties, it always ignores the last one.
>> I'll keep on trying...
>
> The intended way of removing blocks is to
>
> 1) copy blocks.properties -> local.blocks.properties
> 2) uncomment all the excludes
> 3) build
>
> I've tried to remove the need for command line parameter passing.
Sorry Stefano, I don't understand what you mean here.
#exclude.webapp.documentation=true
#exclude.webapp.javadocs=true
#exclude.webapp.scratchpad=true
#exclude.webapp.samples=true
#exclude.webapp.libs=true
#exclude.scratchpad=true
#exclude.deprecated=true
these are not excluding individual 'blocks' ....
regards Jeremy
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Josema Alonso wrote:
> Stupid me, I forgot the way properties go in command line. I'm so bad at
> syntax at times...
> Please, forgive me.
>
> The right way is:
> build webapp -Dexclude.block.databases=yes
>
> But this doesn't build either cause it stops at the jsp, php, python, web3
> blocks. I've tried then:
> build
> webapp -Dexclude.block.databases=yes -Dexclude.block.jsp=yes -Dexclude.block
> .php=yes -Dexclude.block.python=yes -Dexclude.block.web3=yes
>
> But it doesn't work either. It seems it doesn't like more than three
> properties in the command line as it is ignoring the last one and stopping
> when building web3 block. It doesn't mind if If I change the order of the
> properties, it always ignores the last one.
>
> I'll keep on trying...
The intended way of removing blocks is to
1) copy blocks.properties -> local.blocks.properties
2) uncomment all the excludes
3) build
I've tried to remove the need for command line parameter passing.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system
Posted by Josema Alonso <jo...@simbiosystems.com>.
Stupid me, I forgot the way properties go in command line. I'm so bad at
syntax at times...
Please, forgive me.
The right way is:
build webapp -Dexclude.block.databases=yes
But this doesn't build either cause it stops at the jsp, php, python, web3
blocks. I've tried then:
build
webapp -Dexclude.block.databases=yes -Dexclude.block.jsp=yes -Dexclude.block
.php=yes -Dexclude.block.python=yes -Dexclude.block.web3=yes
But it doesn't work either. It seems it doesn't like more than three
properties in the command line as it is ignoring the last one and stopping
when building web3 block. It doesn't mind if If I change the order of the
properties, it always ignores the last one.
I'll keep on trying...
Josema.
----- Original Message -----
From: "Josema Alonso" <jo...@simbiosystems.com>
To: <co...@xml.apache.org>
Sent: Friday, February 21, 2003 12:56 AM
Subject: Re: The new build system
> I have the very same problem.
> I'm wondering if it's possible to skip that or any other block builds and
> what's the syntax.
>
> Maybe something like: build webapp exclude.databases.block
> Am I close to it at least?
>
> Thanks.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Leszek Gawron <ou...@vip.net.pl>.
On pią, lut 21, 2003 at 12:56:49 +0100, Josema Alonso wrote:
> I have the very same problem.
> I'm wondering if it's possible to skip that or any other block builds and
> what's the syntax.
>
> Maybe something like: build webapp exclude.databases.block
> Am I close to it at least?
you have to edit blocks.properties file
but for me excluding database block is not a solution because this block is
the only one I use apart from pure core
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Josema Alonso <jo...@simbiosystems.com>.
I have the very same problem.
I'm wondering if it's possible to skip that or any other block builds and
what's the syntax.
Maybe something like: build webapp exclude.databases.block
Am I close to it at least?
Thanks.
----- Original Message -----
From: "Leszek Gawron" <ou...@vip.net.pl>
To: <co...@xml.apache.org>
Sent: Friday, February 21, 2003 12:37 AM
Subject: Re: The new build system
> I'm getting this error when building databases block
> databases-compile:
> Copying 40 files to
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src
> Copying 1 file to
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\dest
> Reading:
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\classes\org\apache\cocoo
n\cocoon.roles
> Processing:
C:\Dev\CVSProjects\xml-cocoon2\src\blocks\databases\conf\db-modules.xroles
> Writing:
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\classes\org\apache\cocoo
n\cocoon.roles
> Compiling 40 source files to
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\dest
>
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org
\apache\cocoon\acting\OraAddAction.java:53:
> package oracle.jdbc does not exist
> import oracle.jdbc.OracleResultSet;
> ^
>
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org
\apache\cocoon\acting\OraAddAction.java:54:
> package oracle.sql does not exist
> import oracle.sql.BLOB;
> ^
>
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org
\apache\cocoon\acting\OraAddAction.java:55:
> package oracle.sql does not exist
> import oracle.sql.CLOB;
> ^
>
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org
\apache\cocoon\acting\OraAddAction.java:187:
> cannot resolve symbol
> symbol : class OracleResultSet
> location: class org.apache.cocoon.acting.OraAddAction
> OracleResultSet set = (OracleResultSet)
LOBstatement.executeQuery();
> and so on
>
> ouzo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Leszek Gawron <ou...@vip.net.pl>.
On czw, lut 20, 2003 at 09:44:50 +0100, Stefano Mazzocchi wrote:
> The new build system has landed on CVS.
>
> Do a 'cvs update' to get it.
>
> I've done major refactoring of almost everything touched, so things
> might be a little shaky for a while. I copied the old build into
> build.old.xml so that I can copy/paste the stuff that is missing in the
> next days.
>
> I wanted to release early so that you people can play with it.
I'm getting this error when building databases block
databases-compile:
Copying 40 files to C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src
Copying 1 file to C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\dest
Reading: C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\classes\org\apache\cocoon\cocoon.roles
Processing: C:\Dev\CVSProjects\xml-cocoon2\src\blocks\databases\conf\db-modules.xroles
Writing: C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\classes\org\apache\cocoon\cocoon.roles
Compiling 40 source files to C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\dest
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org\apache\cocoon\acting\OraAddAction.java:53:
package oracle.jdbc does not exist
import oracle.jdbc.OracleResultSet;
^
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org\apache\cocoon\acting\OraAddAction.java:54:
package oracle.sql does not exist
import oracle.sql.BLOB;
^
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org\apache\cocoon\acting\OraAddAction.java:55:
package oracle.sql does not exist
import oracle.sql.CLOB;
^
C:\Dev\CVSProjects\xml-cocoon2\build\cocoon-2.1-dev\blocks\databases\src\org\apache\cocoon\acting\OraAddAction.java:187:
cannot resolve symbol
symbol : class OracleResultSet
location: class org.apache.cocoon.acting.OraAddAction
OracleResultSet set = (OracleResultSet) LOBstatement.executeQuery();
and so on
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Upayavira <uv...@upaya.co.uk>.
> I just downloaded the lastest CVS for 2.1 (see timestamp of the mail),
> but I got this error:
As others have said, Stephano hasn't yet finished the samples. Therefore you need to
uncomment the line:
exclude.webapp.samples=true
in your build.properties or your local.build.properties.
Regards, Upayavira
Re: The new build system
Posted by David Crossley <cr...@indexgeo.com.au>.
Antonio Gallardo wrote:
> David Crossley dijo:
> > Antonio Gallardo wrote:
> > <snip/>
> >> Sorry, but I have another problem (see below).
> >
> > Thanks Antonio, i just fixed the broken xml comments
> > in cocoon.xconf ... so now you can proceed with
> > testing the new build system.
> >
> > It finally compiles the webapp, so i am off to do
> > 'build run'.
> > --David
>
> The best of Cocoon Comunity is the 24 hours support!
> This is great! Thanks David for fix the bug!
Yes, open source is brilliant. It is good for everyone
to dive in and fix bugs to keep the testing happening
around the clock.
> By the way, now a after the "./build.sh clean", a full build
> takes just 1 min 39 secs! This is amazing!
>
> Thanks Stefano again!
Hooray.
I would also like to specifically thank Nicola Ken
for his tireless work on the build system leading
up to this.
> And thanks to people that switched Cocoon from the
> fat Tomcat to the slim Jetty!
Yes ... even though the only thing that i have
seen is the error message below.
> I think I will throw the Tomcat book I buyed
> ;-)
>
> Best Regards,
>
> Antonio Gallardo
>
> P.S: I finally can build the cocoon. Now the problem is when I launch:
>
> ./build.sh run
>
> jetty starts, but when I point the browser to http://locahost:8888/ (as
> Stefano suggested) I got:
>
> Not allowed to define mixed content in the element cocoon at
> file:/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:23
Me too. I have no idea what that error is about.
I added a basic RELAX NG validation into my build, but
it did not reveal any error with current cocoon.xconf
--David
Re: The new build system
Posted by Ugo Cei <u....@cbim.it>.
Antonio Gallardo wrote:
> P.S: I finally can build the cocoon. Now the problem is when I launch:
>
> ./build.sh run
>
> jetty starts, but when I point the browser to http://locahost:8888/ (as
> Stefano suggested) I got:
>
> Not allowed to define mixed content in the element cocoon at
> file:/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:23
I get the same error, but I worked around it by copying my old
cocoon.xconf in place of the one provided.
Ugo
Re: The new build system
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
David Crossley dijo:
> Antonio Gallardo wrote:
> <snip/>
>> Sorry, but I have another problem (see below).
>
> Thanks Antonio, i just fixed the broken xml comments
> in cocoon.xconf ... so now you can proceed with
> testing the new build system.
>
> It finally compiles the webapp, so i am off to do
> 'build run'.
> --David
The best of Cocoon Comunity is the 24 hours support! This is great! Thanks
David for fix the bug!
By the way, now a after the "./build.sh clean", a full build takes just 1
min 39 secs! This is amazing!
Thanks Stefano again! And thanks to people that switched Cocoon from the
fat Tomcat to the slim Jetty! I think I will throw the Tomcat book I buyed
;-)
Best Regards,
Antonio Gallardo
P.S: I finally can build the cocoon. Now the problem is when I launch:
./build.sh run
jetty starts, but when I point the browser to http://locahost:8888/ (as
Stefano suggested) I got:
Not allowed to define mixed content in the element cocoon at
file:/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:23
The error.log is:
ERROR (2003-02-21) 20:47.03:961 [access] (Unknown-URI)
Unknown-thread/CocoonServlet: Exception reloading
org.apache.avalon.framework.configuration.ConfigurationException: Error
trying to load configurations
at org.apache.cocoon.Cocoon.configure(Cocoon.java:366)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:285)
at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1313)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:505)
at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:219)
at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:436)
at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:150)
at
org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:490)
at org.mortbay.http.HttpServer.start(HttpServer.java:647)
at org.mortbay.jetty.Server.main(Server.java:411)
Caused by: org.xml.sax.SAXException: Not allowed to define mixed content
in the element cocoon at
file:/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf:3:23
at
org.apache.avalon.framework.configuration.SAXConfigurationHandler.endElement(SAXConfigurationHandler.java:136)
at
org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:585)
at
org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement(XMLNamespaceBinder.java:898)
at
org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:644)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1008)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1469)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:254)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:273)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:363)
... 9 more
Re: The new build system
Posted by David Crossley <cr...@indexgeo.com.au>.
Antonio Gallardo wrote:
<snip/>
> Sorry, but I have another problem (see below).
Thanks Antonio, i just fixed the broken xml comments
in cocoon.xconf ... so now you can proceed with
testing the new build system.
It finally compiles the webapp, so i am off to do
'build run'.
--David
Re: The new build system
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>> Thanks Stefano for this great improvement!
>>
>> I think you saved worldwide trillions of trillons of CPU cycles. :-D
>
> well, I didn't do it to save your CPU cycles but MINE! Good old
> sellfishness is the real engine of things around OSS :)
>
> Besides, you're going to waste those CPU cycles anyway :)
Never mind I recycle it: http://mersenne.org/ :-D
Sorry, but I have another problem (see below).
Antonio Gallardo
******************************************
prepare-webapp:
Copying 1 file to
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/lib
Reading:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/sitemap.xmap
No Changes:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/sitemap.xmap
Reading:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/sitemap.xmap
No Changes:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/sitemap.xmap
Reading:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/WEB-INF/cocoon.xconf
[Fatal Error] cocoon.xconf:433:8: The string "--" is not permitted within
comments.
BUILD FAILED
file:///home/agallardo/CVS/cocoon/xml-cocoon2/build.xml:657: SAXException:
org.xml.sax.SAXParseException: The string "--" is not permitted within
comments.
**************************************
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> Thanks Stefano for this great improvement!
>
> I think you saved worldwide trillions of trillons of CPU cycles. :-D
well, I didn't do it to save your CPU cycles but MINE! Good old
sellfishness is the real engine of things around OSS :)
Besides, you're going to waste those CPU cycles anyway :)
> I wrote not just for kidding.... Huston, we have a problem..... :-(
>
> I just downloaded the lastest CVS for 2.1 (see timestamp of the mail), but
> I got this error:
>
> BUILD FAILED
> file:///home/agallardo/CVS/cocoon/xml-cocoon2/build.xml:669: IOException:
> java.io.FileNotFoundException:
> /home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/samples/sitemap.xmap
> (No such file or directory)
>
> What can I do?
I just set "exclude.webapp.samples=true" in the build.properties. So
update the CVS and retry.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Thanks Stefano for this great improvement!
I think you saved worldwide trillions of trillons of CPU cycles. :-D
I wrote not just for kidding.... Huston, we have a problem..... :-(
I just downloaded the lastest CVS for 2.1 (see timestamp of the mail), but
I got this error:
BUILD FAILED
file:///home/agallardo/CVS/cocoon/xml-cocoon2/build.xml:669: IOException:
java.io.FileNotFoundException:
/home/agallardo/CVS/cocoon/xml-cocoon2/build/cocoon-2.1-dev/webapp/samples/sitemap.xmap
(No such file or directory)
What can I do?
Best Regards,
Antonio Gallardo.
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Martin Holz wrote:
> Stefano Mazzocchi <st...@apache.org> writes:
>
>
>>Martin Holz wrote:
>>
>>>Stefano Mazzocchi <st...@apache.org> writes:
>>>
>>
>>>>The new build system has landed on CVS.
>>>
>>>[...]
>>
>>>> read BUILD.txt
>>>> cp blocks.properties local.blocks.properties
>>>> cp build.properties local.build.properties
>>>> [modify the local copies as you like, leaving the original intact]
>>>> build webapp [this will generate the webapp]
>>>
>>>Does overriding boolean properties work? If I set
>>
>>>"exclude.webapp.samples=false"
>>>in local.build.properties a target like <target
>>>name="prepare-webapp-samples" depends="package-samples"
>>>unless="exclude.webapp.samples"> won't be executed. "unless" does
>>>not test, if the variable has the value of "true" or "false".
>>
>>>It tests, if the value is defined. At least, that's what the
>>>documentation for ant 1.5 says.
>>
>>>The only way to execute the target is removing the definition from
>>>local.build.properties
>>
>>>and build.properties. The result will be failed build, but that's a other story.
>>
>>You don't have to set things to false, you have to uncomment them!
>
>
> In local.build.properties? This would not help, since they
> are defined in build.properties, which is read by build.xml
> immediately after local.build.properties. You would have to uncomment
> them in build.properties.
right, of course.
I was talking about exclude parameters that are already commented out in
build.properties.
don't worry, I'll make sure things are consistent.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bernhard Huber wrote:
>>> fixed it for me introducing:
>>> <property file="blocks.properties"/>
>>> <condition property="unless.exclude.XXX">
>>> <istrue value="${exclude.XXX}"/>
>>> </condition>
>>>
>>> and using
>>> <target ... unless="${unless.exclude.XXX}">
>>>
>>> this way you can set exclude.XXX in your local.build.properties to
>>> true, or false as you like it.
>>
>>
>> However, I think it's not applicable for block excludes since it
>> would require to change the build file for each new block. Or can we
>> generate automatically a set of exist/not-exist properties from a set
>> of true/false properties (custom task, XSLT, etc ?).
>
>
> well, i didn't fully catch the working of tools/src/blocks-build.xsl,
> yet, but your requirement should be solvable
> in this xsl a la
> <condition property="unless.exclude.{$block-name}">
> <istrue value="exlcude.{$block-name}"/>
> </condition>
> this may - didn't checked it yet - solve your request.
> bye bernhard
You're absolutely right, since block build isn't handled by the main
build.xml
Thanks,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Bernhard Huber <be...@a1.net>.
>
>
>> fixed it for me introducing:
>> <property file="blocks.properties"/>
>> <condition property="unless.exclude.XXX">
>> <istrue value="${exclude.XXX}"/>
>> </condition>
>>
>> and using
>> <target ... unless="${unless.exclude.XXX}">
>>
>> this way you can set exclude.XXX in your local.build.properties to
>> true, or false as you like it.
>
> However, I think it's not applicable for block excludes since it would
> require to change the build file for each new block. Or can we
> generate automatically a set of exist/not-exist properties from a set
> of true/false properties (custom task, XSLT, etc ?).
well, i didn't fully catch the working of tools/src/blocks-build.xsl,
yet, but your requirement should be solvable
in this xsl a la
<condition property="unless.exclude.{$block-name}">
<istrue value="exlcude.{$block-name}"/>
</condition>
this may - didn't checked it yet - solve your request.
bye bernhard
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bernhard Huber wrote:
>>
>> Failed on the same problem today. For those targets that we want to
>> exclude in the default build, having a "exclude.xxx=true" in
>> build.properties requires to modify this CVS-managed file to allow
>> building "xxx", which obviously isn't good.
>>
>> So I tried to go the other way and change to "include.xxx" properties
>> along with <target name="xxx" if="include.xxx"> : this works just
>> fine if I put "include.xxx=" in local.build.properties without
>> changing build.properties.
>>
> fixed it for me introducing:
> <property file="blocks.properties"/>
> <condition property="unless.exclude.XXX">
> <istrue value="${exclude.XXX}"/>
> </condition>
>
> and using
> <target ... unless="${unless.exclude.XXX}">
>
> this way you can set exclude.XXX in your local.build.properties to
> true, or false as you like it.
Good idea !
However, I think it's not applicable for block excludes since it would
require to change the build file for each new block. Or can we generate
automatically a set of exist/not-exist properties from a set of
true/false properties (custom task, XSLT, etc ?).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Bernhard Huber <be...@a1.net>.
>
> Failed on the same problem today. For those targets that we want to
> exclude in the default build, having a "exclude.xxx=true" in
> build.properties requires to modify this CVS-managed file to allow
> building "xxx", which obviously isn't good.
>
> So I tried to go the other way and change to "include.xxx" properties
> along with <target name="xxx" if="include.xxx"> : this works just fine
> if I put "include.xxx=" in local.build.properties without changing
> build.properties.
>
fixed it for me introducing:
<property file="blocks.properties"/>
<condition property="unless.exclude.XXX">
<istrue value="${exclude.XXX}"/>
</condition>
and using
<target ... unless="${unless.exclude.XXX}">
this way you can set exclude.XXX in your local.build.properties to true,
or false as you like it.
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Do you mean that "in the future", the default will be for the build
>>> system to exclude nothing ?
>>>
>>> Can't "the future" be right now and then let the user choose what he
>>> wants to exclude using its local.build.properties instead of patching
>>> build.properties ?
>>>
>>> Sylvain
>>
>>
>>
>> the current excluded things are those that don't work.
>>
> I'm on the way to make some of them work ;-)
Great! Thanks.
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Do you mean that "in the future", the default will be for the build
>> system to exclude nothing ?
>>
>> Can't "the future" be right now and then let the user choose what he
>> wants to exclude using its local.build.properties instead of patching
>> build.properties ?
>>
>> Sylvain
>
>
> the current excluded things are those that don't work.
>
I'm on the way to make some of them work ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Failed on the same problem today. For those targets that we want to
>>> exclude in the default build, having a "exclude.xxx=true" in
>>> build.properties requires to modify this CVS-managed file to allow
>>> building "xxx", which obviously isn't good.
>>
>>
>>
>> the exclude.* stuff that is not commented out in the build.properties
>> will be in the future so the problem goes away.
>
>
>
> Do you mean that "in the future", the default will be for the build
> system to exclude nothing ?
>
> Can't "the future" be right now and then let the user choose what he
> wants to exclude using its local.build.properties instead of patching
> build.properties ?
>
> Sylvain
>
the current excluded things are those that don't work.
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Failed on the same problem today. For those targets that we want to
>> exclude in the default build, having a "exclude.xxx=true" in
>> build.properties requires to modify this CVS-managed file to allow
>> building "xxx", which obviously isn't good.
>
>
> the exclude.* stuff that is not commented out in the build.properties
> will be in the future so the problem goes away.
Do you mean that "in the future", the default will be for the build
system to exclude nothing ?
Can't "the future" be right now and then let the user choose what he
wants to exclude using its local.build.properties instead of patching
build.properties ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Martin Holz wrote:
>
>> Stefano Mazzocchi <st...@apache.org> writes:
>>
>>
>>
>>> Martin Holz wrote:
>>>
>>>
>>>> Stefano Mazzocchi <st...@apache.org> writes:
>>>>
>>>>
>>>>
>>>>> The new build system has landed on CVS.
>>>>>
>>>>
>>>> [...]
>>>>
>>>>
>>>>> read BUILD.txt
>>>>> cp blocks.properties local.blocks.properties
>>>>> cp build.properties local.build.properties
>>>>> [modify the local copies as you like, leaving the original intact]
>>>>> build webapp [this will generate the webapp]
>>>>>
>>>>
>>>> Does overriding boolean properties work? If I set
>>>>
>>>> "exclude.webapp.samples=false"
>>>> in local.build.properties a target like <target
>>>> name="prepare-webapp-samples" depends="package-samples"
>>>> unless="exclude.webapp.samples"> won't be executed. "unless" does
>>>> not test, if the variable has the value of "true" or "false".
>>>>
>>>> It tests, if the value is defined. At least, that's what the
>>>> documentation for ant 1.5 says.
>>>>
>>>> The only way to execute the target is removing the definition from
>>>> local.build.properties
>>>>
>>>> and build.properties. The result will be failed build, but that's a
>>>> other story.
>>>>
>>>
>>> You don't have to set things to false, you have to uncomment them!
>>>
>>
>>
>> In local.build.properties? This would not help, since they
>> are defined in build.properties, which is read by build.xml
>> immediately after local.build.properties. You would have to
>> uncomment them in build.properties.
>>
>> Martin
>>
>>
>
> Failed on the same problem today. For those targets that we want to
> exclude in the default build, having a "exclude.xxx=true" in
> build.properties requires to modify this CVS-managed file to allow
> building "xxx", which obviously isn't good.
the exclude.* stuff that is not commented out in the build.properties
will be in the future so the problem goes away.
Re: The new build system
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Martin Holz wrote:
>Stefano Mazzocchi <st...@apache.org> writes:
>
>
>
>>Martin Holz wrote:
>>
>>
>>>Stefano Mazzocchi <st...@apache.org> writes:
>>>
>>>
>>>
>>>>The new build system has landed on CVS.
>>>>
>>>>
>>>[...]
>>>
>>>
>>>> read BUILD.txt
>>>> cp blocks.properties local.blocks.properties
>>>> cp build.properties local.build.properties
>>>> [modify the local copies as you like, leaving the original intact]
>>>> build webapp [this will generate the webapp]
>>>>
>>>>
>>>Does overriding boolean properties work? If I set
>>>
>>>
>>>"exclude.webapp.samples=false"
>>>in local.build.properties a target like <target
>>>name="prepare-webapp-samples" depends="package-samples"
>>>unless="exclude.webapp.samples"> won't be executed. "unless" does
>>>not test, if the variable has the value of "true" or "false".
>>>
>>>
>>>It tests, if the value is defined. At least, that's what the
>>>documentation for ant 1.5 says.
>>>
>>>
>>>The only way to execute the target is removing the definition from
>>>local.build.properties
>>>
>>>
>>>and build.properties. The result will be failed build, but that's a other story.
>>>
>>>
>>You don't have to set things to false, you have to uncomment them!
>>
>>
>
>In local.build.properties? This would not help, since they
>are defined in build.properties, which is read by build.xml
>immediately after local.build.properties. You would have to uncomment
>them in build.properties.
>
>Martin
>
>
Failed on the same problem today. For those targets that we want to
exclude in the default build, having a "exclude.xxx=true" in
build.properties requires to modify this CVS-managed file to allow
building "xxx", which obviously isn't good.
So I tried to go the other way and change to "include.xxx" properties
along with <target name="xxx" if="include.xxx"> : this works just fine
if I put "include.xxx=" in local.build.properties without changing
build.properties.
Is this the way to go (I wouldn't like to break the build) ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The new build system
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> writes:
> Martin Holz wrote:
> > Stefano Mazzocchi <st...@apache.org> writes:
> >
>
> >>The new build system has landed on CVS.
> > [...]
>
> >> read BUILD.txt
> >> cp blocks.properties local.blocks.properties
> >> cp build.properties local.build.properties
> >> [modify the local copies as you like, leaving the original intact]
> >> build webapp [this will generate the webapp]
> > Does overriding boolean properties work? If I set
>
> > "exclude.webapp.samples=false"
> > in local.build.properties a target like <target
> > name="prepare-webapp-samples" depends="package-samples"
> > unless="exclude.webapp.samples"> won't be executed. "unless" does
> > not test, if the variable has the value of "true" or "false".
>
> > It tests, if the value is defined. At least, that's what the
> > documentation for ant 1.5 says.
>
> > The only way to execute the target is removing the definition from
> > local.build.properties
>
> > and build.properties. The result will be failed build, but that's a other story.
>
> You don't have to set things to false, you have to uncomment them!
In local.build.properties? This would not help, since they
are defined in build.properties, which is read by build.xml
immediately after local.build.properties. You would have to uncomment
them in build.properties.
Martin
Re: The new build system
Posted by Stefano Mazzocchi <st...@apache.org>.
Martin Holz wrote:
> Stefano Mazzocchi <st...@apache.org> writes:
>
>
>>The new build system has landed on CVS.
>
> [...]
>
>> read BUILD.txt
>> cp blocks.properties local.blocks.properties
>> cp build.properties local.build.properties
>> [modify the local copies as you like, leaving the original intact]
>> build webapp [this will generate the webapp]
>
>
> Does overriding boolean properties work? If I set
> "exclude.webapp.samples=false"
> in local.build.properties a target like
>
> <target name="prepare-webapp-samples" depends="package-samples" unless="exclude.webapp.samples">
>
> won't be executed. "unless" does not test, if the variable has the value of "true" or "false".
> It tests, if the value is defined. At least, that's what the documentation for
> ant 1.5 says.
>
> The only way to execute the target is removing the definition from local.build.properties
> and build.properties. The result will be failed build, but that's a other story.
You don't have to set things to false, you have to uncomment them!
I'll make this more explicit in some internal comments.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> writes:
> The new build system has landed on CVS.
[...]
> read BUILD.txt
> cp blocks.properties local.blocks.properties
> cp build.properties local.build.properties
> [modify the local copies as you like, leaving the original intact]
> build webapp [this will generate the webapp]
Does overriding boolean properties work? If I set
"exclude.webapp.samples=false"
in local.build.properties a target like
<target name="prepare-webapp-samples" depends="package-samples" unless="exclude.webapp.samples">
won't be executed. "unless" does not test, if the variable has the value of "true" or "false".
It tests, if the value is defined. At least, that's what the documentation for
ant 1.5 says.
The only way to execute the target is removing the definition from local.build.properties
and build.properties. The result will be failed build, but that's a other story.
Martin
P.S : Improving the build system is really worth some temporary inconvenience. Thank you very much.
--
Martin Holz <ho...@fiz-chemie.de>
Softwareentwicklung / Vernetztes Studium - Chemie
FIZ CHEMIE Berlin
Franklinstrasse 11
D-10587 Berlin
Re: The new build system
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> ...Would it make sense to add the possibility to debug the application
> too? It would be a matter of adding a couple of jvmargs like
>
> <jvmarg value="-Xdebug"/>
> <jvmarg
> value="-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"/> >
>
> This way, it would be a piece of cake to remotely debug the
> application. I'm just wondering whether it should be another target or
> a switch like "./build.sh -Dcocoon.debug run".
Very useful IMHO, go for it!
If you want to include it, here's what I use in another project to
start the JSWAT debugger. We might not want to distribute it with
Cocoon, but at least people could download it and not have to mess with
settings too much, it would start with the correct paths to find
everything.
<!-- classpath for jswat debugger -->
<path id="jswat.classpath">
<fileset dir="lib/jswat">
<include name="**/*.jar"/>
</fileset>
</path>
<!-- start the jswat debugger -->
<target name="jswat" description="run the jswat debugger">
<echo>-jswat
debugging---------------------------------------------------------------
----</echo>
<echo>Attempting to start the jswat debugger for
${ant.project.name}...</echo>
<echo>Then, start "./build.sh -Dcocoon.debug run" and then
"./build.sh jswat", and use "session/attach to remote" in jswat, with
the port numb
er set by jvm.extra.args</echo>
<echo>WARNING: using this debugger requires running both the
"run" and "jswat" targets under JDK 1.4</echo>
<echo>------------------------------------------------------------------
------------------------------</echo>
<!-- open jswat debugger for remote debugging in project env -->
<java classname="com.bluemarsh.jswat.Main" fork="yes">
<jvmarg value="-Djava.source.path=${src}"/>
<classpath refid="jswat.classpath"/>
<classpath refid="compile.classpath"/>
<classpath refid="runtime.classpath"/>
<classpath refid="test.classpath"/>
</java>
</target>
-Bertrand
Re: The new build system
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
> The new build system has landed on CVS.
>
> Do a 'cvs update' to get it.
Cool, I'll try it today!
Would it make sense to add the possibility to debug the application too?
It would be a matter of adding a couple of jvmargs like
<jvmarg value="-Xdebug"/>
<jvmarg
value="-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"/>
This way, it would be a piece of cake to remotely debug the application.
I'm just wondering whether it should be another target or a switch like
"./build.sh -Dcocoon.debug run".
How about it?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
Re: esql: setting date format for
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 21.Feb.2003 -- 01:25 PM, Goetz Botterweck wrote:
> Is there a way to ...
> 1) get all columns with <esql:get-columns/>
> 2) specify date format for one of these columns
> (so that I do not get "2003-05-21 00:00:00.0" but "21. May 2003")
>
> I do not want to use <esql:get-date ...>
None that I am aware of. ;-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: esql: setting date format for
Posted by leo leonid <te...@leonid.de>.
On Freitag, Februar 21, 2003, at 01:25 Uhr, Goetz Botterweck wrote:
> Is there a way to ...
> 1) get all columns with <esql:get-columns/>
> 2) specify date format for one of these columns
> (so that I do not get "2003-05-21 00:00:00.0" but "21. May 2003")
>
> I do not want to use <esql:get-date ...>
>
-> 2) Why not <esql:get-date ...>? or get-timestamp ?
The only problem I can see is that there is no way to set a locale to
format with get-date,
this could be solved with the i18n transformer
<i18n:date-time src-pattern="yyyy-MM-dd hh:mm:ss" pattern="FULL" >
<esql:get-timestamp column="mydate" format="yyyy-MM-dd hh:mm:ss"/>
</i18n:date-time>
/Leo
> Thanks
> Goetz
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
esql: setting date format for
Posted by Goetz Botterweck <bo...@uni-koblenz.de>.
Is there a way to ...
1) get all columns with <esql:get-columns/>
2) specify date format for one of these columns
(so that I do not get "2003-05-21 00:00:00.0" but "21. May 2003")
I do not want to use <esql:get-date ...>
Thanks
Goetz
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: The new build system
Posted by Gabriele Domenichini <ga...@fastmail.fm>.
> I suggest you to:
>
> read BUILD.txt
> cp blocks.properties local.blocks.properties
> cp build.properties local.build.properties
> [modify the local copies as you like, leaving the original intact]
> build webapp [this will generate the webapp]
> build run [this will run jetty]
Build failed and I received this error:
<partOfTheErrorMessage>
/usr/local/xml-cocoon2/build/cocoon-2.1-dev/blocks/databases/src/org/apache/cocoon/acting/OraAddAction.java:53:
package oracle.jdbc does not exist
import oracle.jdbc.OracleResultSet;
</partOfTheErrorMessage>
I haven't got Oracle jdbc drivers of course because I don't use them at
home.
How can I exclude them?
Thank you
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
ISSUE 3: mocks4blocks
It appears that no blocks with mock classes can be build because the
mock classes are not compiled (or even copied).
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de> wrote:
> ISSUE 3: mocks 4 blocks
> It appears that building mocks does not work currently. IOW all blocks
> that have mocks don't build :-(
Whopsie? I went through the compilation of all blocks (except databases)
fine, but now it's reporting:
prepare-webapp-samples:
Copying 1 file to
/Users/pier/Desktop/cocoon/build/cocoon-2.1-dev/webapp/WEB-INF/lib
Reading:
/Users/pier/Desktop/cocoon/build/cocoon-2.1-dev/webapp/samples/sitemap.xmap
BUILD FAILED
file:///Users/pier/Desktop/cocoon/build.xml:669: IOException:
java.io.FileNotFoundException:
/Users/pier/Desktop/cocoon/build/cocoon-2.1-dev/webapp/samples/sitemap.xmap
(No such file or directory)
Still some ironing out to do...
Pier
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
ISSUE 3: mocks 4 blocks
It appears that building mocks does not work currently. IOW all blocks
that have mocks don't build :-(
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: The new build system
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Thu, 20 Feb 2003, Stefano Mazzocchi wrote:
> Do a 'cvs update' to get it.
,..
> Since I normally work on a pentium II 366 you guys should see even
> faster build times, expecially after the first run.
..
> now, off for a drink :)
Make it a big one ! - the cvs update took ten times longer than the build.
WoW - impressive (though still hunting down some junit dependency).
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> I tweaked jetty to be as small as possible. I'm now able to get a cocoon
> up and running with as low as 22 Mb memory!
Good idea to plant that webdefaults.xml file in there! :-) Now it's time to
update the libs (new release came out).
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le Jeudi, 20 fév 2003, à 21:44 Europe/Zurich, Stefano Mazzocchi a écrit :
>
>> The new build system has landed on CVS.
>
>
> woooh-hooh-hooh, looks great!
thank you.
> I have a few issues here however, most probably related to my JDK
> (1.3.1 on macosx 10.2.3).
ok, I'm working on JDK 1.4.1 on win2k so I was expecting something like
this.
> After a build clean + CVS update (no local.* stuff), build.sh works (1
> minute 6 seconds - wow!)
cool
> I checked that the target.vm property is correctly set to "1.2" in
> build.xml.
great
> ISSUE 1 - JDBC3 stuff
> "build.sh webapp" fails:
> src/org/apache/cocoon/components/language/markup/xsp/
> AbstractEsqlConnection.java:298: cannot resolve symbol
> symbol : class Savepoint
> location: package sql
> public java.sql.Savepoint setSavepoint()
>
> Most probably this has to do with the "jdbc3.present" property used by
> ./src/blocks/databases/build.xml. I tried to set this property in the
> optional-tests target of the main build.xml but it didn't help.
hmmm, might be a problem with the invocation of the block build. I
didn't really test that one since it was working for me. I'll try more
stuff.
>
> ISSUE 2 - "build run"
> "build.sh run" says "NoClassDefFoundError: org/xml/sax/ContentHandler"
> unless I add this to the classpath of the run target:
>
> <fileset dir="lib/endorsed">
> <include name="*.jar"/>
> </fileset>
Oh, damn, you're totally right. Since JDK 1.3.x doesn't have the
-endorsed command line tag, jetty doesn't find things.
I'm installing JDK 1.3.1 so that I can see these problems myself.
> Using the <classpath> from the build.old.xml, the "run" target works as
> well (that is, jetty starts but as I have no webapp it doesn't go that
> far).
> Also a JDK 1.3.1 issue I think, as this interface is standard in 1.4
> AFAIK but not in 1.3.1.
Yes, it's trivial to fix, but I'll install JDK 1.3.1 so that I can do
stuff myself.
Thanks and keep up reporting the problems.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, February 20, 2003, at 10:56 PM, Bertrand Delacretaz wrote:
> Le Jeudi, 20 fév 2003, à 21:44 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> The new build system has landed on CVS.
>
> woooh-hooh-hooh, looks great!
>
> I have a few issues here however, most probably related to my JDK
> (1.3.1 on macosx 10.2.3).
>
I am sorry to report problems too.
MacOSX 10.2.4, JVM 1.3.1.
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:53: package
oracle.jdbc does not exist
import oracle.jdbc.OracleResultSet;
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:54: package
oracle.sql does not exist
import oracle.sql.BLOB;
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:55: package
oracle.sql does not exist
import oracle.sql.CLOB;
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:187: cannot
resolve symbol
symbol : class OracleResultSet
location: class org.apache.cocoon.acting.OraAddAction
OracleResultSet set = (OracleResultSet)
LOBstatement.executeQuery();
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:187: cannot
resolve symbol
symbol : class OracleResultSet
location: class org.apache.cocoon.acting.OraAddAction
OracleResultSet set = (OracleResultSet)
LOBstatement.executeQuery();
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:204: cannot
resolve symbol
symbol : class CLOB
location: class org.apache.cocoon.acting.OraAddAction
CLOB ascii = set.getCLOB(index);
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/acting/OraAddAction.java:217: cannot
resolve symbol
symbol : class BLOB
location: class org.apache.cocoon.acting.OraAddAction
BLOB binary = set.getBLOB(index);
^
/Users/jermq/Checkouts/Secure/xml-cocoon2/build/cocoon-2.1-dev/blocks/
databases/src/org/apache/cocoon/components/modules/database/
IfxSerialAutoIncrementModule.java:78: package com.informix.jdbc does
not exist
return new Integer(((com.informix.jdbc.IfxStatement)
stmt).getSerial());
not sure where to go with this ....
any suggestions?
many thanks
regards Jeremy
Re: The new build system (JDK 1.3.1/macosx issues)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 20 fév 2003, à 21:44 Europe/Zurich, Stefano Mazzocchi a écrit
:
> The new build system has landed on CVS.
woooh-hooh-hooh, looks great!
I have a few issues here however, most probably related to my JDK
(1.3.1 on macosx 10.2.3).
After a build clean + CVS update (no local.* stuff), build.sh works (1
minute 6 seconds - wow!)
I checked that the target.vm property is correctly set to "1.2" in
build.xml.
ISSUE 1 - JDBC3 stuff
"build.sh webapp" fails:
src/org/apache/cocoon/components/language/markup/xsp/
AbstractEsqlConnection.java:298: cannot resolve symbol
symbol : class Savepoint
location: package sql
public java.sql.Savepoint setSavepoint()
Most probably this has to do with the "jdbc3.present" property used by
./src/blocks/databases/build.xml. I tried to set this property in the
optional-tests target of the main build.xml but it didn't help.
ISSUE 2 - "build run"
"build.sh run" says "NoClassDefFoundError: org/xml/sax/ContentHandler"
unless I add this to the classpath of the run target:
<fileset dir="lib/endorsed">
<include name="*.jar"/>
</fileset>
Using the <classpath> from the build.old.xml, the "run" target works as
well (that is, jetty starts but as I have no webapp it doesn't go that
far).
Also a JDK 1.3.1 issue I think, as this interface is standard in 1.4
AFAIK but not in 1.3.1.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The new build system
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Thu, 20 Feb 2003, Stefano Mazzocchi wrote:
> Do a 'cvs update' to get it.
,..
> Since I normally work on a pentium II 366 you guys should see even
> faster build times, expecially after the first run.
..
> now, off for a drink :)
Make it a big one ! - the cvs update took ten times longer than the build.
WoW - impressive (though still hunting down some junit dependency).
Dw.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: The new build system
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> I tweaked jetty to be as small as possible. I'm now able to get a cocoon
> up and running with as low as 22 Mb memory!
Good idea to plant that webdefaults.xml file in there! :-) Now it's time to
update the libs (new release came out).
Pier