Re: [RT] Flattening trunk
Niclas Hedhman wrote: On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote: I think we should move the content of trunk/src/ to trunk/, and start considering them as separate projects (blocks). I would be really happy if a top-level build script (maven, ant, bash, perl, whatever) is maintained for us poor souls who wouldn't know what depends on what, and in which order stuff needs to be built. Doesn't need to support everything, just one sweep to compile/package each part. Also, in the long run, consider getting rid of the ttb structure, drop the heritage from CVS and make a more direct statement; /repos/asf/cocoon/ main/ legacy2.1/ releases/ experiments/ or something along those lines. We already considered this, but do we group them by code-stability, community stability, functionality, etc, etc, etc. The simplest is to have a flat structure, and have meta-data to describe them in as many ways as is required. Regards, Upayavira
Re: [RT] Flattening trunk
Niclas Hedhman wrote: On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote: I think we should move the content of trunk/src/ to trunk/, and start considering them as separate projects (blocks). I would be really happy if a top-level build script (maven, ant, bash, perl, whatever) is maintained for us poor souls who wouldn't know what depends on what, and in which order stuff needs to be built. That is the intention, you can see that there is a toplevel POM in the new M2 build. IIUC M2 POMs describe all the dependencies and the block POMs refers to the toplevel POM and build the needed blocks. Doesn't need to support everything, just one sweep to compile/package each part. Also, in the long run, consider getting rid of the ttb structure, drop the heritage from CVS and make a more direct statement; /repos/asf/cocoon/ main/ legacy2.1/ releases/ experiments/ or something along those lines. Agree. As your explanation is somewhat terse I expand a little bit on it. When we discussed repository structure in Felix I propsed that we should follow the same structure as for Cocoon blocks with ttb(=trunk/tag/branch) under each bundle directory. Niclas instead propsed: Personally, I don't use tags and branches at all. Code that are released, are copied into a proper directory named releases, and straight after made read-only. Branches are handled differently depending on whether it is an experiment (in which case it is just copied to my laboratory) or it is maintenance of released code, in which case I first copy the release into a temporary area, do the changes and then create a new release make readonly and so forth. Which we all agreed about as it seem to be more practical. We should do the same for Coccon IMO. In the directory structure above we would have main/ pom.xml apples/ asciiart/ ... core/ ... webapp/ ... or maybe with a subdirectory for blocks, not certain if I want that as everything is blocks anyway. All the blocks are own projects and when we release a block we put it in releases: releases/ core-2.2.0 core-2.2.1 ... cforms-0.9 ... portal-2.1 ... Simple and easy to understand! /Daniel
[RT] Flattening trunk
As a step in our continuos strugle to make Cocoon less monolithic I think we should move the content of trunk/src/ to trunk/, and start considering them as separate projects (blocks). Carsten have already started to do something in this direction by creating a core and webapp directory (with POMs but not source) at trunk level as part of Mavenization. The toplevel projects should be possible to build separately and all dependencies should be explicit in the POMs. It also makes sense from a real blocks POV as most of the directories under trunk/src/ are or will become bundles. Eclipse organizes its bundles in a flat way: http://dev.eclipse.org/viewcvs/index.cgi/. There is also a bewildering amount of files under trunk/, meybe we could move part of them to subdirectories like bin/, conf/ and readme/. WDYT? /Daniel
Re: [RT] Flattening trunk
Daniel Fagerstrom wrote: It also makes sense from a real blocks POV as most of the directories under trunk/src/ are or will become bundles. Eclipse organizes its bundles in a flat way: http://dev.eclipse.org/viewcvs/index.cgi/. So this means roughly 3 same-level directories per block right? For example: 1)org.apache.cocoon.lucene - mavenized, osgi enabled Real Block or Bundle - Exported to m2 repo 2)org.apache.cocoon.lucene.samples - mavenized, non-osgi block with sitemap resources and java sources. - Explicit pom dependency on 1) - Not exported to the m2 repository 3)org.apache.cocoon.lucene.test - mavenized, non-osgi block with (unit)tests for 1) - Explicit pom dependency on 1) - Not exported to the m2 repository Is this correct ? Jorg
Re: [RT] Flattening trunk
Jorg Heymans wrote: Daniel Fagerstrom wrote: It also makes sense from a real blocks POV as most of the directories under trunk/src/ are or will become bundles. Eclipse organizes its bundles in a flat way: http://dev.eclipse.org/viewcvs/index.cgi/. So this means roughly 3 same-level directories per block right? For example: 1)org.apache.cocoon.lucene - mavenized, osgi enabled Real Block or Bundle - Exported to m2 repo 2)org.apache.cocoon.lucene.samples - mavenized, non-osgi block with sitemap resources and java sources. - Explicit pom dependency on 1) - Not exported to the m2 repository Yes, IIRC, we decided a while ago to have samples as separate blocks. Carsten have allready done this for the portal. For the sample block I think it will be a OSGi bundle and real block as well. It will have an block.xml that describes where the sitemap is (and possibly other things) and it will export sitemap functionality that will be mounted at a certain point in the URI space. 3)org.apache.cocoon.lucene.test - mavenized, non-osgi block with (unit)tests for 1) - Explicit pom dependency on 1) - Not exported to the m2 repository For unit tests I'm not certain about the best way to solve it. I think that it might become unpractical to manage them without using OSGi, as OSGi takes care about the classloading for blocks that depend on other blocks, without OSGi we have to simulate its classloading behaviour. OTH if we use OSGi, the block will need to export all packages that it want to unit test, if the tests are in a separate block, this kills isolation. Maybe we can have the unit tests inside the block and be able to remove them when exporting to the M2 repo? Are there any design patterns for unit testing Eclipse plugins that we can reuse? For functional tests it makes sense to have a separate test block that test the block from the outside. Knopflerfish have a JUnit bundle that supports such testing http://www.knopflerfish.org/releases/1.3.3/jars/junit/junit_all-1.0.0.html, http://www.knopflerfish.org/releases/1.3.3/jars/junit_runner/junit_runner_all-1.0.0.html. /Daniel
Re: [RT] Flattening trunk
Daniel Fagerstrom wrote: So this means roughly 3 same-level directories per block right? For example: 1)org.apache.cocoon.lucene - mavenized, osgi enabled Real Block or Bundle - Exported to m2 repo 2)org.apache.cocoon.lucene.samples - mavenized, non-osgi block with sitemap resources and java sources. - Explicit pom dependency on 1) - Not exported to the m2 repository Yes, IIRC, we decided a while ago to have samples as separate blocks. Carsten have allready done this for the portal. For the sample block I think it will be a OSGi bundle and real block as well. It will have an block.xml that describes where the sitemap is (and possibly other things) and it will export sitemap functionality that will be mounted at a certain point in the URI space. Ok got it now. 3)org.apache.cocoon.lucene.test - mavenized, non-osgi block with (unit)tests for 1) - Explicit pom dependency on 1) - Not exported to the m2 repository For unit tests I'm not certain about the best way to solve it. I think that it might become unpractical to manage them without using OSGi, as OSGi takes care about the classloading for blocks that depend on other blocks, without OSGi we have to simulate its classloading behaviour. OTH I forgot about the special requirements that OSGi dependency resolution has. Yes, it will become mighty unpractical and a waste of energy to try and manage this ourselves. if we use OSGi, the block will need to export all packages that it want to unit test, if the tests are in a separate block, this kills isolation. Maybe we can have the unit tests inside the block and be able to remove them when exporting to the M2 repo? Are there any design patterns for unit testing Eclipse plugins that we can reuse? IIUC, m2 supports this layout with the testSourceDirectory/ and testOutputDirectory/ elements. For functional tests it makes sense to have a separate test block that test the block from the outside. Knopflerfish have a JUnit bundle that supports such testing http://www.knopflerfish.org/releases/1.3.3/jars/junit/junit_all-1.0.0.html, http://www.knopflerfish.org/releases/1.3.3/jars/junit_runner/junit_runner_all-1.0.0.html. I hope m2's unittest implementation is pluggable, otherwise this sounds like a good candidate for an m2 plugin. Jorg (with a note to self: start reading up on OSGi!)
Re: [RT] Flattening trunk
On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote: I think we should move the content of trunk/src/ to trunk/, and start considering them as separate projects (blocks). I would be really happy if a top-level build script (maven, ant, bash, perl, whatever) is maintained for us poor souls who wouldn't know what depends on what, and in which order stuff needs to be built. Doesn't need to support everything, just one sweep to compile/package each part. Also, in the long run, consider getting rid of the ttb structure, drop the heritage from CVS and make a more direct statement; /repos/asf/cocoon/ main/ legacy2.1/ releases/ experiments/ or something along those lines. Cheers Niclas
