hi jukka, On 7/10/05, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > Some more ideas after thinking about the build issues a bit more. > > Directory layout > ---------------- > > Roy is right in that the directory layout could do with some cleaning > up. A proposal: > > jackrabbit/ > ./api > ./commons > ./core > ./applications > ./xdocs > ./subprojects > ./jcr-rmi > ./jcr-server > ./orm-persistence > ... > ./contrib > ./examples > ./jcr-commands > ./jcr-ext > ./jcrtaglib > ./phpcr > ./tck-webapp > ./textfilters > ./vfs > ... > > Commentary: > > * We'd keep the main Jackrabbit components (api, commons, and core) at > the top level as they are now. They can be built and managed using a > Maven multiproject setup at the top level Jackrabbit directory.
+1 > > * The mature subprojects (like jcr-server) would be placed in > ./subprojects and managed as independent entities. It might be useful to > include also them in the top level multiproject setup. At least they > should be included in the site build. The same level of commit > discipline (little or no failing builds) would be required as for the > main components. in general +1; however, if the subprojects were to be included in the top level multiproject it should still be possible to build 'just' jackrabbit without the subprojects. i am a little worried that work on core could be hampered otherwise. there's still the possibility of necessary major changes in the core that could break some subprojects. > > * The contrib projects would remain in ./contrib. They'd not be included > in any of the top level builds, but (if made possible by the main site > build script) contrib authors could commit their site builds to > site/contrib to publish information about the contrib projects on the > Jackrabbit web site. +1 > > * The ./application and ./xdocs directories remain as they are. I'm not > totally happy with the current use of the ./application/test repository > directory (it would be nicer to have it inside ./target), but that's > another discussion. +1 > > Top-level build > --------------- > > As proposed by Roy, we should use the Maven Multi-Project plugin to > manage builds at the top level. The maven.multiproject.includes property > should be either the default (include only the main modules) or > "*/project.xml,subprojects/*/project.xml" (include also the mature > subprojects). +1 > > Additionally, to avoid dependency problems like the recent "maven clean" > issue, we should change the "-dev" suffix to the Maven-standard > "-SNAPSHOT" and start publishing periodic binary snapshots either on the > Day repository or at Ibiblio. This would be nice for other purposes as well. +1 > > Web site navigation > ------------------- > > Following the above directory layout proposal, we could divide the web > site like this: > > Apache Jackrabbit > [the current documentation] > Jackrabbit components > Jackrabbit API > Jackrabbit Commons > Jackrabbit Core > Jackrabbit subprojects > JCR-RMI > JCR Server > ORM Persistence > ... > Jackrabbit contributions > ... > > The new sections would contain pointers to the individual subsites > generated by multiproject. General documentation would remain at the top > level, and the technical details (generated javadocs, developer > instructions, TODOs, etc.) would be included in the subsites. +1 > > IDE and tool support > -------------------- > > It would be nicer for IDEs and various tools if the current main modules > would _not_ extend the top level project.xml. For example at the moment > you cannot just grab jackrabbit/commons and build it. Instead you need > to get the whole Jackrabbit source tree to do this. As the top level > project.xml contains mostly just descriptive information not directly > used in building the sources, I'd propose removing this dependency. It > would remove the contributor and mailing list information from the > module projects, but I think we could manage with having that > information only at the top level. +1 btw: great job, thanks for taking the lead on this task! cheers stefan > > BR, > > Jukka Zitting >
