Yep, I agree with the 2nd one if I undesrstand correctly. This should be the same thing put into the release as documentation.
Website content independent of a release should be in a separate project like "wicket-site" that is always published to the same place and not part of release documentation. - Brett On 7/16/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > BTW, I think I have answered my own question on what the best option is > between the two scenarios I described (the multiple deployment strategy > is my preferred one, as it doesn't break much). > > But comments from others are much appreciated. > > Martijn > > Martijn Dashorst wrote: > > > All, > > > > As the release and site manager of the Wicket project, I am trying to > > come up with a good scheme for uploading maven generated sites and > > putting this in projects. > > > > Currently we have all documentation in the xdocs folder of the Wicket > > project. I can simple do a > > maven clean site:deploy > > in order to have the new content to be available on the website. > > > > The problem arises when you have multiple versions of your project. We > > currently have 1.0 out there, and development is busy on 1.1 > > > > In order to support linking to online documentation, and not have > > those links become outdated, and in order to have an archive of the > > released versions documentation wise, I want to adopt the following > > layout: > > > > htdocs/ > > htdocs/wicket-1.0 > > htdocs/wicket-1.1 > > htdocs/wicket-x.y > > > > Method 1: Seperate projects > > ==================== > > Build and javadoc information should go into the wicket-x.y > > subdirectories, and will be generated as a normal maven java project. > > Sub versions will overwrite the contents of each wicket-x.y subdirectory. > > > > The main documentation (examples, feature lists, news, etc) are put > > into the root and or special subdirectories. This part of the site is > > generated from a seperate, special purpose project. > > > > Method 2: One project, multi deployments > > ============================== > > Another option is to keep the structure the way it currently is, and > > deploy the main site from the head of the trunc, and each release (and > > update) to the subdirectories. > > > > What is wisdom in my case. Has anyone else got a great idea for this? > > > > Martijn > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
