using confluence as the official ofbiz.org site?

[Si Chen-2]

Hey -

My last "general thought" of the day: what about using confluence as  
the ofbiz.org site, maybe customized or enhanced?  I've seen a lot of  
open source projects use wiki-based sites for their projects, and now  
I think I see why: it is better when there are a lot of different  
people creating content.

Si

[Adam Heath-2]

Si Chen wrote:
> Hey -
>
> My last "general thought" of the day: what about using confluence as the
> ofbiz.org site, maybe customized or enhanced?  I've seen a lot of open
> source projects use wiki-based sites for their projects, and now I think
> I see why: it is better when there are a lot of different people
> creating content.

Do you have a link to this software?

[Si Chen-2]

Well take a look at http://docs.ofbiz.org there should be some links  
to confluence there already.  I was just thinking of making this docs  
site the ofbiz.org site?


On Jun 27, 2006, at 1:32 PM, Adam Heath wrote:

> Si Chen wrote:
>> Hey -
>> My last "general thought" of the day: what about using confluence  
>> as the ofbiz.org site, maybe customized or enhanced?  I've seen a  
>> lot of open source projects use wiki-based sites for their  
>> projects, and now I think I see why: it is better when there are a  
>> lot of different people creating content.
>
> Do you have a link to this software?

[David E. Jones]

I'm not sure how good an idea this is right now, mostly for organizational reasons.

It would be nice if the new site is launched on the Apache web servers so we need to use the infrastructure they have available. To keep it simple for now plain HTML files would be nice.

Right now there is no official ASF Confluence server, just one hosted by Atlassian for the ASF, but I wouldn't be surprised to see that change in the future.

-David


Si Chen wrote:
> Hey -
>
> My last "general thought" of the day: what about using confluence as the
> ofbiz.org site, maybe customized or enhanced?  I've seen a lot of open
> source projects use wiki-based sites for their projects, and now I think
> I see why: it is better when there are a lot of different people
> creating content.
>
> Si

[Adam Heath-2]

get it.
people still think that top-posting is a good thing to do.  I just don't
of speech.  Documents all follow a top-down layout of information.  Yet
Why do people use top-posting?  It doesn't follow with the natural flow

Si Chen wrote:
> Well take a look at http://docs.ofbiz.org there should be some links to
> confluence there already.  I was just thinking of making this docs site
> the ofbiz.org site?

Um, this seems bad.  Using non-free software for a free software
project?  Wouldn't this be equally bad, now that ofbiz is an apache project?

[Si Chen-2]

Ok, that makes sense.

On Jun 27, 2006, at 1:51 PM, David E. Jones wrote:

>
> I'm not sure how good an idea this is right now, mostly for  
> organizational reasons.
>
> It would be nice if the new site is launched on the Apache web  
> servers so we need to use the infrastructure they have available.  
> To keep it simple for now plain HTML files would be nice.
>
> Right now there is no official ASF Confluence server, just one  
> hosted by Atlassian for the ASF, but I wouldn't be surprised to see  
> that change in the future.
>
> -David
>
>
> Si Chen wrote:
>> Hey -
>> My last "general thought" of the day: what about using confluence  
>> as the ofbiz.org site, maybe customized or enhanced?  I've seen a  
>> lot of open source projects use wiki-based sites for their  
>> projects, and now I think I see why: it is better when there are a  
>> lot of different people creating content.
>> Si

[davidnwelton]

> Um, this seems bad.  Using non-free software for a free software
> project?  Wouldn't this be equally bad, now that ofbiz is an apache project?

Actually, the ASF 'started it' - they've been using JIRA for a while now.

There is certainly an argument to be made for 'eating your own
dogfood' in terms of utilizing free software, but this probably isn't
the right place to take up that debate.  Suffice it to say that
certain proprietary bits and pieces are ok - JIRA, maybe Confluence.
And...well... Java:-)

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[Jacques Le Roux]

Why not giving a try to java CMS tools ? We could make a double shoot here : by
using one of them we may evaluate the tool and if possible reuse it after in
OFBiz ?

In Nabble (you know with this plugin from Firas ;o) I found already commented in
the MLs

OpenCMS (http://www.opencms.org/opencms/en/download/opencms.html) GPL :(
Magnolia (http://sourceforge.net/projects/magnolia/) too small ?
Alfresco (http://sourceforge.net/projects/alfresco/) seems to have seduce some
OFBizer

http://sourceforge.net/projects/lportal/ ?

And of course
http://jackrabbit.apache.org/faq.html
http://lenya.apache.org/ (in cocoon?)
http://new.cocoondev.org/daisy/index.htmln (in cocoon)
a lot of CMS by there...

Jacques


>
> I'm not sure how good an idea this is right now, mostly for organizational
reasons.
>
> It would be nice if the new site is launched on the Apache web servers so we
need to use the infrastructure they have available. To keep it simple for now
plain HTML files would be nice.
>
> Right now there is no official ASF Confluence server, just one hosted by
Atlassian for the ASF, but I wouldn't be surprised to see that change in the
future.

>
> -David
>
>
> Si Chen wrote:
> > Hey -
> >
> > My last "general thought" of the day: what about using confluence as the
> > ofbiz.org site, maybe customized or enhanced?  I've seen a lot of open
> > source projects use wiki-based sites for their projects, and now I think
> > I see why: it is better when there are a lot of different people
> > creating content.
> >
> > Si

[David E. Jones]

Adam,

These are 2 very good examples of the Purist and Idealist styles of thinking. While useful to some extent, my vote has to go with a more context-aware Pragmatic style.


Adam Heath wrote:
> get it.

Yeah, got it. Yo, check it! ;)

> people still think that top-posting is a good thing to do.  I just don't
> of speech.  Documents all follow a top-down layout of information.  Yet
> Why do people use top-posting?  It doesn't follow with the natural flow

If there is a conversational flow, the in-line replies are great, especially for multiple thoughts on multiple "threads" in a single email. It's way efficient, and cool. If you're responding in a more general way and to a single thought I think in-line posting is bloody annoying. Especially if someone replies to a long message way down at the bottom and you have to scroll all over the place to see what the reply looks like.

> Si Chen wrote:
>> Well take a look at http://docs.ofbiz.org there should be some links
>> to confluence there already.  I was just thinking of making this docs
>> site the ofbiz.org site?
>
> Um, this seems bad.  Using non-free software for a free software
> project?  Wouldn't this be equally bad, now that ofbiz is an apache
> project?

David Welton answered this pretty well. Here again I like a pragmatic approach. I'm all for open source software, when it's available and a tenable option. I'll be the first to admit that OFBiz, for example, is not the solution for all problems.

I'd love to use OFBiz-based stuff instead of commercial things (even open source based commercial things like the Atlassian products, of which Jira actually even uses parts of OFBiz), but we just don't have the functionality on the business/applications level in these areas nor the resources to build them out, especially not within the time frame we need them (like immediate and ongoing...).

Of course, once we do... ;) Then it's just an issue of making sure we can get such things deployed on the ASF infrastructure (though I guess they're pretty cool about new tools and such).

-David

[Adam Heath-2]

David E. Jones wrote:

>> people still think that top-posting is a good thing to do.  I just don't
>> of speech.  Documents all follow a top-down layout of information.  Yet
>> Why do people use top-posting?  It doesn't follow with the natural flow
>
> If there is a conversational flow, the in-line replies are great,
> especially for multiple thoughts on multiple "threads" in a single
> email. It's way efficient, and cool. If you're responding in a more
> general way and to a single thought I think in-line posting is bloody
> annoying. Especially if someone replies to a long message way down at
> the bottom and you have to scroll all over the place to see what the
> reply looks like.

Well, generally top-posters don't do editting of the email before
sending their response.  They just add their 2 bits at the top, and keep
the *entire* previous conversation underneath.  Certainly, in that
sense, scrolling thru the entire email body would be tedious.

Proper email etiquette would trim down the email, before commenting.
This is when you see things like [snip] inside the standard '> ' that
preceeds a response.  It also saves bandwidth, and the email comes out
smaller.

For example, I deleted most of your email, as it has become 2 threads.
I also changed the topic slightly, while still leaving enough for those
who only use subject sorting to know that the thread has changed gears.

[Adrian Crum]

Adam Heath wrote:
> David E. Jones wrote:
>
>>> people still think that top-posting is a good thing to do.  I just don't
>>> of speech.  Documents all follow a top-down layout of information.  Yet
>>> Why do people use top-posting?  It doesn't follow with the natural flow

[snip]

> Well, generally top-posters don't do editting of the email before
> sending their response.  They just add their 2 bits at the top, and keep
> the *entire* previous conversation underneath.  Certainly, in that
> sense, scrolling thru the entire email body would be tedious.

[snip]

> For example, I deleted most of your email, as it has become 2 threads. I
> also changed the topic slightly, while still leaving enough for those
> who only use subject sorting to know that the thread has changed gears.

I've followed the suggested etiquette. Now future readers of this email will
have to scroll through lists of emails to find the context of our conversation.
Will that be easier? Probably not.

[Adam Heath-2]

David E. Jones wrote:
>> Um, this seems bad.  Using non-free software for a free software
>> project?  Wouldn't this be equally bad, now that ofbiz is an apache
>> project?
>
> David Welton answered this pretty well. Here again I like a pragmatic
> approach. I'm all for open source software, when it's available and a
> tenable option. I'll be the first to admit that OFBiz, for example, is
> not the solution for all problems.

Yeah, he did.

> I'd love to use OFBiz-based stuff instead of commercial things (even
> open source based commercial things like the Atlassian products, of
> which Jira actually even uses parts of OFBiz), but we just don't have
> the functionality on the business/applications level in these areas nor
> the resources to build them out, especially not within the time frame we
> need them (like immediate and ongoing...).

Well, if you recall, last summer during the OfBiz User's Conference, we
were displaying some wiki based software.  We're fast approaching the 1
year mark on it's birth, and we haven't sat still with it's development.

Right now, I am rewriting the basic framework in it, extracting it out
of OfBiz proper, and making it a stand-alone project.  Said project will
be under either a BSD or ASF license; we haven't fully decided.

Main features:

* commons-vfs for generic file access
   * implemented filesystems:
     * COW(Copy-On-Write).  Used for quick templating/extension.
       Changing a file contents is supported, as are deletes.  Multiple
       parents are supported(a single directory can have multiple parent
       directories it inherits from).  Also, if a parent directory is
       also COWed, then it can still walk all that.  Directory listings
       function as expected.
     * flat.  Attributes of files are stored in a foo@ directory, one
       file per attribute.  This sits on top of COW, so overriding a
       single attribute is simple.
     * SVN.  Uses libsvnjava-hl, for automatic revision control of file
       modifications.  The actual SVN filesystem itself uses a generic
       revision control API, so in theory other systems could be plugged
       in.
* BSF, with compilation support
   * Existing BSF engines were rewritten, to support dynamic class-based

     source loading.  This includes the ability to load from File,
     String, URL, and FileObject(commons-vfs).  The BSF API uses an
     Object as the source, so this was a straight-forward extension.
   * The new implementations also compile the source, for a large
     speedup.
   * python(jython), java(janino), php(quercus), javascript(rhino), and
     ruby(jruby) all exist in this new framework.
   * Only one extension to BSF has been made: apply allows for optionally
     specifying the type of the named arguments
* A template engine, based on the BSF API
   * freemarker and velocity are plugged into this system
   * A macro can be written in any template language, and included in
any
     template language.
   * Macros can have both parameters, and bodies.
   * A resource can be in any language; it's parent template that it is
     included into can then be in another language.  Named sections can
     also be written in any language.

     For example, /foo has a template set to /templates/bar.
     /templates/bar then has a template of /templates/baz.  /foo is a
     velocity file.  bar could be an event(which could be written in
     java/python/php/ruby/javascript), that changes the text based on
     permissions, time-of-day, or phases of the moon.  Like maybe
     changing the color, css, or switching left/right sides of a div.
     Then, once the event had made it's decision, the baz template would
     be used to wrapped it's output.

* A resource can be a bit of text, interpeted as a template, or a bit of
   code, that is run when it is requested.
* Code-based resources include standard events, and something we call a
   filter(bad name).  A filter can do whatever kind of processing it
   wants with the rest of the path that comes after it.  For example:

   /category/10000/0/20/summary

   This would show category 10000, starting and page 0, show 20 items per
   page, and show the summary of the products.  What is nice about this
   approach, is it makes for very nice entries in access logs.
* Since a resource can be either code or text, the template engine also
   works with that.  A named section, parent template, or macro can
   actual be a bit of code, that does complex processing.  Again, and
   example may be the easiest way to describe this.

   freemarker:
   <tr>
    <td>
     <@TemplateMerge name="/category/10000/0/20/summary"/>
    </td>
   <tr>
* Most code(with the exception of the very low-level commons-vfs
   filesystems, and the single servlet) is runtime changeable.  You can
   edit the actual dispatcher code at runtime, and the classloader will
   be recycled.
* A runtime controllable(by having events run, or even editting the
   dispatcher java file itself), allows one to have very complex
   request->site mapping.  One can do the normal host->site mapping, but
   could also do something based on time-of-day.
* Something that could be done with this system, is a nice use of the
   COW feature, and the above site mapping.  There could be a base
   directory, that contained all the code for a site.  Then, when a
   request comes, a COWed directory that inherits from the code base
   could be selected, based on the user's locale, and possibly a geo-ip
   lookup.

As a framework, is it very extensible.  However, as with most projects,
it has reach a point where it has accumulated cruft; both in the form of
poorly implemented features, and backwards compatibility.  This is the
reason I am currently reworking it to be standalone, and a separately
released project.

However, the existing code-base has been put to quite a bit of testing.
  An example of both the framework, and the ofbiz integration, is at
http://checkmark.heart.org.

[David E. Jones]

By way of general commentary on this: the functionality sounds great as a starting point for something that could compete well with Confluence. The functionality here is still mostly oriented at solving technical problems though, and in the case of docs.ofbiz.org there are certain functionality requirements we need that would still have to be built.

I would also be concerned with this for a public wiki unless the code that you can include in a page is extremely limited and can't do much, and even then it would be a constant security concern. If you have an internal group working on stuff then it's not such a big deal, but for a public wiki even if controlled going in that direction is a bit scary.

However it's done when there is an alternative that is totally open source, and it is one that the ASF supports or is likely to support, then we can go for it. Until then, there's not much we can do.

For this thing on its own it looks pretty cool and it will be great to see it available in an open source project.

-David


Adam Heath wrote:

>> I'd love to use OFBiz-based stuff instead of commercial things (even
>> open source based commercial things like the Atlassian products, of
>> which Jira actually even uses parts of OFBiz), but we just don't have
>> the functionality on the business/applications level in these areas
>> nor the resources to build them out, especially not within the time
>> frame we need them (like immediate and ongoing...).
>
> Well, if you recall, last summer during the OfBiz User's Conference, we
> were displaying some wiki based software.  We're fast approaching the 1
> year mark on it's birth, and we haven't sat still with it's development.
>
> Right now, I am rewriting the basic framework in it, extracting it out
> of OfBiz proper, and making it a stand-alone project.  Said project will
> be under either a BSD or ASF license; we haven't fully decided.
>
> Main features:
>
> * commons-vfs for generic file access
>   * implemented filesystems:
>     * COW(Copy-On-Write).  Used for quick templating/extension.
>       Changing a file contents is supported, as are deletes.  Multiple
>       parents are supported(a single directory can have multiple parent
>       directories it inherits from).  Also, if a parent directory is
>       also COWed, then it can still walk all that.  Directory listings
>       function as expected.
>     * flat.  Attributes of files are stored in a foo@ directory, one
>       file per attribute.  This sits on top of COW, so overriding a
>       single attribute is simple.
>     * SVN.  Uses libsvnjava-hl, for automatic revision control of file
>       modifications.  The actual SVN filesystem itself uses a generic
>       revision control API, so in theory other systems could be plugged
>       in.
> * BSF, with compilation support
>   * Existing BSF engines were rewritten, to support dynamic class-based
>     source loading.  This includes the ability to load from File,
>     String, URL, and FileObject(commons-vfs).  The BSF API uses an
>     Object as the source, so this was a straight-forward extension.
>   * The new implementations also compile the source, for a large
>     speedup.
>   * python(jython), java(janino), php(quercus), javascript(rhino), and
>     ruby(jruby) all exist in this new framework.
>   * Only one extension to BSF has been made: apply allows for optionally
>     specifying the type of the named arguments
> * A template engine, based on the BSF API
>   * freemarker and velocity are plugged into this system
>   * A macro can be written in any template language, and included in any
>     template language.
>   * Macros can have both parameters, and bodies.
>   * A resource can be in any language; it's parent template that it is
>     included into can then be in another language.  Named sections can
>     also be written in any language.
>
>     For example, /foo has a template set to /templates/bar.
>     /templates/bar then has a template of /templates/baz.  /foo is a
>     velocity file.  bar could be an event(which could be written in
>     java/python/php/ruby/javascript), that changes the text based on
>     permissions, time-of-day, or phases of the moon.  Like maybe
>     changing the color, css, or switching left/right sides of a div.
>     Then, once the event had made it's decision, the baz template would
>     be used to wrapped it's output.
>
> * A resource can be a bit of text, interpeted as a template, or a bit of
>   code, that is run when it is requested.
> * Code-based resources include standard events, and something we call a
>   filter(bad name).  A filter can do whatever kind of processing it
>   wants with the rest of the path that comes after it.  For example:
>
>   /category/10000/0/20/summary
>
>   This would show category 10000, starting and page 0, show 20 items per
>   page, and show the summary of the products.  What is nice about this
>   approach, is it makes for very nice entries in access logs.
> * Since a resource can be either code or text, the template engine also
>   works with that.  A named section, parent template, or macro can
>   actual be a bit of code, that does complex processing.  Again, and
>   example may be the easiest way to describe this.
>
>   freemarker:
>   <tr>
>    <td>
>     <@TemplateMerge name="/category/10000/0/20/summary"/>
>    </td>
>   <tr>
> * Most code(with the exception of the very low-level commons-vfs
>   filesystems, and the single servlet) is runtime changeable.  You can
>   edit the actual dispatcher code at runtime, and the classloader will
>   be recycled.
> * A runtime controllable(by having events run, or even editting the
>   dispatcher java file itself), allows one to have very complex
>   request->site mapping.  One can do the normal host->site mapping, but
>   could also do something based on time-of-day.
> * Something that could be done with this system, is a nice use of the
>   COW feature, and the above site mapping.  There could be a base
>   directory, that contained all the code for a site.  Then, when a
>   request comes, a COWed directory that inherits from the code base
>   could be selected, based on the user's locale, and possibly a geo-ip
>   lookup.
>
> As a framework, is it very extensible.  However, as with most projects,
> it has reach a point where it has accumulated cruft; both in the form of
> poorly implemented features, and backwards compatibility.  This is the
> reason I am currently reworking it to be standalone, and a separately
> released project.
>
> However, the existing code-base has been put to quite a bit of testing.
>  An example of both the framework, and the ofbiz integration, is at
> http://checkmark.heart.org.
>

[Adam Heath-2]

Adrian Crum wrote:
> I've followed the suggested etiquette. Now future readers of this email
> will have to scroll through lists of emails to find the context of our
> conversation. Will that be easier? Probably not.

Because you snipped poorly, and didn't add anything to the conversation.

[davidnwelton]

I think that for a lot of things, were it me in charge, I think I'd
just look for an open source solution because I believe pretty
strongly in it, and I've most always found something good enough for
my own needs.  But the real decision makers on this issue as to what's
ok and what isn't are the ASF infrastructure guys who actually
maintain everything.  It is an open group and people can volunteer to
help out... but still, they need to be convinced that something isn't
going to be a huge burden.

Stuff that's too much for them to handle, and is deemed to be critical
can continue to be hosted on external sites, but I suppose that needs
to be looked at case by case, as it would be nice to share as much
infrastructure as possible in order to let the core OFBiz guys hack on
OFBiz rather than take time administrating stuff.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[Ean Schuessler]

David E. Jones wrote:

>
> By way of general commentary on this: the functionality sounds great
> as a starting point for something that could compete well with
> Confluence. The functionality here is still mostly oriented at solving
> technical problems though, and in the case of docs.ofbiz.org there are
> certain functionality requirements we need that would still have to be
> built.
>
> I would also be concerned with this for a public wiki unless the code
> that you can include in a page is extremely limited and can't do much,
> and even then it would be a constant security concern. If you have an
> internal group working on stuff then it's not such a big deal, but for
> a public wiki even if controlled going in that direction is a bit scary.
>
> However it's done when there is an alternative that is totally open
> source, and it is one that the ASF supports or is likely to support,
> then we can go for it. Until then, there's not much we can do.
>
> For this thing on its own it looks pretty cool and it will be great to
> see it available in an open source project.

We have had to address this issue for customer deployments. We check a
role on the website (assigned in the standard ofbiz way) to determine
whether you can edit a particular resource. Those roles can be
arbitrary. It would be simple to limit public editing to items that are
only of plain wiki text type. This would completely block an
unauthorized user from executing code.

One of the more public facing functions we've put the system into was
for the Sun Tech Days conference in Brasil. Using the copy-on-write
system we created a base conference template and then cloned it for 15
conferences in cities all over the country. Each site was assigned its
own staff using the party manager and website roles and each group could
edit its pages independently. You can see the results at
http://techdays.soujava.org.br. We used the same functionality to manage
the sign-ups for the Java Bloggers event at Java One. You can see that
at http://javabloggers.gobof.org.

I think that the system is probably up to the task of managing the OFBiz
wiki.