Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 24.03.2004 01:53, Geoff Howard wrote: This was the reason for the common classpath, wasn't it? I wanted to have a look on it after having reverted the common classpath, but I guess that's no longer needed. Thanks for it. BTW, which block depends on other block's samples? Not sure if this is what you mean, but there are some interdependencies between block samples involving (I think) database, hsql, eventcache, jms, and maybe repository. No block depends outright on samples, but samples do depend on other blocks where the dependency disappears without the samples. I hope no block's core code is depending on another block's samples code and we will not introduce such a dependency as this would break compiling if one excludes the samples from the build. What I meant was one block's samples dependent on another block's samples (all about compiling Java files). I would prefer to see some conditional build steps to allow "soft" dependencies for samples and even optional pieces of code. IOW, some bits are included if the dependency is met, otherwise not. Indeed. At the moment in gump.xml both sample and compiling dependencies are mixed and sometimes not specified at all (e.g. OJB samples depend on CForms). AFAIK there is no strict handling of gump.xml and Gump does not stumble about additional attributes, so we might add an @type to the dependency element. This can be used for better dependency information in blocks.properties and maybe also for blocks-build.xsl Joerg
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Joerg Heinicke wrote: On 23.03.2004 20:23, [EMAIL PROTECTED] wrote: stephan 2004/03/23 11:23:07 Modified:tools/src blocks-build.xsl Log: Allow to share codebase to other blocks. + + This was the reason for the common classpath, wasn't it? I wanted to have a look on it after having reverted the common classpath, but I guess that's no longer needed. Thanks for it. BTW, which block depends on other block's samples? Not sure if this is what you mean, but there are some interdependencies between block samples involving (I think) database, hsql, eventcache, jms, and maybe repository. No block depends outright on samples, but samples do depend on other blocks where the dependency disappears without the samples. I would prefer to see some conditional build steps to allow "soft" dependencies for samples and even optional pieces of code. IOW, some bits are included if the dependency is met, otherwise not. Geoff
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Di, den 23.03.2004 schrieb Joerg Heinicke um 20:37: > On 23.03.2004 20:23, [EMAIL PROTECTED] wrote: > > stephan 2004/03/23 11:23:07 > > > > Modified:tools/src blocks-build.xsl > > Log: > > Allow to share codebase to other blocks. > > > > > + > > + > > > > > > > > This was the reason for the common classpath, wasn't it? One reason ;-) > I wanted to > have a look on it after having reverted the common classpath, but I > guess that's no longer needed. Thanks for it. BTW, which block depends > on other block's samples? I think at moment none, but will come next ;-) Stephan.
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote: stephan 2004/03/23 11:23:07 Modified:tools/src blocks-build.xsl Log: Allow to share codebase to other blocks. + + This was the reason for the common classpath, wasn't it? I wanted to have a look on it after having reverted the common classpath, but I guess that's no longer needed. Thanks for it. BTW, which block depends on other block's samples? Joerg
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 17.03.2004 20:51, [EMAIL PROTECTED] wrote: cziegeler2004/03/17 11:51:14 Modified:tools/src blocks-build.xsl Log: Removed all antcalls - very fast build now (at least compared to the old system) Thanks, exactly this was the reason for the slow build. If you had not it already done, this would have been my task for today evening. I built today for testing with all blocks included, but without documentation and javadoc on PIII 650 - it took 15 min, and you could see obviously the pause after every little block target, because the huge blocks-build.xml is reparsed on every antcall. Thanks very much for this work. Now, let the flame war begin (if something is not working) No, the effect of this change is too good :) Now we can start serious bug hunting. Joerg
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Stephan Michels wrote: > > > The patch method return a true if the patch was applied. > So I retry > > > to patch until there exists no patches to execute > anymore. It's not > > > perfect, but fulfil our needs. > > > > > Ah, I see - and in the case of an error you avoid endless loops, I > > guess? > > Yes I hope so ;-) > Great :) Carsten
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Fr, den 12.03.2004 schrieb Carsten Ziegeler um 10:35: > Stephan Michels wrote: > > > > The patch method return a true if the patch was applied. So I > > retry to patch until there exists no patches to execute > > anymore. It's not perfect, but fulfil our needs. > > > Ah, I see - and in the case of an error you avoid endless loops, > I guess? Yes I hope so ;-) Stephan.
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Stephan Michels wrote: > > The patch method return a true if the patch was applied. So I > retry to patch until there exists no patches to execute > anymore. It's not perfect, but fulfil our needs. > Ah, I see - and in the case of an error you avoid endless loops, I guess? Carsten
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Fr, den 12.03.2004 schrieb Carsten Ziegeler um 08:25: > Stephan Michels wrote > > > Ehm, are you sure that this works? The xconf's from the different > > > blocks have to be applied in the correct order (in the > > order of their > > > dependencies). If you all apply at once this is imho not > > guarenteed, > > > right? > > > > Now it should work. I rewrote the XConfTask. So, there is no > > problem the xsp-session-fw.xconf and others anymore. > > > Just curious, how does it work - how do you ensure that the xconf's > are applied in the correct order? The patch method return a true if the patch was applied. So I retry to patch until there exists no patches to execute anymore. It's not perfect, but fulfil our needs. Stephan.
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Stephan Michels wrote > > Ehm, are you sure that this works? The xconf's from the different > > blocks have to be applied in the correct order (in the > order of their > > dependencies). If you all apply at once this is imho not > guarenteed, > > right? > > Now it should work. I rewrote the XConfTask. So, there is no > problem the xsp-session-fw.xconf and others anymore. > Just curious, how does it work - how do you ensure that the xconf's are applied in the correct order? Carsten
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Do, den 11.03.2004 schrieb Carsten Ziegeler um 16:48: > [EMAIL PROTECTED] wrote: > > > > Modified:tools/src blocks-build.xsl > > Log: > > Apply all xconf file in one shoot. > > > Ehm, are you sure that this works? The xconf's from the different > blocks have to be applied in the correct order (in the order > of their dependencies). If you all apply at once this is imho > not guarenteed, right? Now it should work. I rewrote the XConfTask. So, there is no problem the xsp-session-fw.xconf and others anymore. Stephan.
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
[EMAIL PROTECTED] wrote: > > Modified:tools/src blocks-build.xsl > Log: > Apply all xconf file in one shoot. > Ehm, are you sure that this works? The xconf's from the different blocks have to be applied in the correct order (in the order of their dependencies). If you all apply at once this is imho not guarenteed, right? Carsten
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Mi, den 10.03.2004 schrieb Joerg Heinicke um 12:41: > On 10.03.2004 10:36, [EMAIL PROTECTED] wrote: > > > Modified:tools/src blocks-build.xsl > > ... > > > Using one classpath for all blocks instead of one classpath for each block. > > Any particular reason for this? I thought this was already in > preparation of real blocks. I had them problem that the sample classes of one block wasn't visible by the other, and I also want to reduce the builded build file. There is not more information in the block classpath, so I was able to merge the classpath easily. This change nothing (I hope). Stephan.
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
On 10.03.2004 10:36, [EMAIL PROTECTED] wrote: Modified:tools/src blocks-build.xsl ... Using one classpath for all blocks instead of one classpath for each block. Any particular reason for this? I thought this was already in preparation of real blocks. Joerg
Re: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Line 277 in blocks-build.xsl: Some else targets depend on this one. But what's the sense of it? Joerg
