Thanks for your comments. I haven't gone through all the details and will do
that tomorrow. However, this caught my eye and wanted to better understand
your comment.
Java SCA
- Architecture Guide
- still pointing to the old one
What do you mean by "still pointing to the old one". If you follow the link
you should see this page
http://cwiki.apache.org/TUSCANY/java-sca-architecture-overview.html
I agree that the content should be updated, but want to make sure you are
seeing this page.
- DeveloperGuide
- I still think there should be a developer guide as it fits well under
What is a developer guide and how is the content different than what would
go into the 'get involved' page under development section?
Here is what I was thinking (perhaps it is not right):
User Guide would hold things like:
- Installation/setup information
- user type documentation (SCA concepts and examples, etc)
- How to develop a simple SCA application followed with more advanced
topics
GetInvolved link would point to information that anyone wanting to
contribute to SCA Java would need to know about, for example, code
structure, hints on development, etc.
Haleh
On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > <snip/>
> > >
> > > - I like the list of modules I think we should go with the
module
> > name
> > > > from the code and link to a separate
> > > > page for each one. (take a look I've made an example). We
can
> > then
> > > > use
> > > > URLs such as
> > > >
http://cwiki.apache.org/confluence/display/TUSCANY/binding-wsto
> > > > refer
> > > > directly to the module description(*)
> > >
> > >
> > > I like the one wiki page with the module name per module and as
well,
> > but
> > > do we really want all of those listed on the "Java SCA Subproject
> page"?
> > > That page seems more user oriented giving an overview of Java SCA
> > > capabilities, where as all the individual modules are a really deep
> > > implementation detail. For example how about on the "Java SCA
> > Subproject"
> > > page say Tuscany has a web service binding and links to a "web
> service"
> > > page
> > > which talks about the WS capabilities and its that "web service"
page
> > > where
> > > the list of WS related modules could go: binding-ws, binding-ws-xml,
> > > binding-ws-axis2, binding-ws-cxf, interface-wsdl,
interface-wsdl-xml,
> > > interface-wsdl-runtime etc. Similar thing for all the other binding,
> > > implementation, databinding, runtime etc.
> > >
> > > ...ant
> > >
> > I agree that this list doesn't need to go on this page but it would be
> > good
> > to have a straight list somewhere so it's easy to get the low down on
a
> > module. Perhaps in the develper guide as I had hoped that these module
> > pages
> > will include design information. I would expect the user docs for the
> > modules, i.e. what to put in the SCDL to make them work, to go in the
> User
> > Guide section. This could have a more user friendly index
as suggested
>
>
> A complete list does sound useful. How about the developer guide links
to
> something like an architecture page which has a diagram of the runtime,
a
> bit of a description about it, and the complete list of modules? Eg,
> Similar
> to [1] but the other way up and more text explaining it.
>
> ...ant
>
> [1]
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Modulization+Design+Discussions
>
I thinks that's spot on. Didn't know the page had been extended to include
the module list. Lets link it into the architecture page (when we decide
which architecture page we are having ;-). We can use module links from
this
page to record module design information. Module user information would be
separate of course.So doe this hierarchy look right
Architecture Guide ---> Module list ----> Module technical detail
^
|
User Guide ---> Implementation/Binding/Databinding... list --> Extension
User Guide
We could probably tie the two together as you suggest by indicating which
modules are used to implement an Implementation/Binding/Databinding
Simon
