You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2008/03/04 23:42:18 UTC
[PROPOSAL] Move to confluence and cwiki for project website and documentation
Dear community,
I'm cross-posting this proposal to the developers lists of our other sibling projects, Pluto and Bridges, as well as our PMC as I think it might be of interest
to the whole Portals community.
For now though, my proposal only targets the Jetspeed project web site, and I'd like to hear who might be interested in this .
Until now, we've been defining our jetspeed website and documentation in (Maven-1) xdoc format, which makes it possible to maintain it in the svn repository,
and more or less "seemingly" integrate project meta-data and end user documentation in one central location to be pushed out (after generation) as our primary
project website and documentation.
While this more or less works "ok", as we all know, maven site generation has it peculiar quirks, and quite strict (and limiting) rules to obey to get it
working correctly.
Furthermore, although the goal of maintaining the documentation definitions versioned in svn by itself doesn't seem like a bad idea, in practice this poses
logical problems once a "release" tag has been set. Most commonly, the website documentation is in need of updating/correcting for an already released version,
so changes usually are committed against the svn trunk which might already be (way) ahead in development.
One solution would be to maintain separate "documentation update" branches in svn, but that's cumbersome too to say the least.
On top of that, it is very difficult (and very impractical) to maintain online documentation for multiple release versions, while end users most likely will be
using different/older version(s) than just the current (trunk) development version.
And maintaining the maven site documentation in xdoc (or apt or even some more exotic) format is in practice, in my personal view, horrible to do.
AFAIK, there still isn't any good GUI support for writing this but using plain ASCII or XML format, and using and maintaing correct anchors and image references
without any proper (direct) feedback mechanism is quite error prone. For some this might be the perfect tool, but in my personal experience, these limitations
have hindered us (as project committers) very much in writing and providing some good and proper documentation.
Writing documentation usually already isn't the best quality of us coders (certainly not mine), but having to do so in maven site format definitely doesn't help.
Finally, although we have a MoinMoin Wiki for Jetspeed-2 too (see: http://wiki.apache.org/portals/jetspeed2) which can be used by both the committers and other
community members to provide more direct and interactive documentation, in reality hardly anyone uses it, is (in my view) ugly and difficult to use, and
contains mostly stale/outdated information.
And now, with our recent restructuring of our svn by moving the j2-admin and other portlet applications to a separate applications root folder so they now will
have their own life cycle, even more complex challenges arise. Maintaining and *integrating* two or even more maven generated websites under one primary site is
definitely not going to be easy (forget about maintaining documentation for multiple releases) ...
As we now are working on a major overhaul of the Jetspeed-2 build system (dropping the old maven-1/2 structure and replacing it with a clean maven-2 project
rewrite from scratch), maybe this now also is the right time to evaluate our current project documentation and website generation solution.
And as probably already obvious from my above "rant" against our current solution, I'd like to propose something completely different.
Since quite some time, several other Apache projects have moved to Confluence for their documentation tasks *and* their project website "generation".
Some good and also very nice *and* different looking examples are:
Cayenne - http://cayenne.apache.org
Directory - http://directory.apache.org
Felix - http://felix.apache.org
Geronimo - http://geronimo.apache.org
James - http://james.apache.org
Wicket - http://wicket.apache.org
and there are several more.
Although Confluence is a real wiki, with an AutoExport plugin a static HTML site snapshot can automatically be created (after each change or update) and used as
basis for a Apache project website. Additionally, Velocity scripts can be run during the export to provide additional formatting for a custom styled website.
Although I could try to describe here all the procedures and possibilities of this solution and the benefits it brings, I think it better to read up on these
yourself and also see how these other projects are using it.
The primary documentation can be found here:
http://cwiki.apache.org/CWIKI/
The Geronimo and Wicket projects have some nice additional documentation how they make use of this:
http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html
and
http://wicket.apache.org/writing-documentation.html
My proposal is simple:
- switch to using this Confluence+cwiki solution
- maintain separate Confluence spaces for release specific documentation for jetspeed-2, j2-admin and future products
- also allow selected end users (non-committers but with a CLA on file, see main CWIKI documentation for explanation)
to maintain these official documentation spaces
- also switch to using Confluence for our public jetspeed-2 wiki (replacing MoinMoin) for additional non-official/endorsed project information
- integrate all the above in one new main cwiki based jetspeed-2 project website
WDYT?
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by David Sean Taylor <da...@bluesunrise.com>.
All the x-posting confuses me.
Now that everyone is aware of the proposal, can we discuss this on
general?
I like the idea of using Confluence. In general I am +1.
Just a few questions, which I will ask on general...
On Mar 4, 2008, at 2:42 PM, Ate Douma wrote:
> Dear community,
>
> I'm cross-posting this proposal to the developers lists of our
> other sibling projects, Pluto and Bridges, as well as our PMC as I
> think it might be of interest to the whole Portals community.
>
> For now though, my proposal only targets the Jetspeed project web
> site, and I'd like to hear who might be interested in this .
>
> Until now, we've been defining our jetspeed website and
> documentation in (Maven-1) xdoc format, which makes it possible to
> maintain it in the svn repository, and more or less "seemingly"
> integrate project meta-data and end user documentation in one
> central location to be pushed out (after generation) as our primary
> project website and documentation.
>
> While this more or less works "ok", as we all know, maven site
> generation has it peculiar quirks, and quite strict (and limiting)
> rules to obey to get it working correctly.
>
> Furthermore, although the goal of maintaining the documentation
> definitions versioned in svn by itself doesn't seem like a bad
> idea, in practice this poses logical problems once a "release" tag
> has been set. Most commonly, the website documentation is in need
> of updating/correcting for an already released version, so changes
> usually are committed against the svn trunk which might already be
> (way) ahead in development.
>
> One solution would be to maintain separate "documentation update"
> branches in svn, but that's cumbersome too to say the least.
>
> On top of that, it is very difficult (and very impractical) to
> maintain online documentation for multiple release versions, while
> end users most likely will be using different/older version(s) than
> just the current (trunk) development version.
>
> And maintaining the maven site documentation in xdoc (or apt or
> even some more exotic) format is in practice, in my personal view,
> horrible to do.
> AFAIK, there still isn't any good GUI support for writing this but
> using plain ASCII or XML format, and using and maintaing correct
> anchors and image references without any proper (direct) feedback
> mechanism is quite error prone. For some this might be the perfect
> tool, but in my personal experience, these limitations have
> hindered us (as project committers) very much in writing and
> providing some good and proper documentation.
> Writing documentation usually already isn't the best quality of us
> coders (certainly not mine), but having to do so in maven site
> format definitely doesn't help.
>
> Finally, although we have a MoinMoin Wiki for Jetspeed-2 too (see:
> http://wiki.apache.org/portals/jetspeed2) which can be used by both
> the committers and other community members to provide more direct
> and interactive documentation, in reality hardly anyone uses it, is
> (in my view) ugly and difficult to use, and contains mostly stale/
> outdated information.
>
> And now, with our recent restructuring of our svn by moving the j2-
> admin and other portlet applications to a separate applications
> root folder so they now will have their own life cycle, even more
> complex challenges arise. Maintaining and *integrating* two or even
> more maven generated websites under one primary site is definitely
> not going to be easy (forget about maintaining documentation for
> multiple releases) ...
>
> As we now are working on a major overhaul of the Jetspeed-2 build
> system (dropping the old maven-1/2 structure and replacing it with
> a clean maven-2 project rewrite from scratch), maybe this now also
> is the right time to evaluate our current project documentation and
> website generation solution.
>
> And as probably already obvious from my above "rant" against our
> current solution, I'd like to propose something completely different.
>
> Since quite some time, several other Apache projects have moved to
> Confluence for their documentation tasks *and* their project
> website "generation".
> Some good and also very nice *and* different looking examples are:
> Cayenne - http://cayenne.apache.org
> Directory - http://directory.apache.org
> Felix - http://felix.apache.org
> Geronimo - http://geronimo.apache.org
> James - http://james.apache.org
> Wicket - http://wicket.apache.org
> and there are several more.
>
> Although Confluence is a real wiki, with an AutoExport plugin a
> static HTML site snapshot can automatically be created (after each
> change or update) and used as basis for a Apache project website.
> Additionally, Velocity scripts can be run during the export to
> provide additional formatting for a custom styled website.
>
> Although I could try to describe here all the procedures and
> possibilities of this solution and the benefits it brings, I think
> it better to read up on these yourself and also see how these other
> projects are using it.
>
> The primary documentation can be found here:
> http://cwiki.apache.org/CWIKI/
>
> The Geronimo and Wicket projects have some nice additional
> documentation how they make use of this:
> http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-
> architecture.html
> and
> http://wicket.apache.org/writing-documentation.html
>
> My proposal is simple:
> - switch to using this Confluence+cwiki solution
> - maintain separate Confluence spaces for release specific
> documentation for jetspeed-2, j2-admin and future products
> - also allow selected end users (non-committers but with a CLA on
> file, see main CWIKI documentation for explanation)
> to maintain these official documentation spaces
> - also switch to using Confluence for our public jetspeed-2 wiki
> (replacing MoinMoin) for additional non-official/endorsed project
> information
> - integrate all the above in one new main cwiki based jetspeed-2
> project website
>
> WDYT?
>
> Regards,
>
> Ate
>
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

Re: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by David Sean Taylor <da...@bluesunrise.com>.
All the x-posting confuses me.
Now that everyone is aware of the proposal, can we discuss this on
general?
I like the idea of using Confluence. In general I am +1.
Just a few questions, which I will ask on general...
On Mar 4, 2008, at 2:42 PM, Ate Douma wrote:
> Dear community,
>
> I'm cross-posting this proposal to the developers lists of our
> other sibling projects, Pluto and Bridges, as well as our PMC as I
> think it might be of interest to the whole Portals community.
>
> For now though, my proposal only targets the Jetspeed project web
> site, and I'd like to hear who might be interested in this .
>
> Until now, we've been defining our jetspeed website and
> documentation in (Maven-1) xdoc format, which makes it possible to
> maintain it in the svn repository, and more or less "seemingly"
> integrate project meta-data and end user documentation in one
> central location to be pushed out (after generation) as our primary
> project website and documentation.
>
> While this more or less works "ok", as we all know, maven site
> generation has it peculiar quirks, and quite strict (and limiting)
> rules to obey to get it working correctly.
>
> Furthermore, although the goal of maintaining the documentation
> definitions versioned in svn by itself doesn't seem like a bad
> idea, in practice this poses logical problems once a "release" tag
> has been set. Most commonly, the website documentation is in need
> of updating/correcting for an already released version, so changes
> usually are committed against the svn trunk which might already be
> (way) ahead in development.
>
> One solution would be to maintain separate "documentation update"
> branches in svn, but that's cumbersome too to say the least.
>
> On top of that, it is very difficult (and very impractical) to
> maintain online documentation for multiple release versions, while
> end users most likely will be using different/older version(s) than
> just the current (trunk) development version.
>
> And maintaining the maven site documentation in xdoc (or apt or
> even some more exotic) format is in practice, in my personal view,
> horrible to do.
> AFAIK, there still isn't any good GUI support for writing this but
> using plain ASCII or XML format, and using and maintaing correct
> anchors and image references without any proper (direct) feedback
> mechanism is quite error prone. For some this might be the perfect
> tool, but in my personal experience, these limitations have
> hindered us (as project committers) very much in writing and
> providing some good and proper documentation.
> Writing documentation usually already isn't the best quality of us
> coders (certainly not mine), but having to do so in maven site
> format definitely doesn't help.
>
> Finally, although we have a MoinMoin Wiki for Jetspeed-2 too (see:
> http://wiki.apache.org/portals/jetspeed2) which can be used by both
> the committers and other community members to provide more direct
> and interactive documentation, in reality hardly anyone uses it, is
> (in my view) ugly and difficult to use, and contains mostly stale/
> outdated information.
>
> And now, with our recent restructuring of our svn by moving the j2-
> admin and other portlet applications to a separate applications
> root folder so they now will have their own life cycle, even more
> complex challenges arise. Maintaining and *integrating* two or even
> more maven generated websites under one primary site is definitely
> not going to be easy (forget about maintaining documentation for
> multiple releases) ...
>
> As we now are working on a major overhaul of the Jetspeed-2 build
> system (dropping the old maven-1/2 structure and replacing it with
> a clean maven-2 project rewrite from scratch), maybe this now also
> is the right time to evaluate our current project documentation and
> website generation solution.
>
> And as probably already obvious from my above "rant" against our
> current solution, I'd like to propose something completely different.
>
> Since quite some time, several other Apache projects have moved to
> Confluence for their documentation tasks *and* their project
> website "generation".
> Some good and also very nice *and* different looking examples are:
> Cayenne - http://cayenne.apache.org
> Directory - http://directory.apache.org
> Felix - http://felix.apache.org
> Geronimo - http://geronimo.apache.org
> James - http://james.apache.org
> Wicket - http://wicket.apache.org
> and there are several more.
>
> Although Confluence is a real wiki, with an AutoExport plugin a
> static HTML site snapshot can automatically be created (after each
> change or update) and used as basis for a Apache project website.
> Additionally, Velocity scripts can be run during the export to
> provide additional formatting for a custom styled website.
>
> Although I could try to describe here all the procedures and
> possibilities of this solution and the benefits it brings, I think
> it better to read up on these yourself and also see how these other
> projects are using it.
>
> The primary documentation can be found here:
> http://cwiki.apache.org/CWIKI/
>
> The Geronimo and Wicket projects have some nice additional
> documentation how they make use of this:
> http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-
> architecture.html
> and
> http://wicket.apache.org/writing-documentation.html
>
> My proposal is simple:
> - switch to using this Confluence+cwiki solution
> - maintain separate Confluence spaces for release specific
> documentation for jetspeed-2, j2-admin and future products
> - also allow selected end users (non-committers but with a CLA on
> file, see main CWIKI documentation for explanation)
> to maintain these official documentation spaces
> - also switch to using Confluence for our public jetspeed-2 wiki
> (replacing MoinMoin) for additional non-official/endorsed project
> information
> - integrate all the above in one new main cwiki based jetspeed-2
> project website
>
> WDYT?
>
> Regards,
>
> Ate
>
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

Re: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by David Sean Taylor <da...@bluesunrise.com>.
All the x-posting confuses me.
Now that everyone is aware of the proposal, can we discuss this on
general?
I like the idea of using Confluence. In general I am +1.
Just a few questions, which I will ask on general...
On Mar 4, 2008, at 2:42 PM, Ate Douma wrote:
> Dear community,
>
> I'm cross-posting this proposal to the developers lists of our
> other sibling projects, Pluto and Bridges, as well as our PMC as I
> think it might be of interest to the whole Portals community.
>
> For now though, my proposal only targets the Jetspeed project web
> site, and I'd like to hear who might be interested in this .
>
> Until now, we've been defining our jetspeed website and
> documentation in (Maven-1) xdoc format, which makes it possible to
> maintain it in the svn repository, and more or less "seemingly"
> integrate project meta-data and end user documentation in one
> central location to be pushed out (after generation) as our primary
> project website and documentation.
>
> While this more or less works "ok", as we all know, maven site
> generation has it peculiar quirks, and quite strict (and limiting)
> rules to obey to get it working correctly.
>
> Furthermore, although the goal of maintaining the documentation
> definitions versioned in svn by itself doesn't seem like a bad
> idea, in practice this poses logical problems once a "release" tag
> has been set. Most commonly, the website documentation is in need
> of updating/correcting for an already released version, so changes
> usually are committed against the svn trunk which might already be
> (way) ahead in development.
>
> One solution would be to maintain separate "documentation update"
> branches in svn, but that's cumbersome too to say the least.
>
> On top of that, it is very difficult (and very impractical) to
> maintain online documentation for multiple release versions, while
> end users most likely will be using different/older version(s) than
> just the current (trunk) development version.
>
> And maintaining the maven site documentation in xdoc (or apt or
> even some more exotic) format is in practice, in my personal view,
> horrible to do.
> AFAIK, there still isn't any good GUI support for writing this but
> using plain ASCII or XML format, and using and maintaing correct
> anchors and image references without any proper (direct) feedback
> mechanism is quite error prone. For some this might be the perfect
> tool, but in my personal experience, these limitations have
> hindered us (as project committers) very much in writing and
> providing some good and proper documentation.
> Writing documentation usually already isn't the best quality of us
> coders (certainly not mine), but having to do so in maven site
> format definitely doesn't help.
>
> Finally, although we have a MoinMoin Wiki for Jetspeed-2 too (see:
> http://wiki.apache.org/portals/jetspeed2) which can be used by both
> the committers and other community members to provide more direct
> and interactive documentation, in reality hardly anyone uses it, is
> (in my view) ugly and difficult to use, and contains mostly stale/
> outdated information.
>
> And now, with our recent restructuring of our svn by moving the j2-
> admin and other portlet applications to a separate applications
> root folder so they now will have their own life cycle, even more
> complex challenges arise. Maintaining and *integrating* two or even
> more maven generated websites under one primary site is definitely
> not going to be easy (forget about maintaining documentation for
> multiple releases) ...
>
> As we now are working on a major overhaul of the Jetspeed-2 build
> system (dropping the old maven-1/2 structure and replacing it with
> a clean maven-2 project rewrite from scratch), maybe this now also
> is the right time to evaluate our current project documentation and
> website generation solution.
>
> And as probably already obvious from my above "rant" against our
> current solution, I'd like to propose something completely different.
>
> Since quite some time, several other Apache projects have moved to
> Confluence for their documentation tasks *and* their project
> website "generation".
> Some good and also very nice *and* different looking examples are:
> Cayenne - http://cayenne.apache.org
> Directory - http://directory.apache.org
> Felix - http://felix.apache.org
> Geronimo - http://geronimo.apache.org
> James - http://james.apache.org
> Wicket - http://wicket.apache.org
> and there are several more.
>
> Although Confluence is a real wiki, with an AutoExport plugin a
> static HTML site snapshot can automatically be created (after each
> change or update) and used as basis for a Apache project website.
> Additionally, Velocity scripts can be run during the export to
> provide additional formatting for a custom styled website.
>
> Although I could try to describe here all the procedures and
> possibilities of this solution and the benefits it brings, I think
> it better to read up on these yourself and also see how these other
> projects are using it.
>
> The primary documentation can be found here:
> http://cwiki.apache.org/CWIKI/
>
> The Geronimo and Wicket projects have some nice additional
> documentation how they make use of this:
> http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-
> architecture.html
> and
> http://wicket.apache.org/writing-documentation.html
>
> My proposal is simple:
> - switch to using this Confluence+cwiki solution
> - maintain separate Confluence spaces for release specific
> documentation for jetspeed-2, j2-admin and future products
> - also allow selected end users (non-committers but with a CLA on
> file, see main CWIKI documentation for explanation)
> to maintain these official documentation spaces
> - also switch to using Confluence for our public jetspeed-2 wiki
> (replacing MoinMoin) for additional non-official/endorsed project
> information
> - integrate all the above in one new main cwiki based jetspeed-2
> project website
>
> WDYT?
>
> Regards,
>
> Ate
>
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Dennis Dam <d....@hippo.nl>.
Great idea! It will make it easier and more motivating to write
documentation , because you see result almost in an instant. On top of
that there are lots of other advantages, like more flexible styling
possibilities, export/import to other spaces, etc.
Big +1 !
Dennis
David Jencks wrote:
> +1 to the "expanded" proposal. Even I can manage to write
> documentation in confluence :-)
>
> I'm by no means a confluence expert but I believe it is much easier to
> create a new space as a copy of an existing one than it is to copy
> content from one space to another. So, when creating a space for a
> new release I strongly advise copying the space for the previous
> version and then modifying it for the new release.
>
> thanks
> david jencks
> On Mar 5, 2008, at 6:49 AM, Ate Douma wrote:
>
>> Carsten Ziegeler wrote:
>>> Big +1 for using Confluence; we are using it for several projects
>>> (Felix, Sling, Jackrabbit) already and it works nicely.
>>>>> If they have a CLA on file, and are contributing to the official
>>>>> project
>>>>> documentation, they *ARE* Committers. They just aren't coders,
>>>>> and don't
>>>>> have SVN access.
>>>> Well, that's not how I understand how it is described on the CWIKI
>>>> page, or even here:
>>>> http://www.apache.org/foundation/how-it-works.html.
>>>> Although a committer must have a CLA on file, can't a "contributer"
>>>> have a CLA on file too without being a committer?
>>> Yes, that's how we do it in other projects. You need a CLA and then
>>> can contribute to the docs without being a "svn committer".
>> Cool, that's what I thought too.
>>
>>> Ate Douma wrote:
>>> > My proposal is simple:
>>> > - switch to using this Confluence+cwiki solution
>>> I assume you mean for the whole portals project. +1
>> Well, I indicated upfront to propose this (initially) for Jetspeed-2
>> only.
>> But of course, I'd like to see this to be extended to the whole of
>> Portals project too.
>> See also my comments below.
>>
>>> > - maintain separate Confluence spaces for release specific
>>> documentation
>>> > for jetspeed-2, j2-admin and future products
>>> Hmm, not sure if we need this. So this would also include to have a
>>> specific space for Pluto, Bridges etc?
>> Yes, and even potentially, depending on the goals for each project,
>> distinct spaces per each (major) release.
>> See for example how Geronimo handles this:
>> Main website space - http://cwiki.apache.org/GMOxSITE/
>> Trunk development space - http://cwiki.apache.org/GMOxDEV/
>> Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/
>> Geronimo v.1.2 space - http://cwiki.apache.org/GMOxDOC12/
>> Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/
>> etc.
>>
>> Now, if we are going to extend my proposal for the whole of Portals
>> project (or at least including the main site), we might optimize this
>> a bit.
>> In my view, there is/should only be a need for one primary (release
>> independent) website space.
>> This space (PORTALS) can then contain all general information for
>> both the Portals project (like http://portals.apache.org) as well as
>> for the subprojects (Jetspeed, Pluto, Bridges, etc.).
>> Then, each sub project can need additional release related spaces,
>> like J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
>>
>> Finally, we can simply switch to one Confluence space for the
>> "public" wiki for the whole Portals project too, something like
>> PORTALSxWIKI.
>>
>>> > - integrate all the above in one new main cwiki based jetspeed-2
>>> project
>>> > website
>>> Can you elaborate a little bit on this one please?
>> The global PORTALS space should integrate all of the above spaces
>> similar to how other projects do this, as well as additional
>> resources like generated javadocs, reports etc. for which we still
>> can use maven but need to provide links to from the Confluence space(s).
>>
>> So, if you would want to expand this proposal to include Portals
>> itself, Pluto, Bridges, maybe even WSRP4J etc., +1
>>
>> Ate
>>
>>> Carsten
>>
>
Re: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by David Jencks <da...@yahoo.com>.
+1 to the "expanded" proposal. Even I can manage to write
documentation in confluence :-)
I'm by no means a confluence expert but I believe it is much easier
to create a new space as a copy of an existing one than it is to copy
content from one space to another. So, when creating a space for a
new release I strongly advise copying the space for the previous
version and then modifying it for the new release.
thanks
david jencks
On Mar 5, 2008, at 6:49 AM, Ate Douma wrote:
> Carsten Ziegeler wrote:
>> Big +1 for using Confluence; we are using it for several projects
>> (Felix, Sling, Jackrabbit) already and it works nicely.
>>>> If they have a CLA on file, and are contributing to the official
>>>> project
>>>> documentation, they *ARE* Committers. They just aren't coders,
>>>> and don't
>>>> have SVN access.
>>> Well, that's not how I understand how it is described on the
>>> CWIKI page, or even here: http://www.apache.org/foundation/how-it-
>>> works.html.
>>> Although a committer must have a CLA on file, can't a
>>> "contributer" have a CLA on file too without being a committer?
>> Yes, that's how we do it in other projects. You need a CLA and
>> then can contribute to the docs without being a "svn committer".
> Cool, that's what I thought too.
>
>> Ate Douma wrote:
>> > My proposal is simple:
>> > - switch to using this Confluence+cwiki solution
>> I assume you mean for the whole portals project. +1
> Well, I indicated upfront to propose this (initially) for
> Jetspeed-2 only.
> But of course, I'd like to see this to be extended to the whole of
> Portals project too.
> See also my comments below.
>
>> > - maintain separate Confluence spaces for release specific
>> documentation
>> > for jetspeed-2, j2-admin and future products
>> Hmm, not sure if we need this. So this would also include to have
>> a specific space for Pluto, Bridges etc?
> Yes, and even potentially, depending on the goals for each project,
> distinct spaces per each (major) release.
> See for example how Geronimo handles this:
> Main website space - http://cwiki.apache.org/GMOxSITE/
> Trunk development space - http://cwiki.apache.org/GMOxDEV/
> Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/
> Geronimo v.1.2 space - http://cwiki.apache.org/GMOxDOC12/
> Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/
> etc.
>
> Now, if we are going to extend my proposal for the whole of Portals
> project (or at least including the main site), we might optimize
> this a bit.
> In my view, there is/should only be a need for one primary (release
> independent) website space.
> This space (PORTALS) can then contain all general information for
> both the Portals project (like http://portals.apache.org) as well
> as for the subprojects (Jetspeed, Pluto, Bridges, etc.).
> Then, each sub project can need additional release related spaces,
> like J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
>
> Finally, we can simply switch to one Confluence space for the
> "public" wiki for the whole Portals project too, something like
> PORTALSxWIKI.
>
>> > - integrate all the above in one new main cwiki based
>> jetspeed-2 project
>> > website
>> Can you elaborate a little bit on this one please?
> The global PORTALS space should integrate all of the above spaces
> similar to how other projects do this, as well as additional
> resources like generated javadocs, reports etc. for which we still
> can use maven but need to provide links to from the Confluence space
> (s).
>
> So, if you would want to expand this proposal to include Portals
> itself, Pluto, Bridges, maybe even WSRP4J etc., +1
>
> Ate
>
>> Carsten
>
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma wrote:
>
>>
>> I think it's easier to go with the problems of a maintained software
>> than trying to use something which is currently not installed. But I'm
>> following majority here.
> Without some kind of infra support for a newer/newest MoinMoin, I agree
> this isn't going to work out.
> I'm just stating my preference for if and why I think it is a better
> alternative, but only *if* it can be supported.
> Confluence is "nice", but also a pain in some quite important area's.
>
Yes, I agree - so how to we proceed. So far, it's just the two of us
discussing
this. I'm really interested in other opinions.
As a start we could try to get some response from infra about a newer
MoinMoin version and what they think about it. We could also try to
convince the confluence people to fix the problems although I doubt that
this will be solved in a short time frame.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> Hmm, I agree that this is a problem. In Felix we solve this (partially)
> by prefixing the page names with the sub projects. It works but calls
> for trouble over time.
>
> I can only say that I really hate (perhaps hate is a little bit too
> strong) the current MoinMoin installation we have.
Belief me, I'm not a fan of the current installation either.
> If newer versions are
> better, I would be fine with that; but I doubt that this will be easy to
> be maintained by infra. On the other hand Confluence has a very strong
> support.
True, but the current MoinMoin is maintained/support too and I don't see that going away any time soon.
The question is: when, how and by whom can our current version be upgraded?
And if that won't be possible any time soon, can we have a second/independent installation (just for
portals.apache.org)?
>
> Now, we have two problems if I understand this correctly:
> a) Possible page name clashes in the general content
> This could be solved by prefixing; as this content is more of a static
> nature, we should come around this.
Yes, that can be done. But Felix and most other projects don't have full blown sub projects to consider, each with
usually many similar topics to describe. With Portals, this is quite different.
We need to specify strict naming rules to keep us from ending up in a big mess.
>
> b) Nesting of spaces
> I'm not quiet sure, but I think this can be easily done. If we export
> the general space to portals.a.o, the j2 space to portals.a.o/j2 etc.
> everything should work out of the box. Or do I oversee something here?
No, I agree that's the general idea.
But what I'm afraid of is that we are going to see an explosion of confluence spaces:
1) site: general + pluto + bridges + apa (+apps) + j2 + j2admin + wsrp4j (all in one space)
2) pluto v1.1.5 doc
3) pluto v2.0 doc
4) bridges v1.0.4 doc
5) j2 v2.1.3 doc
6) j2 v2.2 doc
7) j2-admin v2.2 doc
8) wsrp4j v1.0 doc
10) apa-<app1> v1.0 doc
11) apa-<app2> v1.0 doc
13) apa-<app3> v1.0 doc
Of course, the above set is just the beginning, with newer (major) releases and/or new apa apps added, this set might
expand rapidly.
The nice thing of MoinMoin is that one doesn't have to concern itself with all these "Spaces", unique page names etc,
nor merging separate "spaces" in one url space: everything can be managed inline/online and in realtime with MoinMoin.
>
> I think it's easier to go with the problems of a maintained software
> than trying to use something which is currently not installed. But I'm
> following majority here.
Without some kind of infra support for a newer/newest MoinMoin, I agree this isn't going to work out.
I'm just stating my preference for if and why I think it is a better alternative, but only *if* it can be supported.
Confluence is "nice", but also a pain in some quite important area's.
>
> Carsten
> Ate Douma wrote:
>> After doing some further research and actually playing around with a
>> standalone installation of Confluence and the AutoExport plugin, I'm
>> not really positive about this proposal anymore :(
>>
>> Especially with regards to managing and integrating the confluence
>> content for multiple Portals sub projects, I've noticed some very
>> serious confluence limitations.
>> These limitations are quite known and much sought after to be solved,
>> see:
>>
>> http://jira.atlassian.com/browse/CONF-2524
>> http://jira.atlassian.com/browse/CONF-1095
>>
>> The main limitation (in my view) is that confluence page titles need
>> to be unique within one Space. Considering commonly expected page
>> titles like Index, Documentation, Reports, etc. which each project
>> would want or need to create, this is going to be a big problem trying
>> to handle all that in one confluence Space (which was the idea for the
>> standard/non-release related content). The only "solution" to that
>> problem would be using some kind of ugly pre/postfixing page titles,
>> like J2Index, PlutoIndex etc., ugh...
>>
>> Currently the only real solution is to use separate confluence spaces
>> for even the general content of each independent (sub) project, and
>> not only just for their (major) release documentations.
>> Now, considering we are also going to start with the new APA project,
>> which (by intent) will be composed of multiple, independent, sub
>> projects again, we're looking at quite a lot of confluence spaces for
>> the Portals project only (easily growing to 10-20 or more).
>>
>> I don't think that, from a managerial POV, this is going to be
>> acceptable, neither for infra or ourselves.
>>
>> Last but certainly not least, confluence (in contrast to many other
>> wiki's, including MoinMoin) doesn't grog sub pages, folders or nested
>> Spaces.
>>
>> As the cwiki solution requires generating exported static html from
>> Confluence for each Space to be merged into one coherent single
>> Portals website / url space, this is going to be extremely difficult
>> to do.
>> In fact, I've got a feeling this might turn out to be even more
>> difficult/buggy than trying to achieve this with a maven 2 site setup.
>>
>> The biggest problem in my view with these issues is the fact that
>> Confluence is a closed source solution with makes it impossible for us
>> to assess the scope of these problems, the options available to
>> workaround them, or even provide patches/fixes.
>>
>> The handling of the above mentioned JIRA issues by Atlassian also
>> doesn't make me optimistic these are going to be solved any time soon.
>>
>> Why didn't I notice these problems before and don't other projects
>> seem to have these issues?
>> Probably because AFAIK none of the other projects have as much
>> (independent) sub projects as we (are going to) have, so they only
>> have to manage a handful of Spaces the most (Geronimo being
>> exceptional with already 15+ spaces).
>>
>> Unless anyone has some knowledge or ideas how these issues can be
>> circumvented or tell me I have completely misunderstood all this, I'm
>> going to change my opinion to -1 for this solution.
>>
>> But...
>>
>> This doesn't mean there isn't or might not be an alternative.
>>
>> I decided to now properly check out the capabilities and features of
>> MoinMoin as only other Wiki based solution available to us. And to my
>> surprise, it seems to be capable of *much* more than what currently is
>> used or provided by the installation on wiki.apache.org.
>>
>> This is mostly caused by Apache still using a hacked/forked version
>> 1.3.4 (released 3 years ago: where was Confluence at that time,
>> feature wise?).
>> The latest MoinMoin 1.6 definitely supports many (if not all or more)
>> of the features I think why we were looking at Confluence for:
>> - Easy editing, WYSIWYG, multiple (wiki) languages, custom client side
>> editing support (e.g. editmoin)
>> - easy to use python macros and extendability, theming
>> - many (free/open-source) plugins/macros/actions available
>> - modular/pluggable authentication
>> - very flexible ACL configuration (users/groups, definition support)
>> - sub pages! (like: http://moinmo.in/HelpOnEditing/SubPages)
>> - sub pages can also inherit parent page ACL settings (something
>> Confluence cannot either)
>> - custom themes, page templates
>> - etc.
>>
>> Some relevant links worthwhile checking out:
>> http://moinmo.in/
>> http://moinmo.in/MoinMoinScreenShots
>> http://moinmo.in/MoinMoinFeatures
>> http://moinmo.in/HelpOnEditing/SubPages
>> http://moinmo.in/HelpOnAccessControlLists
>> http://moinmo.in/HelpOnAuthentication
>>
>> I know, just a week ago I proposed the cwiki/confluence solution,
>> which at least is (somewhat) supported by infrastructure, and the
>> latest version of MoinMoin certainly (not) yet.
>>
>> But in my current view, MoinMoin potentially can provide us with a
>> really good solution.
>> Its open source, fast, and would even allow *inline* editing (with
>> proper authentication and ACL that is) of the website. No funky
>> jumping-through-hoops kind of intermediate exporting, merging and
>> additional url-rewriting needed!
>>
>> Looking at the current state and maintenance of MoinMoin at Apache
>> though, I'm doubtful if anyone at infrastructure is willing to move to
>> the latest version *for* wiki.apache.org, which is one large wiki farm
>> across Apache.
>>
>> If there is enough interest for this though, maybe we can ask infra if
>> we can get portals.apache.org hosted on a separate (latest) instance
>> of MoinMoin. But as infrastructure already seems to be stressed quite
>> a lot, that might be problematic too.
>>
>> Anyway, I'd like to know if anyone else has experience with more
>> recent MoinMoin installations and opinions about properly using
>> MoinMoin (to the fullest) as alternative solution.
>>
>
>
>
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Carsten Ziegeler <cz...@apache.org>.
Hmm, I agree that this is a problem. In Felix we solve this (partially)
by prefixing the page names with the sub projects. It works but calls
for trouble over time.
I can only say that I really hate (perhaps hate is a little bit too
strong) the current MoinMoin installation we have. If newer versions are
better, I would be fine with that; but I doubt that this will be easy to
be maintained by infra. On the other hand Confluence has a very strong
support.
Now, we have two problems if I understand this correctly:
a) Possible page name clashes in the general content
This could be solved by prefixing; as this content is more of a static
nature, we should come around this.
b) Nesting of spaces
I'm not quiet sure, but I think this can be easily done. If we export
the general space to portals.a.o, the j2 space to portals.a.o/j2 etc.
everything should work out of the box. Or do I oversee something here?
I think it's easier to go with the problems of a maintained software
than trying to use something which is currently not installed. But I'm
following majority here.
Carsten
Ate Douma wrote:
> After doing some further research and actually playing around with a
> standalone installation of Confluence and the AutoExport plugin, I'm not
> really positive about this proposal anymore :(
>
> Especially with regards to managing and integrating the confluence
> content for multiple Portals sub projects, I've noticed some very
> serious confluence limitations.
> These limitations are quite known and much sought after to be solved, see:
>
> http://jira.atlassian.com/browse/CONF-2524
> http://jira.atlassian.com/browse/CONF-1095
>
> The main limitation (in my view) is that confluence page titles need to
> be unique within one Space. Considering commonly expected page titles
> like Index, Documentation, Reports, etc. which each project would want
> or need to create, this is going to be a big problem trying to handle
> all that in one confluence Space (which was the idea for the
> standard/non-release related content). The only "solution" to that
> problem would be using some kind of ugly pre/postfixing page titles,
> like J2Index, PlutoIndex etc., ugh...
>
> Currently the only real solution is to use separate confluence spaces
> for even the general content of each independent (sub) project, and not
> only just for their (major) release documentations.
> Now, considering we are also going to start with the new APA project,
> which (by intent) will be composed of multiple, independent, sub
> projects again, we're looking at quite a lot of confluence spaces for
> the Portals project only (easily growing to 10-20 or more).
>
> I don't think that, from a managerial POV, this is going to be
> acceptable, neither for infra or ourselves.
>
> Last but certainly not least, confluence (in contrast to many other
> wiki's, including MoinMoin) doesn't grog sub pages, folders or nested
> Spaces.
>
> As the cwiki solution requires generating exported static html from
> Confluence for each Space to be merged into one coherent single Portals
> website / url space, this is going to be extremely difficult to do.
> In fact, I've got a feeling this might turn out to be even more
> difficult/buggy than trying to achieve this with a maven 2 site setup.
>
> The biggest problem in my view with these issues is the fact that
> Confluence is a closed source solution with makes it impossible for us
> to assess the scope of these problems, the options available to
> workaround them, or even provide patches/fixes.
>
> The handling of the above mentioned JIRA issues by Atlassian also
> doesn't make me optimistic these are going to be solved any time soon.
>
> Why didn't I notice these problems before and don't other projects seem
> to have these issues?
> Probably because AFAIK none of the other projects have as much
> (independent) sub projects as we (are going to) have, so they only have
> to manage a handful of Spaces the most (Geronimo being exceptional with
> already 15+ spaces).
>
> Unless anyone has some knowledge or ideas how these issues can be
> circumvented or tell me I have completely misunderstood all this, I'm
> going to change my opinion to -1 for this solution.
>
> But...
>
> This doesn't mean there isn't or might not be an alternative.
>
> I decided to now properly check out the capabilities and features of
> MoinMoin as only other Wiki based solution available to us. And to my
> surprise, it seems to be capable of *much* more than what currently is
> used or provided by the installation on wiki.apache.org.
>
> This is mostly caused by Apache still using a hacked/forked version
> 1.3.4 (released 3 years ago: where was Confluence at that time, feature
> wise?).
> The latest MoinMoin 1.6 definitely supports many (if not all or more) of
> the features I think why we were looking at Confluence for:
> - Easy editing, WYSIWYG, multiple (wiki) languages, custom client side
> editing support (e.g. editmoin)
> - easy to use python macros and extendability, theming
> - many (free/open-source) plugins/macros/actions available
> - modular/pluggable authentication
> - very flexible ACL configuration (users/groups, definition support)
> - sub pages! (like: http://moinmo.in/HelpOnEditing/SubPages)
> - sub pages can also inherit parent page ACL settings (something
> Confluence cannot either)
> - custom themes, page templates
> - etc.
>
> Some relevant links worthwhile checking out:
> http://moinmo.in/
> http://moinmo.in/MoinMoinScreenShots
> http://moinmo.in/MoinMoinFeatures
> http://moinmo.in/HelpOnEditing/SubPages
> http://moinmo.in/HelpOnAccessControlLists
> http://moinmo.in/HelpOnAuthentication
>
> I know, just a week ago I proposed the cwiki/confluence solution, which
> at least is (somewhat) supported by infrastructure, and the latest
> version of MoinMoin certainly (not) yet.
>
> But in my current view, MoinMoin potentially can provide us with a
> really good solution.
> Its open source, fast, and would even allow *inline* editing (with
> proper authentication and ACL that is) of the website. No funky
> jumping-through-hoops kind of intermediate exporting, merging and
> additional url-rewriting needed!
>
> Looking at the current state and maintenance of MoinMoin at Apache
> though, I'm doubtful if anyone at infrastructure is willing to move to
> the latest version *for* wiki.apache.org, which is one large wiki farm
> across Apache.
>
> If there is enough interest for this though, maybe we can ask infra if
> we can get portals.apache.org hosted on a separate (latest) instance of
> MoinMoin. But as infrastructure already seems to be stressed quite a
> lot, that might be problematic too.
>
> Anyway, I'd like to know if anyone else has experience with more recent
> MoinMoin installations and opinions about properly using MoinMoin (to
> the fullest) as alternative solution.
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
After doing some further research and actually playing around with a standalone installation of Confluence and the
AutoExport plugin, I'm not really positive about this proposal anymore :(
Especially with regards to managing and integrating the confluence content for multiple Portals sub projects, I've
noticed some very serious confluence limitations.
These limitations are quite known and much sought after to be solved, see:
http://jira.atlassian.com/browse/CONF-2524
http://jira.atlassian.com/browse/CONF-1095
The main limitation (in my view) is that confluence page titles need to be unique within one Space. Considering commonly
expected page titles like Index, Documentation, Reports, etc. which each project would want or need to create, this is
going to be a big problem trying to handle all that in one confluence Space (which was the idea for the
standard/non-release related content). The only "solution" to that problem would be using some kind of ugly
pre/postfixing page titles, like J2Index, PlutoIndex etc., ugh...
Currently the only real solution is to use separate confluence spaces for even the general content of each independent
(sub) project, and not only just for their (major) release documentations.
Now, considering we are also going to start with the new APA project, which (by intent) will be composed of multiple,
independent, sub projects again, we're looking at quite a lot of confluence spaces for the Portals project only (easily
growing to 10-20 or more).
I don't think that, from a managerial POV, this is going to be acceptable, neither for infra or ourselves.
Last but certainly not least, confluence (in contrast to many other wiki's, including MoinMoin) doesn't grog sub pages,
folders or nested Spaces.
As the cwiki solution requires generating exported static html from Confluence for each Space to be merged into one
coherent single Portals website / url space, this is going to be extremely difficult to do.
In fact, I've got a feeling this might turn out to be even more difficult/buggy than trying to achieve this with a maven
2 site setup.
The biggest problem in my view with these issues is the fact that Confluence is a closed source solution with makes it
impossible for us to assess the scope of these problems, the options available to workaround them, or even provide
patches/fixes.
The handling of the above mentioned JIRA issues by Atlassian also doesn't make me optimistic these are going to be
solved any time soon.
Why didn't I notice these problems before and don't other projects seem to have these issues?
Probably because AFAIK none of the other projects have as much (independent) sub projects as we (are going to) have, so
they only have to manage a handful of Spaces the most (Geronimo being exceptional with already 15+ spaces).
Unless anyone has some knowledge or ideas how these issues can be circumvented or tell me I have completely
misunderstood all this, I'm going to change my opinion to -1 for this solution.
But...
This doesn't mean there isn't or might not be an alternative.
I decided to now properly check out the capabilities and features of MoinMoin as only other Wiki based solution
available to us. And to my surprise, it seems to be capable of *much* more than what currently is used or provided by
the installation on wiki.apache.org.
This is mostly caused by Apache still using a hacked/forked version 1.3.4 (released 3 years ago: where was Confluence at
that time, feature wise?).
The latest MoinMoin 1.6 definitely supports many (if not all or more) of the features I think why we were looking at
Confluence for:
- Easy editing, WYSIWYG, multiple (wiki) languages, custom client side editing support (e.g. editmoin)
- easy to use python macros and extendability, theming
- many (free/open-source) plugins/macros/actions available
- modular/pluggable authentication
- very flexible ACL configuration (users/groups, definition support)
- sub pages! (like: http://moinmo.in/HelpOnEditing/SubPages)
- sub pages can also inherit parent page ACL settings (something Confluence cannot either)
- custom themes, page templates
- etc.
Some relevant links worthwhile checking out:
http://moinmo.in/
http://moinmo.in/MoinMoinScreenShots
http://moinmo.in/MoinMoinFeatures
http://moinmo.in/HelpOnEditing/SubPages
http://moinmo.in/HelpOnAccessControlLists
http://moinmo.in/HelpOnAuthentication
I know, just a week ago I proposed the cwiki/confluence solution, which at least is (somewhat) supported by
infrastructure, and the latest version of MoinMoin certainly (not) yet.
But in my current view, MoinMoin potentially can provide us with a really good solution.
Its open source, fast, and would even allow *inline* editing (with proper authentication and ACL that is) of the
website. No funky jumping-through-hoops kind of intermediate exporting, merging and additional url-rewriting needed!
Looking at the current state and maintenance of MoinMoin at Apache though, I'm doubtful if anyone at infrastructure is
willing to move to the latest version *for* wiki.apache.org, which is one large wiki farm across Apache.
If there is enough interest for this though, maybe we can ask infra if we can get portals.apache.org hosted on a
separate (latest) instance of MoinMoin. But as infrastructure already seems to be stressed quite a lot, that might be
problematic too.
Anyway, I'd like to know if anyone else has experience with more recent MoinMoin installations and opinions about
properly using MoinMoin (to the fullest) as alternative solution.
Ate Douma wrote:
> Carsten Ziegeler wrote:
>> Big +1 for using Confluence; we are using it for several projects (Felix, Sling, Jackrabbit) already and it works
>> nicely.
>>
>>>> If they have a CLA on file, and are contributing to the official project documentation, they *ARE* Committers.
>>>> They just aren't coders, and don't have SVN access.
>>> Well, that's not how I understand how it is described on the CWIKI page, or even here:
>>> http://www.apache.org/foundation/how-it-works.html. Although a committer must have a CLA on file, can't a
>>> "contributer" have a CLA on file too without being a committer?
>> Yes, that's how we do it in other projects. You need a CLA and then can contribute to the docs without being a "svn
>> committer".
> Cool, that's what I thought too.
>
>>
>> Ate Douma wrote:
>>> My proposal is simple: - switch to using this Confluence+cwiki solution
>> I assume you mean for the whole portals project. +1
> Well, I indicated upfront to propose this (initially) for Jetspeed-2 only. But of course, I'd like to see this to be
> extended to the whole of Portals project too. See also my comments below.
>
>>
>>> - maintain separate Confluence spaces for release specific
>> documentation
>>> for jetspeed-2, j2-admin and future products
>> Hmm, not sure if we need this. So this would also include to have a specific space for Pluto, Bridges etc?
> Yes, and even potentially, depending on the goals for each project, distinct spaces per each (major) release. See for
> example how Geronimo handles this: Main website space - http://cwiki.apache.org/GMOxSITE/ Trunk development
> space - http://cwiki.apache.org/GMOxDEV/ Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/ Geronimo v.1.2
> space - http://cwiki.apache.org/GMOxDOC12/ Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/ etc.
>
> Now, if we are going to extend my proposal for the whole of Portals project (or at least including the main site), we
> might optimize this a bit. In my view, there is/should only be a need for one primary (release independent) website
> space. This space (PORTALS) can then contain all general information for both the Portals project (like
> http://portals.apache.org) as well as for the subprojects (Jetspeed, Pluto, Bridges, etc.). Then, each sub project
> can need additional release related spaces, like J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
>
> Finally, we can simply switch to one Confluence space for the "public" wiki for the whole Portals project too,
> something like PORTALSxWIKI.
>
>>
>>> - integrate all the above in one new main cwiki based jetspeed-2
>> project
>>> website
>> Can you elaborate a little bit on this one please?
> The global PORTALS space should integrate all of the above spaces similar to how other projects do this, as well as
> additional resources like generated javadocs, reports etc. for which we still can use maven but need to provide links
> to from the Confluence space(s).
>
> So, if you would want to expand this proposal to include Portals itself, Pluto, Bridges, maybe even WSRP4J etc., +1
>
> Ate
>
>>
>> Carsten
>
>
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks Ate for the additional information.
Yes, I really would like to include all sub projects. Let's use just one
technology and one way of dealing with documentation for the whole
portals project.
I never thought of having different spaces per released version (or
branch or whatever you call it), but it seems to make sense.
So +1 for the proposal (just rephrasing what you wrote):
- Space PORTALS all general information for both the Portals project
(like http://portals.apache.org) as well as for the subprojects
(Jetspeed, Pluto, Bridges, etc.).
- Additional release related spaces like J2xDOC213, J2xDOC22, PLUTOx115,
PLUTOx20, BRIDGESx104 (PORTALS links to these spaces)
- PORTALSxWIKI for the "public" wiki for the whole portals project
Carsten
Ate Douma wrote:
> Carsten Ziegeler wrote:
>> Big +1 for using Confluence; we are using it for several projects
>> (Felix, Sling, Jackrabbit) already and it works nicely.
>>
>>>> If they have a CLA on file, and are contributing to the official
>>>> project
>>>> documentation, they *ARE* Committers. They just aren't coders, and
>>>> don't
>>>> have SVN access.
>>> Well, that's not how I understand how it is described on the CWIKI
>>> page, or even here: http://www.apache.org/foundation/how-it-works.html.
>>> Although a committer must have a CLA on file, can't a "contributer"
>>> have a CLA on file too without being a committer?
>> Yes, that's how we do it in other projects. You need a CLA and then
>> can contribute to the docs without being a "svn committer".
> Cool, that's what I thought too.
>
>>
>> Ate Douma wrote:
>> > My proposal is simple:
>> > - switch to using this Confluence+cwiki solution
>> I assume you mean for the whole portals project. +1
> Well, I indicated upfront to propose this (initially) for Jetspeed-2 only.
> But of course, I'd like to see this to be extended to the whole of
> Portals project too.
> See also my comments below.
>
>>
>> > - maintain separate Confluence spaces for release specific
>> documentation
>> > for jetspeed-2, j2-admin and future products
>> Hmm, not sure if we need this. So this would also include to have a
>> specific space for Pluto, Bridges etc?
> Yes, and even potentially, depending on the goals for each project,
> distinct spaces per each (major) release.
> See for example how Geronimo handles this:
> Main website space - http://cwiki.apache.org/GMOxSITE/
> Trunk development space - http://cwiki.apache.org/GMOxDEV/
> Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/
> Geronimo v.1.2 space - http://cwiki.apache.org/GMOxDOC12/
> Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/
> etc.
>
> Now, if we are going to extend my proposal for the whole of Portals
> project (or at least including the main site), we might optimize this a
> bit.
> In my view, there is/should only be a need for one primary (release
> independent) website space.
> This space (PORTALS) can then contain all general information for both
> the Portals project (like http://portals.apache.org) as well as for the
> subprojects (Jetspeed, Pluto, Bridges, etc.).
> Then, each sub project can need additional release related spaces, like
> J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
>
> Finally, we can simply switch to one Confluence space for the "public"
> wiki for the whole Portals project too, something like PORTALSxWIKI.
>
>>
>> > - integrate all the above in one new main cwiki based jetspeed-2
>> project
>> > website
>> Can you elaborate a little bit on this one please?
> The global PORTALS space should integrate all of the above spaces
> similar to how other projects do this, as well as additional resources
> like generated javadocs, reports etc. for which we still can use maven
> but need to provide links to from the Confluence space(s).
>
> So, if you would want to expand this proposal to include Portals itself,
> Pluto, Bridges, maybe even WSRP4J etc., +1
>
> Ate
>
>>
>> Carsten
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> Big +1 for using Confluence; we are using it for several projects
> (Felix, Sling, Jackrabbit) already and it works nicely.
>
>>> If they have a CLA on file, and are contributing to the official project
>>> documentation, they *ARE* Committers. They just aren't coders, and
>>> don't
>>> have SVN access.
>> Well, that's not how I understand how it is described on the CWIKI
>> page, or even here: http://www.apache.org/foundation/how-it-works.html.
>> Although a committer must have a CLA on file, can't a "contributer"
>> have a CLA on file too without being a committer?
> Yes, that's how we do it in other projects. You need a CLA and then can
> contribute to the docs without being a "svn committer".
Cool, that's what I thought too.
>
> Ate Douma wrote:
> > My proposal is simple:
> > - switch to using this Confluence+cwiki solution
> I assume you mean for the whole portals project. +1
Well, I indicated upfront to propose this (initially) for Jetspeed-2 only.
But of course, I'd like to see this to be extended to the whole of Portals project too.
See also my comments below.
>
> > - maintain separate Confluence spaces for release specific documentation
> > for jetspeed-2, j2-admin and future products
> Hmm, not sure if we need this. So this would also include to have a
> specific space for Pluto, Bridges etc?
Yes, and even potentially, depending on the goals for each project, distinct spaces per each (major) release.
See for example how Geronimo handles this:
Main website space - http://cwiki.apache.org/GMOxSITE/
Trunk development space - http://cwiki.apache.org/GMOxDEV/
Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/
Geronimo v.1.2 space - http://cwiki.apache.org/GMOxDOC12/
Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/
etc.
Now, if we are going to extend my proposal for the whole of Portals project (or at least including the main site), we might optimize this a bit.
In my view, there is/should only be a need for one primary (release independent) website space.
This space (PORTALS) can then contain all general information for both the Portals project (like http://portals.apache.org) as well as for the subprojects
(Jetspeed, Pluto, Bridges, etc.).
Then, each sub project can need additional release related spaces, like J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
Finally, we can simply switch to one Confluence space for the "public" wiki for the whole Portals project too, something like PORTALSxWIKI.
>
> > - integrate all the above in one new main cwiki based jetspeed-2 project
> > website
> Can you elaborate a little bit on this one please?
The global PORTALS space should integrate all of the above spaces similar to how other projects do this, as well as additional resources like generated
javadocs, reports etc. for which we still can use maven but need to provide links to from the Confluence space(s).
So, if you would want to expand this proposal to include Portals itself, Pluto, Bridges, maybe even WSRP4J etc., +1
Ate
>
> Carsten
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Carsten Ziegeler <cz...@apache.org>.
Big +1 for using Confluence; we are using it for several projects
(Felix, Sling, Jackrabbit) already and it works nicely.
>> If they have a CLA on file, and are contributing to the official project
>> documentation, they *ARE* Committers. They just aren't coders, and don't
>> have SVN access.
> Well, that's not how I understand how it is described on the CWIKI page,
> or even here: http://www.apache.org/foundation/how-it-works.html.
> Although a committer must have a CLA on file, can't a "contributer" have
> a CLA on file too without being a committer?
Yes, that's how we do it in other projects. You need a CLA and then can
contribute to the docs without being a "svn committer".
Ate Douma wrote:
> My proposal is simple:
> - switch to using this Confluence+cwiki solution
I assume you mean for the whole portals project. +1
> - maintain separate Confluence spaces for release specific documentation
> for jetspeed-2, j2-admin and future products
Hmm, not sure if we need this. So this would also include to have a
specific space for Pluto, Bridges etc?
> - integrate all the above in one new main cwiki based jetspeed-2 project
> website
Can you elaborate a little bit on this one please?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Ugh, as David already pointed out, x-posting such a message leads to confusion where follow up responses should be send too.
I should have known better and send this to general@ in the first place.
Anyway, sending this one last time "across the board" so everyone is aware to follow up please on general@ now.
Now in response to Noel, see further comments below
Noel J. Bergman wrote:
> +1, but ...
>
>> we now are working on a major overhaul of the Jetspeed-2 build system
>> (dropping the old maven-1/2 structure and replacing it with a clean
>> maven-2 project rewrite from scratch)
>
> How's about dropping Maven entirely, and using a proper Ant build system?
> :-) ESPECIALLY if you are no longer going to use Maven to generate site
> content.
Right, why not add some more confusion to the x-posting mess by hijacking the proposal and add some Maven v.s. Ant controversy ;)
I just want to say (now) that I'm of course open to discuss this further, but please in a separate thread.
While I might not be the biggest maven fan on this planet (for sure), I still do see merit in using it.
Furthermore, moving to Confluence doesn't mean we no longer can use maven to generate some metadata/reports/javadoc pages etc. for integrating in the site as well.
>
>> - switch to using this Confluence+cwiki solution
>
>> - also allow selected end users (non-committers but with a CLA on file)
>> to maintain these official documentation spaces
>
> If they have a CLA on file, and are contributing to the official project
> documentation, they *ARE* Committers. They just aren't coders, and don't
> have SVN access.
Well, that's not how I understand how it is described on the CWIKI page, or even here: http://www.apache.org/foundation/how-it-works.html.
Although a committer must have a CLA on file, can't a "contributer" have a CLA on file too without being a committer?
My interpretation (and idea behind this) was a more "light weight" process could be followed to allow contributers modifying official project documentation once
they signed a CLA.
But if having a CLA on file == committer, I think it only slightly limits our flexibility here and won't really matter much for the proposal.
Regards,
Ate
>
> --- Noel
>
>
>
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Ugh, as David already pointed out, x-posting such a message leads to confusion where follow up responses should be send too.
I should have known better and send this to general@ in the first place.
Anyway, sending this one last time "across the board" so everyone is aware to follow up please on general@ now.
Now in response to Noel, see further comments below
Noel J. Bergman wrote:
> +1, but ...
>
>> we now are working on a major overhaul of the Jetspeed-2 build system
>> (dropping the old maven-1/2 structure and replacing it with a clean
>> maven-2 project rewrite from scratch)
>
> How's about dropping Maven entirely, and using a proper Ant build system?
> :-) ESPECIALLY if you are no longer going to use Maven to generate site
> content.
Right, why not add some more confusion to the x-posting mess by hijacking the proposal and add some Maven v.s. Ant controversy ;)
I just want to say (now) that I'm of course open to discuss this further, but please in a separate thread.
While I might not be the biggest maven fan on this planet (for sure), I still do see merit in using it.
Furthermore, moving to Confluence doesn't mean we no longer can use maven to generate some metadata/reports/javadoc pages etc. for integrating in the site as well.
>
>> - switch to using this Confluence+cwiki solution
>
>> - also allow selected end users (non-committers but with a CLA on file)
>> to maintain these official documentation spaces
>
> If they have a CLA on file, and are contributing to the official project
> documentation, they *ARE* Committers. They just aren't coders, and don't
> have SVN access.
Well, that's not how I understand how it is described on the CWIKI page, or even here: http://www.apache.org/foundation/how-it-works.html.
Although a committer must have a CLA on file, can't a "contributer" have a CLA on file too without being a committer?
My interpretation (and idea behind this) was a more "light weight" process could be followed to allow contributers modifying official project documentation once
they signed a CLA.
But if having a CLA on file == committer, I think it only slightly limits our flexibility here and won't really matter much for the proposal.
Regards,
Ate
>
> --- Noel
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Ugh, as David already pointed out, x-posting such a message leads to confusion where follow up responses should be send too.
I should have known better and send this to general@ in the first place.
Anyway, sending this one last time "across the board" so everyone is aware to follow up please on general@ now.
Now in response to Noel, see further comments below
Noel J. Bergman wrote:
> +1, but ...
>
>> we now are working on a major overhaul of the Jetspeed-2 build system
>> (dropping the old maven-1/2 structure and replacing it with a clean
>> maven-2 project rewrite from scratch)
>
> How's about dropping Maven entirely, and using a proper Ant build system?
> :-) ESPECIALLY if you are no longer going to use Maven to generate site
> content.
Right, why not add some more confusion to the x-posting mess by hijacking the proposal and add some Maven v.s. Ant controversy ;)
I just want to say (now) that I'm of course open to discuss this further, but please in a separate thread.
While I might not be the biggest maven fan on this planet (for sure), I still do see merit in using it.
Furthermore, moving to Confluence doesn't mean we no longer can use maven to generate some metadata/reports/javadoc pages etc. for integrating in the site as well.
>
>> - switch to using this Confluence+cwiki solution
>
>> - also allow selected end users (non-committers but with a CLA on file)
>> to maintain these official documentation spaces
>
> If they have a CLA on file, and are contributing to the official project
> documentation, they *ARE* Committers. They just aren't coders, and don't
> have SVN access.
Well, that's not how I understand how it is described on the CWIKI page, or even here: http://www.apache.org/foundation/how-it-works.html.
Although a committer must have a CLA on file, can't a "contributer" have a CLA on file too without being a committer?
My interpretation (and idea behind this) was a more "light weight" process could be followed to allow contributers modifying official project documentation once
they signed a CLA.
But if having a CLA on file == committer, I think it only slightly limits our flexibility here and won't really matter much for the proposal.
Regards,
Ate
>
> --- Noel
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [PROPOSAL] Move to confluence and cwiki for project website and
documentation
Posted by Ate Douma <at...@douma.nu>.
Ugh, as David already pointed out, x-posting such a message leads to confusion where follow up responses should be send too.
I should have known better and send this to general@ in the first place.
Anyway, sending this one last time "across the board" so everyone is aware to follow up please on general@ now.
Now in response to Noel, see further comments below
Noel J. Bergman wrote:
> +1, but ...
>
>> we now are working on a major overhaul of the Jetspeed-2 build system
>> (dropping the old maven-1/2 structure and replacing it with a clean
>> maven-2 project rewrite from scratch)
>
> How's about dropping Maven entirely, and using a proper Ant build system?
> :-) ESPECIALLY if you are no longer going to use Maven to generate site
> content.
Right, why not add some more confusion to the x-posting mess by hijacking the proposal and add some Maven v.s. Ant controversy ;)
I just want to say (now) that I'm of course open to discuss this further, but please in a separate thread.
While I might not be the biggest maven fan on this planet (for sure), I still do see merit in using it.
Furthermore, moving to Confluence doesn't mean we no longer can use maven to generate some metadata/reports/javadoc pages etc. for integrating in the site as well.
>
>> - switch to using this Confluence+cwiki solution
>
>> - also allow selected end users (non-committers but with a CLA on file)
>> to maintain these official documentation spaces
>
> If they have a CLA on file, and are contributing to the official project
> documentation, they *ARE* Committers. They just aren't coders, and don't
> have SVN access.
Well, that's not how I understand how it is described on the CWIKI page, or even here: http://www.apache.org/foundation/how-it-works.html.
Although a committer must have a CLA on file, can't a "contributer" have a CLA on file too without being a committer?
My interpretation (and idea behind this) was a more "light weight" process could be followed to allow contributers modifying official project documentation once
they signed a CLA.
But if having a CLA on file == committer, I think it only slightly limits our flexibility here and won't really matter much for the proposal.
Regards,
Ate
>
> --- Noel
>
>
>
RE: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by "Noel J. Bergman" <no...@devtech.com>.
+1, but ...
> we now are working on a major overhaul of the Jetspeed-2 build system
> (dropping the old maven-1/2 structure and replacing it with a clean
> maven-2 project rewrite from scratch)
How's about dropping Maven entirely, and using a proper Ant build system?
:-) ESPECIALLY if you are no longer going to use Maven to generate site
content.
> - switch to using this Confluence+cwiki solution
> - also allow selected end users (non-committers but with a CLA on file)
> to maintain these official documentation spaces
If they have a CLA on file, and are contributing to the official project
documentation, they *ARE* Committers. They just aren't coders, and don't
have SVN access.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
RE: [PROPOSAL] Move to confluence and cwiki for project website and documentation
Posted by "Noel J. Bergman" <no...@devtech.com>.
+1, but ...
> we now are working on a major overhaul of the Jetspeed-2 build system
> (dropping the old maven-1/2 structure and replacing it with a clean
> maven-2 project rewrite from scratch)
How's about dropping Maven entirely, and using a proper Ant build system?
:-) ESPECIALLY if you are no longer going to use Maven to generate site
content.
> - switch to using this Confluence+cwiki solution
> - also allow selected end users (non-committers but with a CLA on file)
> to maintain these official documentation spaces
If they have a CLA on file, and are contributing to the official project
documentation, they *ARE* Committers. They just aren't coders, and don't
have SVN access.
--- Noel