chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <>
Subject RE: OpenCMIS release check list
Date Mon, 03 May 2010 13:32:36 GMT
Hi Paul, hi Gabriele,

I like the general idea that Paul laid out. (I haven't looked into all the details yet.)
A nice version of the Confluence Wiki should become the main Chemistry web site. But we also
have to export the Confluence content to SVN when we cut the OpenCMIS release since this should
become the documentation that we want to ship. So we need the Doxia import as well.

- Florian

-----Original Message-----
From: Goetz, Paul [] 
Sent: Montag, 3. Mai 2010 14:51
Subject: RE: OpenCMIS release check list

Hi Gabriele,

sorry if the illustration might have caused some misunderstanding:
About step [1]: I didn't meant that there is a need for wget - it's just to illustrate how
a browser would retrieve the documentation. This and Step [2] is part of the Apache infrastructure
anyway, so nothing to do about it.
All we need to do on project side is to define how /www/ is
populated on minotaur.

There, we have three options:
- get content by a plain SVN checkout (step [3])
- get content generated from Maven (steps [6]/[7])
- get content edited in Confluence (steps [9]/[10])

We discussed that in the F2F - see Florian's mail "More F2F Notes" from 2010/04/14:
Chemistry web site:
* We would like to make an exported version of the Confluence Wiki the main Chemistry web

So my understanding was, that we combine the three options as follows:
- Static content (like landing page, icons, stylesheets) goes to SVN ([4]/[3])
- Manually edited content (the documentation) goes to Confluence ([8]/[9]/[10])
- Automated reports are still generated by Maven where applicable ([5]/[6]/[7])

If I got it right, you're suggesting to rethink that proposal and use Maven also for edited
content (moving the Confluence content to Maven).

So I will raise this question: Ok to use Confluence as "editing system", or should we go for
Maven sites?

I would prefer Confluence:
1. Others (e.g. Apache CXF and Apache Tuscany) do it that way, too.
2. It can be easily automated (autoexport-plugin already set up, [9] simply requires a velocity
template to be defined (in progress), [10] then becomes a copy operation).
3. It seems to be flexible enough to cover also non-Maven-built projects.

What do you think?

Best regards,

-----Original Message-----
From: Gabriele Columbro [] 
Sent: Montag, 3. Mai 2010 13:53
Subject: Re: OpenCMIS release check list

Hey Paul,
thanks for putting effort on linearizing the documentation process. A  
more than needed ECM effort :)

Below my comments on the process: I might be missing some details,   
but I believe we could leverage better the standard documentation  
tools from maven.

On May 2, 2010, at 11:33 PM, Goetz, Paul wrote:

> Hi,
> with regards to the documentation: you might have a look at

> .
> There's a first proposal how we could build the documentation.
> But as always, there are some open questions:
> - Is the proposed process ok for everyone? Any changes / suggestions?

As per step 1: isn't the site at 
chemistry/  just a plain empty generated "mvn site" with generic info  
about the project? Why we need to wget it when we can easily  
regenerate it as part of the mvn site process (step 6/7 in your  

> - For Step [7]: I'd assume that we will use the Maven Site info for  
> OpenCMIS. I wouldn't expect other (Non-Java) subprojects (cmislib,  
> JS-Client) to generate a Maven Site - so would one site be  
> sufficient (vs. every subproject having its own site)?

Agreed. Also for documentation deployment, can't we just use maven  
site deployment  [1] with SSH target repository, instead of using  
rsync / rcp? This can all be run by Hudson, by the means of a 'mvn  

> - For Step [10]: We could either do some magic transformation (like  
> HTML Tidy + removing some sections like <style.../style>|<script.../ 
> script>|<div class="greynavbar".../div>|<div class="footer".../div>, 

> and then apply the style sheets) - or we could change the template  
> for the CMIS site in Confluence (like CXF). Is there someone  
> experienced with Confluence templates?

Doxia, the Maven site engine, supports Confluence markup source pages  
[2], so we could do an initial import of confluence markup pages in  
SVN and have them neatly built by mvn (centralizing all documentation  
efforts  in Maven from that point on).
I can try to spike this in the next days, to basically streamline a  
process where:

- Current Confluence pages are added to SVN and then build by maven
- Current project information at is  
regenerated by the mvn build

1. New pages are added in any of the mvn site supported input formats  
[3] (BTW, you could also develop pages as drafts on Confluence first,  
and then add them to SVN when wanting to aggregate them to the  
"official" site)
2. Site is deployed by hudson by mvn site-deploy, possibly by a  
specific build plan on a different schedule

This approach definitely still needs to be tested, but I believe it  
can take off some maintenance burden and get us up to speed on this  
Am I missing something (I guess) ? :)

> If nobody objects, I would continue with the following todos:
> 1) initial check-in for website content to SVN [4]
> 2) add cronjob to do the SVN update for the website [3]
> 3) update OpenCMIS Maven site content and check-in to SVN [5]
> 4) add cronjob or Hudson task to replicate OpenCMIS' Maven site  
> target build to /www/ [7]
> 5) change the template for CMIS in Confluence
> 6) add cronjob to copy /www/confluence_export/CMIS to /www/ 
> Best regards,
> Paul

As I said I'm happy to help on this, as I've been working on mvn doc  
sites quite extensively in the past and it might get tricky to do the  
configuration bits.
Could start by adding a visual of the process here [4] , if you guys  
believe it's a valid option.




> -----Original Message-----
> From: David Caruana []
> Sent: Freitag, 30. April 2010 10:22
> To:
> Subject: Re: OpenCMIS release check list
> ---8<---
>> - web site update (as source of the documentation to be  
>> packaged) ... not started yet
> I can now confirm that Alfresco can provide someone to design/ 
> provide a skin for the web site.
> --->8---


Eng. Gabriele Columbro
Alfresco Software, Ltd.

M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro

View raw message