Hi Thomas, thanks for pointing me to turbine-site and the other informations. My conclusions are now:
I would now update fulcrum-site pom (similar to turbine site) excluding all fulcrum subdirectories. After this I would ((in trunk) move fulcrum/xdocs to fulcrum/site/xdocs, remove fulcrum/site/src/site/xdoc as it is duplicate. After doing this I´ll update site.xml and check the results (having removed fulcrum/xdocs). Considering that the subfolders "sites" and "howtos" should certainly not be excluded (cft. https://svn.apache.org/repos/infra/websites/production/turbine/content/fulcrum/ ), but that both have more html files site-deployed than I actually could find in any xdocs folder (except intake/xdocs/howto.xml) and that the missing (howto) files seem to be empty - is it ok, that they will be overwritten (deleted)? We have then a single point of entry for fulcrum update (wrapper mode) at fulcrum-site and each fulcrum module would have its own update mechanism (fulcrum parser or security is an example of how to do this best). I think using turbine-parent v3 is a good option, although I made a mistake saying that fulcrum-parent v2-SNAPSHOT depends on turbine-parent v2. It depends on v3 and could be used of course on that condition as well. Best regards, Georg Von: Thomas Vandahl <[email protected]> An: Turbine Developers List <[email protected]>, Datum: 04.12.2013 21:41 Betreff: Re: steps to update fulcrum site + parent Hi Georg, On 04.12.13 12:46, Georg Kallidis wrote: > how is the fulcrum site be prepared to get it up to date again ( > http://turbine.apache.org/fulcrum/ ) ? I guess "not at all" describes it best. Sorry for the mess. > This has be done probably the last time from the trunk. I think, if we > update now the site the released components get the Javadocs from the > current trunk. Is this ok? A tagged version should then be generated for > the entire fulcrum tree (?). Some more updates seem to the necessary > (xdocs7navigation.xml, pom.xml...). I have some more concerns to do this > right now: I don't think so. The Fulcrum site is not a multiproject build AFAIR. And if it is currently, it should not be. All links are done manually. Be aware that all module directories *must* be excluded from the scm-publish plugin or else a commit will delete them. The best option would be to disable deletes completely. See the Turbine-site POM for an example. > 1) Dependencies: Building the site fails due to the fact, that a lot of > fulcrum (cache, bsf, commonsmail, crypto) components depend on > fulcrum-parent v1 (current version is v2-SNAPSHOT). Changing the version > to v2-SNAPSHOT the site build seems to execute successfully. But the > parent fulcrum-parent v2-SNAPSHOT depends on turbine-parent v2 not the > current turbine-parent v3. Do we not need another fulcrum-parent, which > does depend on turbine-parent version 3? Well, I tried to kill the additional parent level with the components that I updated recently. Fulcrum-parser for example derives directly from Turbine-parent 3. So does Fulcrum-intake. I don't know if this is wise, however, my related question on the mailing list remained unanswered. So I decided to go ahead. Right now this means to configure the assembly plugin in each and every component POM which is sub-optimal to say the least. I thought about a "Fulcrum profile" in the parent POM but couldn't get it to work. > 2) Labeling: In the current fulcrum site there is no section for non > released components or components in development. Shouldn´t be the > dormant components renamed to components in development? This could > include old "dormant" and new not released components. Within Apache Commons, there are "proper", "dormant" and "sandbox" components. I'd suggest to go with these terms. From what I understand, "dormant" means unmaintained whereas "sandbox" means "not yet released". Hope this helps. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
