Re: [cron block] dependency question
Reinhard Poetz wrote: Some thoughts I want to share: goal: move towards real blocks - do as much work that can be reused later - each block has its own build system Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Vadim
Re: [cron block] dependency question
Unico Hommes wrote: Reinhard Poetz wrote: Unico Hommes wrote: Some thoughts I want to share: goal: move towards real blocks - do as much work that can be reused later - each block has its own build system IIRC, Nicola already started an effort for an updated build system that features an individual build file for each block separately. I wonder what happened to that and whether it is useable already. - each block has a public and a private directory What does that do? uups, I mean a public and a private source directory. Other blocks mustn't depend on private classes - each block has a deployment descriptor: * list of blocks that are necessary to make them compile/run * list of blocks that are necessary at runtime (e.g. forms needs xsp because of the examples) * list of all libraries (all libraries are in a single Cocoon library repository and this way we can make sure that we don't end at jar hell -- real block and their shielding will finally solve this) -- create gump file -- create eclipse/idea project files - each block only depends on - cocoon core - public sources of other blocks This is the same file as blocks.xml for real blocks right? Yep only stripped down for our current needs a complete build runs through following steps: - compile Cocoon core - one build task that compiles all public directories at once (or can we make sure that there are no circular dependencies, which should be avoided of course) - compile each block separatly - create web application - deploy each block separatly - copy samples - patch configuration files but of course only a single block can be deployed too It's probably a lot of work but sooner or later we have to do it anyway, so why should we suffer from our build system and a gigantic eclipse project any longer For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core . IMO the eclipse project file for a block contains - two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional) This way we don't have to deal with Eclipse project dependencies, do we? -- Reinhard
Re: [cron block] dependency question
Carsten Ziegeler wrote: Unico Hommes wrote: Ok ok, I get the hint ;-) Oh, that wasn't targetted at you, Unico, but if you have time... :) I didn't really feel that it was. It just seems opportune that I take up the issue since I raised it. I'll see what I can do. But before I decide to do any work there is another issue with the blocks build system I'm dying to resolve. What about having only one repository location for blocks? I am so tired of all the duplicate effort we have to do for each and every change to blocks. It shouldn't be neccessary. Yes, and it should be simple. There probably isn't a small amount of work involved to get it working but I'd like to know exactly what it would take to byte this bullet. Some of the steps involved that I can distinguish are: 1. Merge/sync the current 2.1.x and 2.2 blocks.What blocks have the biggest differences between their 2.1.x and 2.2 copy? If there are unresolvable differerences, how to handle that? Have separate source locations for different versions in conflicting blocks? Define Cocoon target versions for individual blocks in gump.xml? We have to finish the syncing, The wiki still lists some blocks that haven't been synced yet - but again this is simple work. Ah thanks for the pointer. I see there is plenty I can do in that departement. Apart from that, some blocks depend (unfortunately) on some internal things which have changed between 2.1.x and 2.2. The most prominent is of course XSP. But there are others that now take advantage of some new features in 2.2 that aren't available in 2.1.x. So in the end this is not so easy. We could start simple. First move blocks that don't have a difference and leave the different ones in the two branches. Hmm, that doesn't make the build system any simpler, but alas, we can clean up after the migration is complete. But I would strongly suggest that we first finish syncing, can then do a painless 2.1.6 release and then spend energy on this issue. I personally don't want to delay a 2.1.6 release just because of a broken build system etc. That is true. Is there anything holding back a 2.1.6 release btw? -- Unico
Re: [cron block] dependency question
Carsten Ziegeler wrote: then do a painless 2.1.6 release and then spend energy on this issue. I personally don't want to delay a 2.1.6 release just because of a broken build system etc. I agree, first the release (and sync) and then the change in the build system. -- Reinhard
RE: [cron block] dependency question
Unico Hommes wrote: That is true. Is there anything holding back a 2.1.6 release btw? Apart from the syncing there is only one test that fails according to Vadim. So, as soon as we have synced we can release. Carsten
Re: [cron block] dependency question
Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core . IMO the eclipse project file for a block contains - two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional) This way we don't have to deal with Eclipse project dependencies, do we? Ah, so you mean to keep the notion of a single eclipse project but one whose project descriptor is split between a top level core one that references project fragments inside individual blocks using entity references? I am just guessing. At least in eclipse this is illegal: ./.project.xml ./blocks/blockA/.project.xml Opening both projects at the same time in the same workspace is not possible. -- Unico
Re: [cron block] dependency question
Unico Hommes wrote: Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core . IMO the eclipse project file for a block contains - two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional) This way we don't have to deal with Eclipse project dependencies, do we? Ah, so you mean to keep the notion of a single eclipse project but one whose project descriptor is split between a top level core one that references project fragments inside individual blocks using entity references? I am just guessing. At least in eclipse this is illegal: ./.project.xml ./blocks/blockA/.project.xml Opening both projects at the same time in the same workspace is not possible. I understood him to mean one project per block. I'd prefer one project for all blocks. Having said that, there's no reason why we couldn't have: trunk/blocks/.project trunk/blocks/forms/.project trunk/blocks/databases/.project etc That way, you can do it which ever way suits you. Upayavira
Re: [cron block] dependency question
Upayavira wrote: Unico Hommes wrote: Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core . IMO the eclipse project file for a block contains - two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional) This way we don't have to deal with Eclipse project dependencies, do we? Ah, so you mean to keep the notion of a single eclipse project but one whose project descriptor is split between a top level core one that references project fragments inside individual blocks using entity references? I am just guessing. At least in eclipse this is illegal: ./.project.xml ./blocks/blockA/.project.xml Opening both projects at the same time in the same workspace is not possible. I understood him to mean one project per block. I'd prefer one project for all blocks. Having said that, there's no reason why we couldn't have: trunk/blocks/.project trunk/blocks/forms/.project trunk/blocks/databases/.project etc That way, you can do it which ever way suits you. But the core project descriptor currently is trunk/.project that should become trunk/core/.project in order to be able to open both core and blocks projects in the same workspace. -- Unico
Re: [cron block] dependency question
Vadim Gritsenko wrote: Reinhard Poetz wrote: Some thoughts I want to share: goal: move towards real blocks - do as much work that can be reused later - each block has its own build system Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [cron block] dependency question
Upayavira wrote: Unico Hommes wrote: Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core . IMO the eclipse project file for a block contains - two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional) This way we don't have to deal with Eclipse project dependencies, do we? Ah, so you mean to keep the notion of a single eclipse project but one whose project descriptor is split between a top level core one that references project fragments inside individual blocks using entity references? I am just guessing. At least in eclipse this is illegal: ./.project.xml ./blocks/blockA/.project.xml Opening both projects at the same time in the same workspace is not possible. I understood him to mean one project per block. I'd prefer one project for all blocks. Having said that, there's no reason why we couldn't have: trunk/blocks/.project trunk/blocks/forms/.project trunk/blocks/databases/.project etc That way, you can do it which ever way suits you. That's the idea. If you prefer having one project per block or prefer one project for all blocks + core, both should work. -- Reinhard
Re: [cron block] dependency question
Nicola Ken Barozzi wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: Some thoughts I want to share: goal: move towards real blocks - do as much work that can be reused later - each block has its own build system Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. nothing to be added :-) -- Reinhard
RE: [cron block] dependency question
Nicola Ken Barozzi wrote: Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. Hmm, to be honest this frightens me a little bit. I really hope that we are not experiencing the avalon build system problem where each module had his own build file with all this complex library and dependency handling and the final result was that noone was able to use the build system for months. Then going back and force from Ant to Maven etc. which in the end didn't really help. But in the end I trust you and I guess *we* will not suffer from these problems. Let's just try to keep it as simple as possible, but working :) Carsten
Re: [cron block] dependency question
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. Hmm, to be honest this frightens me a little bit. I really hope that we are not experiencing the avalon build system problem where each module had his own build file with all this complex library and dependency handling and the final result was that noone was able to use the build system for months. Then going back and force from Ant to Maven etc. which in the end didn't really help. But in the end I trust you and I guess *we* will not suffer from these problems. Let's just try to keep it as simple as possible, but working :) The simplest possible thing would be to have a block descriptor extend a maven POM and use maven to build them. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [cron block] dependency question
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. Hmm, to be honest this frightens me a little bit. I really hope that we are not experiencing the avalon build system problem where each module had his own build file with all this complex library and dependency handling and the final result was that noone was able to use the build system for months. Then going back and force from Ant to Maven etc. which in the end didn't really help. But in the end I trust you and I guess *we* will not suffer from these problems. Let's just try to keep it as simple as possible, but working :) we don't have to break our build system. we already have a new-targets directory where we can create a new build system. and when everything is working smoothly, we can switch. so don't worry :-) -- Reinhard
[cron block] dependency question
I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dependency on the cocoon databases block. Not because of a compilation dependency on the source code of that block but on a jar in its lib directory. Am I correct in assuming that the policy on this is that I move the excalibur-datasource jar to lib/optional? -- Unico
Re: [cron block] dependency question
Unico Hommes wrote: I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dependency on the cocoon databases block. Not because of a compilation dependency on the source code of that block but on a jar in its lib directory. Am I correct in assuming that the policy on this is that I move the excalibur-datasource jar to lib/optional? Just an idea; can we move ALL libraries to lib/optional, and copy them into the WEB-INF/lib on as-needed basis, i.e. if block included which needs a library, only then librariy is copied over? This should be possible using the info from gump.xml... This way we could eliminate several pseudo dependencies like this. Vadim
[GUMP][PATCH] missed one avalon-framework dependency
Hi, when David changed the descriptor to reflect the avalon restructuring, one reference to avalon-framework was missed - it was well hidden by Gump. Please apply the appended patch to finally get nagged again ;-) Cheers Stefan -- http://stefanbodewig.blogger.de/ Index: gump.xml === --- gump.xml(revision 43688) +++ gump.xml(working copy) @@ -40,7 +40,7 @@ ant target=gump-core property name=version value=@@DATE@@/ depend property=logkit.jar project=avalon-logkit/ - depend property=avalonapi.jar project=avalon-framework id=api/ + depend property=avalonapi.jar project=avalon-framework-api/ /ant depend project=ant inherit=runtime/
Re: [GUMP][PATCH] missed one avalon-framework dependency
Stefan Bodewig wrote: Hi, when David changed the descriptor to reflect the avalon restructuring, one reference to avalon-framework was missed - it was well hidden by Gump. Please apply the appended patch to finally get nagged again ;-) now that we have SVN, could we say that gump.xml in cocoon is writeable by all the ASF committers, just like gump? that would allow gumpers to help out *and* the cocoon build system to still function and being more actively maintained? thoughts? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [GUMP][PATCH] missed one avalon-framework dependency
Stefano Mazzocchi dijo: now that we have SVN, could we say that gump.xml in cocoon is writeable by all the ASF committers, just like gump? that would allow gumpers to help out *and* the cocoon build system to still function and being more actively maintained? thoughts? +1 Best Regards, Antonio Gallardo
Re: [PATCH] tour block has dependency on slop
Good to know thanks ! Jorg Joerg Heinicke wrote: Thanks for the hint. Important is adding the dependency in gump.xml. The blocks.properties is only generated by build generate-blocks.properties. Joerg
[PATCH] tour block has dependency on slop
Index: blocks.properties === RCS file: /home/cvspublic/cocoon-2.1/blocks.properties,v retrieving revision 1.80 diff -u -r1.80 blocks.properties --- blocks.properties 7 Jun 2004 01:04:18 - 1.80 +++ blocks.properties 7 Jun 2004 14:46:23 - @@ -140,10 +140,11 @@ #include.block.serializers=false #-[dependency]: slide depends on jms, repository. #include.block.slide=false +#-[dependency]: slop is needed by tour. #include.block.slop=false #include.block.stx=false #include.block.taglib=false -#-[dependency]: tour depends on batik, fop, forms. +#-[dependency]: tour depends on batik, fop, forms, slop. #include.block.tour=false #-[dependency]: webdav depends on repository. #include.block.webdav=false
Re: [PATCH] tour block has dependency on slop
Thanks for the hint. Important is adding the dependency in gump.xml. The blocks.properties is only generated by build generate-blocks.properties. Joerg
Slide/jms dependency
I am looking into adding a class to the Slide block that sends invalidation events over JMS so that the event caching system can pick them up and do its work accordingly. However, I am running into the problem that the class depends on the jms jar that is in the jms block. I tried adding a dependency on the jms block in gump.xml but that doesn't seem to work. Should there be a way declare a dependency on another block so that all of *its* dependencies are traversed and added to the compilation classpath as well? The other solution is to have a copy of the same jar in the Slide block too. WDOT? Unico
RE: Slide/jms dependency
Aw shoot, please ignore this. It seems that depending on a block *does* add its dependencies to the classpath. The reason I didn't see it was that the target I was running didn't recreate blocks-build.xml. Sorry for the noise. Unico -Original Message- From: Unico Hommes Sent: dinsdag 13 januari 2004 11:54 To: [EMAIL PROTECTED] Subject: Slide/jms dependency I am looking into adding a class to the Slide block that sends invalidation events over JMS so that the event caching system can pick them up and do its work accordingly. However, I am running into the problem that the class depends on the jms jar that is in the jms block. I tried adding a dependency on the jms block in gump.xml but that doesn't seem to work. Should there be a way declare a dependency on another block so that all of *its* dependencies are traversed and added to the compilation classpath as well? The other solution is to have a copy of the same jar in the Slide block too. WDOT? Unico
Re: Portal dependency on JDOM is overrated?
Joerg Heinicke [EMAIL PROTECTED] wrote: Carsten is in holidays for three weeks, but maybe one of the other SN people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with JDOM or the other way around? I'm not familiar with the portal code and don't know of any planned refactoring. I'd say if JDOM isn't used, remove it. I'll take Carsten's rage ;-) Guido (Maybe one of the BASF people know more, Volker?) Joerg Vadim Gritsenko wrote: Couple of portal files: cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\P ortalApplicationConfig.java cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\P ortalApplicationConfigFactory.java excplicitly mention JDOM in theirs Javadoc. But anywhere in code they require JDOM, just good'ol w3c DOM. I presume that this is it a bug in Javadoc which can easily be fixed? Joerg Heinicke wrote: Can we also remove JDOM completely? I didn't see any relation to the Cocoon project and could exclude it from build without any problems with compiling. Sure. Let's clear up this above issue, and then I'll remove jdom too. Vadim
Re:Re: Portal dependency on JDOM is overrated?
I think it is only a documentation fault. I add the author to CC ([EMAIL PROTECTED]) Volker Joerg Heinicke [EMAIL PROTECTED] wrote: Carsten is in holidays for three weeks, but maybe one of the other SN people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with JDOM or the other way around? I'm not familiar with the portal code and don't know of any planned refactoring. I'd say if JDOM isn't used, remove it. I'll take Carsten's rage ;-) Guido (Maybe one of the BASF people know more, Volker?) Joerg Vadim Gritsenko wrote: Couple of portal files: cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\P ortalApplicationConfig.java cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\P ortalApplicationConfigFactory.java excplicitly mention JDOM in theirs Javadoc. But anywhere in code they require JDOM, just good'ol w3c DOM. I presume that this is it a bug in Javadoc which can easily be fixed? Joerg Heinicke wrote: Can we also remove JDOM completely? I didn't see any relation to the Cocoon project and could exclude it from build without any problems with compiling. Sure. Let's clear up this above issue, and then I'll remove jdom too. Vadim
Portal dependency on JDOM is overrated?
Couple of portal files: cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfig.java cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfigFactory.java excplicitly mention JDOM in theirs Javadoc. But anywhere in code they require JDOM, just good'ol w3c DOM. I presume that this is it a bug in Javadoc which can easily be fixed? Joerg Heinicke wrote: Can we also remove JDOM completely? I didn't see any relation to the Cocoon project and could exclude it from build without any problems with compiling. Sure. Let's clear up this above issue, and then I'll remove jdom too. Vadim
Re: Portal dependency on JDOM is overrated?
Carsten is in holidays for three weeks, but maybe one of the other SN people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with JDOM or the other way around? Joerg Vadim Gritsenko wrote: Couple of portal files: cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfig.java cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfigFactory.java excplicitly mention JDOM in theirs Javadoc. But anywhere in code they require JDOM, just good'ol w3c DOM. I presume that this is it a bug in Javadoc which can easily be fixed? Joerg Heinicke wrote: Can we also remove JDOM completely? I didn't see any relation to the Cocoon project and could exclude it from build without any problems with compiling. Sure. Let's clear up this above issue, and then I'll remove jdom too. Vadim
