Re: The new build system

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 hap

Re: The new build system

Antonio Gallardo wrote: > David Crossley dijo: > > Antonio Gallardo wrote: > > > >> 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 c

Re: The new build system

David Crossley dijo: > Antonio Gallardo wrote: > >> 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 > 'bui

[ANN] Hibernator - Eclipse Plugin

Since many people is trying to push the combination of XMLForms with Hibernate. I think this link can be of special interest :-) http://sourceforge.net/projects/hibernator/ I hope it will be useful. Best Regards, Antonio Gallardo

Re: The new build system

Antonio Gallardo wrote: > 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

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

crossley2003/02/21 18:12:51 Modified:src/webapp/WEB-INF cocoon.xconf Log: Fix some wonky xml comments. Revision ChangesPath 1.61 +2 -2 xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf Index: cocoon.xconf

Re: The new build system

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 :) >

cvs commit: xml-cocoon2/src/scratchpad/schecoon ChangeLog TODO

stefano 2003/02/21 15:29:08 Removed: src/scratchpad/schecoon ChangeLog TODO Log: say goodbye to schecoon :-)

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

stefano 2003/02/21 15:26:57 Modified:src/webapp/WEB-INF cocoon.xconf Log: there is no scheme implementation going on anyway Revision ChangesPath 1.60 +1 -9 xml-cocoon2/src/webapp/WEB-INF/cocoon.xconf Index: cocoon.xconf ===

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow TODO

stefano 2003/02/21 15:26:31 Modified:src/java/org/apache/cocoon/components/flow TODO Log: update a little (shouldn't we move this into a more visible location?) Revision ChangesPath 1.3 +1 -18 xml-cocoon2/src/java/org/apache/cocoon/components/flow/TODO Inde

cvs commit: xml-cocoon2/src/java Manifest.mf

stefano 2003/02/21 15:17:09 Modified:src/java Manifest.mf Log: cleanup manifest file (did we really need those things in here?) Revision ChangesPath 1.5 +0 -69 xml-cocoon2/src/java/Manifest.mf Index: Manifest.mf ===

[Blocks] Propsal: Block descriptions

First off, I'd like to congratulate Stefano on the awesome work he's done with reworking the build system. I've been poking around, and so far I've been very impressed. Now that blocks are "live", I'd like to propose something very small and simple: For each block, we put a simple file, called p

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

stefano 2003/02/21 15:01:19 Modified:src/webapp/WEB-INF cocoon.xconf Log: merging all xconf files from core into the cocoon configuration improved readability by adding some documentation PLEASE, look into it and fill the gaps that I couldn't fill myself Re

cvs commit: xml-cocoon2/src/java/org/apache/cocoon cocoon.roles

stefano 2003/02/21 14:54:21 Modified:src/java/org/apache/cocoon cocoon.roles Log: merging all xrole files from core into the cocoon role file Revision ChangesPath 1.46 +30 -11xml-cocoon2/src/java/org/apache/cocoon/cocoon.roles Index: cocoon.roles =

Re: The new build system

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

Re: The new build system

> 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

cvs commit: xml-cocoon2 build.properties

stefano 2003/02/21 14:49:45 Modified:.build.properties Log: excluding everything from the webapp for now so that the build works out of the box (still working on the samples) Revision ChangesPath 1.2 +13 -21xml-cocoon2/build.properties Index: build

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow flow.xconf flow.xroles

stefano 2003/02/21 14:49:17 Removed: src/java/org/apache/cocoon/components/flow flow.xconf flow.xroles Log: the xconf tool should used only for optional stuff, the rest should go into the default xconf xroles, otherwise, we loose focus on what's in the core

Win32 Command line length problem

The command line run.bat in CVS does not work at present, due to too many jars making the classpath longer than DOS can handle as an environment variable. Does anyone know how to extend the allowable length of an environment variable, or how to get java to start by passing the classpath in some

Re: [proposal] Removing the scratchpad

Pier Fumagalli wrote: "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: Each block is currently described into the 'project-info.xml' descriptor and has an attribute that marks it 'alpha' and the build system shows that. Is it that thinghy??? yes -- Stefano Mazzocchi

Re: The new build system

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:///h

Re: Setting values in XMLForm (via JXPath)

In this case it looks like XMLForm is trying to replace all the elements of a collection with a new set of elements. It looks to me like there is no reasonable way to do this in general with JXPath without the caller being aware of the representation of the collection. Or am I wrong? Regards,

Re: [PMC] bootstrapping the PMC

Giacomo Pati wrote: On Thu, 30 Jan 2003, Berin Loritsch wrote: The PMC is not responsible for code, they are responsible for community. Hmm.. IIRC I remember dicussions held at Apache Con in Las Vegas where the general expectation was that a PMC *is* responsible for the code at least concerning

Re: [PMC] bootstrapping the PMC

On Thu, 30 Jan 2003, Berin Loritsch wrote: > Sylvain Wallez wrote: > > Stefano Mazzocchi wrote: > > > >> People, > >> > >> since Cocoon got approuved as a top level project, we have a PMC, but > >> the ASF is designed in such a way that each PMC can choose its own > >> rules and policies. > > > >

Setting values in XMLForm (via JXPath)

It appears that XMLForm's use of JXPath is hardcoded to setting indexed values only on Java arrays and Collections (not DOM nodes or other types of JXPath nodes). I was attempting to use a JavaScript object as a JXPath node, but ran into the below problem in Form.java (http://cvs.apache.org/vie

[Proposal] JAR management

Currently Cocoon has so many jars in its lib directory structure that it is hard to know the particulars of who, what, when, where, why, and how. The jar.xml file helps somewhat in that regard, but it can only do so much. Avalon is getting ready to do some releases, and I am actually surprised by

Re: [PROBLEM] caching after map:aggregate

excuse for bothering you Vadim Gritsenko wrote: If pipeline validity for given pipeline key has been changed, then whole result will be recreated. do you mean like this: here are also the cached result are diplayed Klau

RE: The new build system

I finally built it. I used W2K Pro and JSDK 1.4.1_01 I had to exclude the webapp samples as mentioned but everything else works just fine. I forgot to mention in my previous email, Stefano, thanks for this new build system, it really rocks. Best. -Mensaje original- De: Stefano Mazzocch

Re: The new build system

On Friday, February 21, 2003, at 02:48 PM, Stefano Mazzocchi wrote: The errors that have been reported w/ oracle.jdbc, org.xml.database and some others have to do with minor typos in tools/src/blocks-build.xsl. I have appended a patch that remedies these typos. I've fixed it already. I can con

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/delideli.xconf deli.xroles

[EMAIL PROTECTED] wrote: stefano 2003/02/21 07:36:17 Removed: src/java/org/apache/cocoon/components/deli deli.xconf deli.xroles Log: the xconf tool should used only for optional stuff, the rest should go into the default xconf xroles, otherwise, we loose focus o

Re: [PROBLEM] caching after map:aggregate

Klaus Bertram wrote: Vadim Gritsenko wrote: Klaus Bertram wrote: Hi all, it seems that there is a caching problem after the map:aggregate module in the followed transformer at version 2.0.4 and 2.0.5 it works well but not in 2.1 dev here a sample:

Re: [proposal] Removing the scratchpad

On Fri, 21 Feb 2003, Stefano Mazzocchi wrote: > The scratchpad was born as a place where things can be worked-on on > alpha status, but it because a place where things are dumped and forgotten. > > A scratchpad is against the continuous integration concept. In short, > it's an individualistic sho

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules modules.xconf modules.xroles

stefano 2003/02/21 07:38:19 Removed: src/java/org/apache/cocoon/components/modules modules.xconf modules.xroles Log: the xconf tool should used only for optional stuff, the rest should go into the default xconf xroles, otherwise, we loose focus on what's in t

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/deli deli.xconf deli.xroles

stefano 2003/02/21 07:36:17 Removed: src/java/org/apache/cocoon/components/deli deli.xconf deli.xroles Log: the xconf tool should used only for optional stuff, the rest should go into the default xconf xroles, otherwise, we loose focus on what's in the core

Re: [proposal] Removing the scratchpad

Stefano Mazzocchi wrote, On 21/02/2003 16.02: The scratchpad was born as a place where things can be worked-on on alpha status, but it because a place where things are dumped and forgotten. A scratchpad is against the continuous integration concept. In short, it's an individualistic short-cut

Re: [proposal] Removing the scratchpad

Stefano Mazzocchi wrote: The scratchpad was born as a place where things can be worked-on on alpha status, but it because a place where things are dumped and forgotten. A scratchpad is against the continuous integration concept. In short, it's an individualistic short-cut but doesn't help the

cvs commit: xml-cocoon2 project-info.xml

pier2003/02/21 07:31:37 Modified:.project-info.xml Log: Marking proxy-block as "unstable" for now... You never stop learning. Revision ChangesPath 1.11 +1 -1 xml-cocoon2/project-info.xml Index: project-info.xml

Re: [proposal] Removing the scratchpad

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Each block is currently described into the 'project-info.xml' descriptor > and has an attribute that marks it 'alpha' and the build system shows that. Is it that thinghy??? Pier

Re: [proposal] Removing the scratchpad

Stefano Mazzocchi wrote: The scratchpad was born as a place where things can be worked-on on alpha status, but it because a place where things are dumped and forgotten. A scratchpad is against the continuous integration concept. In short, it's an individualistic short-cut but doesn't help the

Re: [proposal] Removing the scratchpad

Stefano Mazzocchi wrote: The scratchpad was born as a place where things can be worked-on on alpha status, but it because a place where things are dumped and forgotten. I propose to dump it and to move the code into 'alpha blocks'. Thoughts? Big +1 on the principle, but with a practical quest

RE: [proposal] Removing the scratchpad

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > The scratchpad was born as a place where things can be worked-on on > alpha status, but it because a place where things are dumped and forgotten. > > A scratchpad is against the continuous integration concept. In short, > it's an individualistic sho

Re: [proposal] Removing the scratchpad

Le Vendredi, 21 fév 2003, à 16:02 Europe/Zurich, Stefano Mazzocchi a écrit : ...I propose to dump it and to move the code into 'alpha blocks'. +1 ...Of course, that also means that those blocks are marked as such in the properties files and removed from the official distribution +1 -Be

Re: [proposal] Removing the scratchpad

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > The scratchpad was born as a place where things can be worked-on on > alpha status, but it because a place where things are dumped and forgotten. > > A scratchpad is against the continuous integration concept. In short, > it's an individualistic sh

[proposal] Removing the scratchpad

The scratchpad was born as a place where things can be worked-on on alpha status, but it because a place where things are dumped and forgotten. A scratchpad is against the continuous integration concept. In short, it's an individualistic short-cut but doesn't help the community, nor the project

Re: The new build system

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

Re: The new build system

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

Re: The new build system

Marc Fleischeuers wrote: I'm very impressed with the new build system. It makes Cocoon look almost like a sane product now. eheh, yeah, I have the same feeling :) The errors that have been reported w/ oracle.jdbc, org.xml.database and some others have to do with minor typos in tools/src/blocks

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/transformation XMLDBTransformer.java

stefano 2003/02/21 06:45:59 Added: src/blocks/xmldb/java/org/apache/cocoon/acting DbXMLAuthenticatorAction.java src/blocks/xmldb/java/org/apache/cocoon/components/source XMLDBSource.java XMLDBSourceFactory.java

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/generation - New directory

stefano 2003/02/21 06:44:19 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/generation - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/transformation - New directory

stefano 2003/02/21 06:44:13 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/transformation - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/components/source - New directory

stefano 2003/02/21 06:43:50 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/components/source - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/acting - New directory

stefano 2003/02/21 06:43:31 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/acting - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/components - New directory

stefano 2003/02/21 06:43:45 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon/components - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache - New directory

stefano 2003/02/21 06:43:16 xml-cocoon2/src/blocks/xmldb/java/org/apache - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon - New directory

stefano 2003/02/21 06:43:22 xml-cocoon2/src/blocks/xmldb/java/org/apache/cocoon - New directory

cvs commit: xml-cocoon2/src/blocks/xmldb/java/org - New directory

stefano 2003/02/21 06:43:09 xml-cocoon2/src/blocks/xmldb/java/org - New directory

Re: The new build system

"Marc Fleischeuers" <[EMAIL PROTECTED]> wrote: > I'm very impressed with the new build system. It makes Cocoon look almost > like a sane product now. > > The errors that have been reported w/ oracle.jdbc, org.xml.database and some > others have to do with minor typos in tools/src/blocks-build.xsl

Re: The new build system

...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

...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 > 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 "./

Re: Proposal for Lenya

Steven Noels wrote: My main concern is the fact that Lenya does not come only with a community, but also with a code base. That code base is in use already at a selected number of commercial installations (which is good, of course). I hope to be proven wrong, yet I fear the existing codebase is

The new build system

I'm very impressed with the new build system. It makes Cocoon look almost like a sane product now. The errors that have been reported w/ oracle.jdbc, org.xml.database and some others have to do with minor typos in tools/src/blocks-build.xsl. I have appended a patch that remedies these typos. The

Re: The new build system

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 This way, it would be a piece of c

Re: The new build system

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 bu

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input DateInputModule.java DateMetaInputModule.java

haul2003/02/21 06:00:58 Modified:src/java/org/apache/cocoon/components/modules/input Tag: cocoon_2_0_3_branch DateInputModule.java DateMetaInputModule.java Log: "typo" Revision ChangesPath No revision

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input DateMetaInputModule.java DateInputModule.java

haul2003/02/21 05:59:24 Modified:src/java/org/apache/cocoon/components/modules/input DateMetaInputModule.java DateInputModule.java Log: "typo" Revision ChangesPath 1.8 +3 -3 xml-cocoon2/src/java/org/apache/cocoon/components/modules/

Re: The new build system (JDK 1.3.1/macosx issues)

"Christian Haul" <[EMAIL PROTECTED]> 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-s

cvs commit: xml-cocoon2/tools/jetty/lib jetty-4.2.8.jar jetty-4.2.7.jar

pier2003/02/21 05:55:08 Added: tools/jetty/lib jetty-4.2.8.jar Removed: tools/jetty/lib jetty-4.2.7.jar Log: New version of Jetty came along... Revision ChangesPath 1.1 xml-cocoon2/tools/jetty/lib/jetty-4.2.8.jar <>

Re: The new build system (JDK 1.3.1/macosx issues)

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 [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08

cvs commit: xml-cocoon2 blocks.properties

pier2003/02/21 05:47:58 Modified:.blocks.properties Log: No newline at the end of the file Revision ChangesPath 1.3 +0 -1 xml-cocoon2/blocks.properties Index: blocks.properties =

Re: The new build system

"Stefano Mazzocchi" <[EMAIL PROTECTED]> 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

Re: cvs commit: xml-cocoon2/src/blocks/proxy/lib dont-delete-me

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: >> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >> >> >>> crossley2003/02/20 19:52:58 >>> >>> Added: src/blocks/proxy/lib dont-delete-me >>> Log: >>> Fix one problem with the new build and move on to the next blo

cvs commit: xml-cocoon2/src/blocks/web3/lib .cvsignore dont-delete-me

pier2003/02/21 05:40:41 Added: src/blocks/authentication-fw/lib .cvsignore src/blocks/jsp/lib .cvsignore src/blocks/linkrewriter/lib .cvsignore src/blocks/naming/lib .cvsignore src/blocks/php/lib .cvsignore

cvs commit: xml-cocoon2/src/blocks/databases/lib .cvsignore xmldb-api-20011111.jar

stefano 2003/02/21 05:29:47 Added: src/blocks/databases/lib .cvsignore Removed: src/blocks/databases/java/org/apache/cocoon/acting DbXMLAuthenticatorAction.java src/blocks/databases/lib xmldb-api-2001.jar Log: moving xmldb stuff into

Re: [Avalon] Trying to coordinate some releases

Konstantin Piroumian wrote: From: "Berin Loritsch" <[EMAIL PROTECTED]> From what I can gather, Cocoon uses all of these components from Avalon: CLI Collections Concurrent i18n i18n stuff from Avalon was moved to Cocoon and now there are no references to anything in Avalon i18n package. AFAIK

cvs commit: xml-cocoon2/tools/src blocks-build.xsl

stefano 2003/02/21 05:27:04 Modified:tools/src blocks-build.xsl Log: fix a typo that didn't make the block compile mocks. This should fix the full build on JDK 1.4, there is still some work to do for 1.3 but I'm workign on it Revision ChangesPath 1.20 +4 -4 xml

cvs commit: xml-cocoon2 build.xml

stefano 2003/02/21 05:25:42 Modified:.build.xml Log: put the build echo message in a more visible location Revision ChangesPath 1.322 +5 -5 xml-cocoon2/build.xml Index: build.xml ===

cvs commit: xml-cocoon2 blocks.properties

stefano 2003/02/21 05:24:51 Modified:.blocks.properties Log: added the proxy block Revision ChangesPath 1.2 +1 -1 xml-cocoon2/blocks.properties Index: blocks.properties === RCS fil

Re: The new build system

...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 fu

Re: cvs commit: xml-cocoon2/src/blocks/proxy/lib dont-delete-me

Pier Fumagalli wrote: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: crossley2003/02/20 19:52:58 Added: src/blocks/proxy/lib dont-delete-me Log: Fix one problem with the new build and move on to the next blockage. Revision ChangesPath 1.1 xml-cocoon2/src/blocks

Re: The new build system

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 no

Re: The new build system

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

Re: cvs commit: xml-cocoon2/src/blocks/proxy/lib dont-delete-me

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > crossley2003/02/20 19:52:58 > > Added: src/blocks/proxy/lib dont-delete-me > Log: > Fix one problem with the new build and move on to the next blockage. > > Revision ChangesPath > 1.1 xml-cocoon2/src/blocks/proxy/li

Re: The new build system

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

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 ca

Re: The new build system (JDK 1.3.1/macosx issues)

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

Re: cvs commit: xml-cocoon2 build.xml

Le Vendredi, 21 fév 2003, à 12:41 Europe/Zurich, [EMAIL PROTECTED] a écrit : ... fixed endorsed classpath issue with running jetty on jdk 1.3.x "build.sh run" works now here on JDK 1.3.1/macosx - thanks! -Bertrand

cvs commit: xml-cocoon2 build.xml

stefano 2003/02/21 03:41:51 Modified:.build.xml Log: fixed endorsed classpath issue with running jetty on jdk 1.3.x Revision ChangesPath 1.321 +5 -2 xml-cocoon2/build.xml Index: build.xml

Re: The new build system (JDK 1.3.1/macosx issues)

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 [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08

Re: The new build system (JDK 1.3.1/macosx issues)

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 wor

Re: cvs commit: xml-cocoon2/tools/src XConfToolTask.java

[EMAIL PROTECTED] wrote: stevenn 2003/02/21 00:58:42 Modified:tools/src XConfToolTask.java Log: Trying to make XConfTool Task work when CVS sandbox directory contains spaces (don't ask: W2K, My Documents et al.) Ah, the power of release early/release often. Thanks you people for

Re: Proposal for Lenya

Niclas Hedhman wrote: On Friday 21 February 2003 09:40, Jeff Turner wrote: I see what Steven means with: My main concern is the fact that Lenya does not come only with a community, but also with a code base. That code base is in use already at a selected number of commercial installations (whi

Re: The new build system

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: bu

Re: [PROBLEM] caching after map:aggregate

Vadim Gritsenko wrote: Klaus Bertram wrote: Hi all, it seems that there is a caching problem after the map:aggregate module in the followed transformer at version 2.0.4 and 2.0.5 it works well but not in 2.1 dev here a sample: If index.html is call

DO NOT REPLY [Bug 17127] - [PATCH] I18nTransformer support for multiple catalogues

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-cocoon2/tools/src XConfToolTask.java

stevenn 2003/02/21 00:58:42 Modified:tools/src XConfToolTask.java Log: Trying to make XConfTool Task work when CVS sandbox directory contains spaces (don't ask: W2K, My Documents et al.) Revision ChangesPath 1.9 +3 -3 xml-cocoon2/tools/src/XConfToolTask.java

Re: Proposal for Lenya

Andreas Kuckartz wrote: You seem to be concerned that the software is *used* in productive environments. Do software developers who want to change the code have to take that into account? Yes, certainly they should do that. Is that an argument against the adoption of the software? No, quite the op