That's why I mentioned the pdf earlier. With Confluence, you could
create a pdf of the current wiki docs at release time which would
serve as (or contribute to) the documentation for that release. Each
pdf would be verified and checked into svn and become part of the
release as well as ta
David,
that documentation looks great. Is your second edition covering Shale?
The first image looks very professional ;)
-Matthias
On 8/9/06, David Geary <[EMAIL PROTECTED]> wrote:
I've attached an updated features-remote.xml to SHALE-130 that contains the
changes outlined below.
Thanks,
da
I've attached an updated features-remote.xml to SHALE-130 that contains the
changes outlined below.
Thanks,
david
2006/8/9, David Geary < [EMAIL PROTECTED]>:
Thanks for committing this, Wendy. It looks good. If you don't mind, could
you add a couple of updates? Thanks.
Please add these two
Thanks for committing this, Wendy. It looks good. If you don't mind, could
you add a couple of updates? Thanks.
Please add these two paragraphs at the end of Remoting Introduction, after
the bulleted list:
Processors are associated with URL patterns. Each processor has a default
pattern. For exa
On the other hand, anyone I am willing to trust with the web content is also
someone I would trust with repository access :-).
We should probably stick to the current "Apache way" whenever
possible. Its not worth adding such a distinction if it gets us
sidetracked from our main business. Bette
On 8/9/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
On 8/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > Another topic of concern was allowing people who have not been granted
> > committer status the ability to edit the official documentation for a
> > project.
>
> We could limit this t
On 8/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Another topic of concern was allowing people who have not been granted
> committer status the ability to edit the official documentation for a
> project.
We could limit this to just committers like we do now for the website
(where the docs a
Another topic of concern was allowing people who have not been granted
committer status the ability to edit the official documentation for a
project.
We could limit this to just committers like we do now for the website
(where the docs are now.) Ideally we could add people by invitation
and thi
> Another topic of concern was allowing people who have not
> been granted committer status the ability to edit the
> official documentation for a project.
I'd vote for some sort of policy that allows non-committers (like myself)
the ability to add to the docs. This is one of my chief complain
On 8/9/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
If we need two, it can be two Conflucence 'spaces'. I'm not planning
to do anything else on Moin Moin (the current wiki) if Confluence is
available.
I believe the infrastructure group's concerns with Confluence have
been addressed by a new plugi
On 8/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
So there would be 2 wikis? One for official documenation (confluence)
and one for community based documentation (current)?
If we need two, it can be two Conflucence 'spaces'. I'm not planning
to do anything else on Moin Moin (the current w
On 8/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
So there would be 2 wikis? One for official documenation (confluence)
and one for community based documentation (current)?
Yes, and only then if the confluence usage is as a static page
generator rather than as a wiki. I'm pretty sure that
So there would be 2 wikis? One for official documenation (confluence)
and one for community based documentation (current)?
To me the current Shale website is a bit overwhelming with
information. I like the idea of moving all of the getting started
docs to confluence and organizing them by subpr
+1
I agree that it's pretty superior, and I love the idea of being able to
easily contribute docs.
~~~
Kito D. Mann ([EMAIL PROTECTED])
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, an
Confluence as documentation is excellent. We've moved all of the
Apache Podling Cayenne's documentation to Confluence over the last
year or so.
Just be aware that infrastructure frowns on using Confluence for
anything other than a static website (or document) generator (for
example, using it as
On Aug 8, 2006, at 7:00 PM, Wendy Smoak wrote:
The space naming convention would probably give us SHLx___
Do we want to have just one space, and use it like we use Moin, or do
we want to push most of the project docs to the wiki?
I don't know anything about Confluence so I can't comment on i
16 matches
Mail list logo
