[Important] Status and future direction

[David Crossley]

This is my personal opinion.

---oOo---

Status:

Forrest appears to be at a standstill.

It has been a long time since a release.
Also the previous release had a long gap.

---oOo---

Possible future directions:

A) Stay with current situation of Cocoon-2.1 version.

There is plenty of development that can be done
with our current Forrest/Cocoon technology.

Fine-tuning and clean-up.

Fully implement the new xml properties system.
I gather that it is ready. Just needs to be
configured for our sample sites, plugins, and docs,
and also documentation updated.

New plugins.

Improve the plugin infrastructure and address the
needs of ASF releases for our plugins.

Improvement and clean-up of documentation.

Development can still be done at Cocoon-2.1 and
our packaged Cocoon be updated. The process is
well documented.

B) Try to upgrade to Cocoon-2.2 version.

See past discussion in our dev mail archives.

C) Try to upgrade to Cocoon-3 version.

I don't know whether Cocoon-3 is ready or
possible for Forrest. Would someone else comment.

D) Develop some other core.

See past discussion in our dev mail archives.

E) Cease Forrest and move to the Apache Attic.

http://attic.apache.org/

---oOo---

Whatever happens, we still need to make a release.

Whatever happens, more people need to assist with
the project management tasks.

---oOo---

My opinion is that Forrest needs to make a decision
about which direction, and stick with it, developers
get involved to start Forrest moving again, and build
the community.

Options A to D have previous discussion in the
dev mail archives.

-David

[Tim Williams]

Thanks David, this is a tough, but necessary, conversation.

I snipped A and B because I don't consider them fruitful options at all.

> C) Try to upgrade to Cocoon-3 version.
> I don't know whether Cocoon-3 is ready or
> possible for Forrest. Would someone else comment.

Cocoon-3 seems ready from what I can tell, though it is already
suffering from the same things that drove me away from enjoying
regular Cocoon.  It's overly complex.  There was a time when the
return on the steep Cocoon learning curve was worth it but that time,
for me, has passed.  I now have minimum amount of spare time to hack
at Forrest and when I've tried lately, it's no longer a pleasure
primarily because I spend much of that time re-learning Cocoon
complexity instead of being productive.  I must admit that when I was
at the height of my Cocoon knowledge I was unempathetic to Ross'
pleas, but now, I probably couldn't agree with his sentiments more.
Anyway, I think this is a long way of saying that i honestly don't see
there being a future in a Cocoon-based Forrest.

> D) Develop some other core.
>
> See past discussion in our dev mail archives.

I think it's ultimately going to be this or the Attic.  Implementing
something that's intuitive, prefers convention, and doesn't attempt to
solve all problems could very well bring the fun back.  I think we'd
have a much easier time attracting new devs too since we wouldn't have
the problem of "yeah, forrest is easy to understand.... *after* you
understand this other ridiculously complex beast over there".

> E) Cease Forrest and move to the Apache Attic.
>
> http://attic.apache.org/

I think there is a niche out there for Forrest.  I've got a need now,
for example, for a simple documentation site but, unfortunately,
forrest is too much of a burden to use for it - documentation is a
side-show that people don't want to have to spend hours/days "coming
up to speed".  So I sincerely hope this option isn't where we end up.

> ---oOo---
>
> Whatever happens, we still need to make a release.

Agreed, I've been poking around at JIRA lately seeing what I can
tackle - as i mentioned the Cocoon (re)-learning curve has kept me
pretty unproductive though.

> Whatever happens, more people need to assist with
> the project management tasks.

Agreed, since I haven't contributed much lately to the coding, I
haven't been compelled to contribute at all.  That's not good, I know.

> ---oOo---
>
> My opinion is that Forrest needs to make a decision
> about which direction, and stick with it, developers
> get involved to start Forrest moving again, and build
> the community.
>
> Options A to D have previous discussion in the
> dev mail archives.

Again, I think D or E are the only viable long-term options.

--tim

[Ross Gardler-4]

I agree with

Sent from my mobile device.

On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:

> Thanks David, this is a tough, but necessary, conversation.
>
> I snipped A and B because I don't consider them fruitful options at  
> all.
>
>> C) Try to upgrade to Cocoon-3 version.
>> I don't know whether Cocoon-3 is ready or
>> possible for Forrest. Would someone else comment.
>
> Cocoon-3 seems ready from what I can tell, though it is already
> suffering from the same things that drove me away from enjoying
> regular Cocoon.  It's overly complex.  There was a time when the
> return on the steep Cocoon learning curve was worth it but that time,
> for me, has passed.  I now have minimum amount of spare time to hack
> at Forrest and when I've tried lately, it's no longer a pleasure
> primarily because I spend much of that time re-learning Cocoon
> complexity instead of being productive.  I must admit that when I was
> at the height of my Cocoon knowledge I was unempathetic to Ross'
> pleas, but now, I probably couldn't agree with his sentiments more.
> Anyway, I think this is a long way of saying that i honestly don't see
> there being a future in a Cocoon-based Forrest.
>
>> D) Develop some other core.
>>
>> See past discussion in our dev mail archives.
>
> I think it's ultimately going to be this or the Attic.  Implementing
> something that's intuitive, prefers convention, and doesn't attempt to
> solve all problems could very well bring the fun back.  I think we'd
> have a much easier time attracting new devs too since we wouldn't have
> the problem of "yeah, forrest is easy to understand.... *after* you
> understand this other ridiculously complex beast over there".
>
>> E) Cease Forrest and move to the Apache Attic.
>>
>> http://attic.apache.org/
>
> I think there is a niche out there for Forrest.  I've got a need now,
> for example, for a simple documentation site but, unfortunately,
> forrest is too much of a burden to use for it - documentation is a
> side-show that people don't want to have to spend hours/days "coming
> up to speed".  So I sincerely hope this option isn't where we end up.
>
>> ---oOo---
>>
>> Whatever happens, we still need to make a release.
>
> Agreed, I've been poking around at JIRA lately seeing what I can
> tackle - as i mentioned the Cocoon (re)-learning curve has kept me
> pretty unproductive though.
>
>> Whatever happens, more people need to assist with
>> the project management tasks.
>
> Agreed, since I haven't contributed much lately to the coding, I
> haven't been compelled to contribute at all.  That's not good, I know.
>
>> ---oOo---
>>
>> My opinion is that Forrest needs to make a decision
>> about which direction, and stick with it, developers
>> get involved to start Forrest moving again, and build
>> the community.
>>
>> Options A to D have previous discussion in the
>> dev mail archives.
>
> Again, I think D or E are the only viable long-term options.
>
> --tim

[Ross Gardler-4]

I agree with Tim here, especially the bit where he can't agree with me  
more ;-)

I don't know a great deal about Cocoon 3, but I have no personal  
interest in using it here - sledgehammer to crack a nut. Since I'm not  
active here my opinion doesn't count for much in that respect though.

If someone wanted to look at and validate my evening hacks on Forrest  
2 I might be drawn back in, I do have a need for such a lightweight  
and embeddable solution. However, I don't have the time or resources  
to drive forward alone on thIs.

David, thank you for raising this issue.

Sorry about top posting...
Sent from my mobile device.

On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:

> Thanks David, this is a tough, but necessary, conversation.
>
> I snipped A and B because I don't consider them fruitful options at  
> all.
>
>> C) Try to upgrade to Cocoon-3 version.
>> I don't know whether Cocoon-3 is ready or
>> possible for Forrest. Would someone else comment.
>
> Cocoon-3 seems ready from what I can tell, though it is already
> suffering from the same things that drove me away from enjoying
> regular Cocoon.  It's overly complex.  There was a time when the
> return on the steep Cocoon learning curve was worth it but that time,
> for me, has passed.  I now have minimum amount of spare time to hack
> at Forrest and when I've tried lately, it's no longer a pleasure
> primarily because I spend much of that time re-learning Cocoon
> complexity instead of being productive.  I must admit that when I was
> at the height of my Cocoon knowledge I was unempathetic to Ross'
> pleas, but now, I probably couldn't agree with his sentiments more.
> Anyway, I think this is a long way of saying that i honestly don't see
> there being a future in a Cocoon-based Forrest.
>
>> D) Develop some other core.
>>
>> See past discussion in our dev mail archives.
>
> I think it's ultimately going to be this or the Attic.  Implementing
> something that's intuitive, prefers convention, and doesn't attempt to
> solve all problems could very well bring the fun back.  I think we'd
> have a much easier time attracting new devs too since we wouldn't have
> the problem of "yeah, forrest is easy to understand.... *after* you
> understand this other ridiculously complex beast over there".
>
>> E) Cease Forrest and move to the Apache Attic.
>>
>> http://attic.apache.org/
>
> I think there is a niche out there for Forrest.  I've got a need now,
> for example, for a simple documentation site but, unfortunately,
> forrest is too much of a burden to use for it - documentation is a
> side-show that people don't want to have to spend hours/days "coming
> up to speed".  So I sincerely hope this option isn't where we end up.
>
>> ---oOo---
>>
>> Whatever happens, we still need to make a release.
>
> Agreed, I've been poking around at JIRA lately seeing what I can
> tackle - as i mentioned the Cocoon (re)-learning curve has kept me
> pretty unproductive though.
>
>> Whatever happens, more people need to assist with
>> the project management tasks.
>
> Agreed, since I haven't contributed much lately to the coding, I
> haven't been compelled to contribute at all.  That's not good, I know.
>
>> ---oOo---
>>
>> My opinion is that Forrest needs to make a decision
>> about which direction, and stick with it, developers
>> get involved to start Forrest moving again, and build
>> the community.
>>
>> Options A to D have previous discussion in the
>> dev mail archives.
>
> Again, I think D or E are the only viable long-term options.
>
> --tim

[Thorsten Scherler]

On 08/10/2009, at 21:07, Ross Gardler wrote:

> I agree with Tim here, especially the bit where he can't agree with  
> me more ;-)
>
> I don't know a great deal about Cocoon 3, but I have no personal  
> interest in using it here - sledgehammer to crack a nut. Since I'm  
> not active here my opinion doesn't count for much in that respect  
> though.

I am still developing mostly with cocoon in different versions. Just a  
couple of days back I had a chance to use cocoon 3 within droids and I  
have to say it is not sledgehammer anymore. You can use it without any  
sitemap if you want. ...

more inline

>
> If someone wanted to look at and validate my evening hacks on  
> Forrest 2 I might be drawn back in, I do have a need for such a  
> lightweight and embeddable solution. However, I don't have the time  
> or resources to drive forward alone on thIs.
>
> David, thank you for raising this issue.
>
> Sorry about top posting...
> Sent from my mobile device.
>
> On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:
>
>> Thanks David, this is a tough, but necessary, conversation.
>>
>> I snipped A and B because I don't consider them fruitful options at  
>> all.

IMO A should be the way to wrap up current development. Like pointed  
out by David we need to have a release that  contains the work of the  
last years since the release.

I talked about trying to do the release but this task got moved down  
my priority list again due to workload. Actually in my work we ATM  
only use the cocoon 2.2 blocks from forrest and they are working fine.  
To move to cocoon 2.2 at whole is IMO as well not worth the while  
since we will find quite a bunch of problems which are not easily  
solvable.


>>
>>> C) Try to upgrade to Cocoon-3 version.
>>> I don't know whether Cocoon-3 is ready or
>>> possible for Forrest. Would someone else comment.
>>
>> Cocoon-3 seems ready from what I can tell, though it is already
>> suffering from the same things that drove me away from enjoying
>> regular Cocoon.  It's overly complex.

Hmm, I am not sure whether I can sign that. Cocoon 3 is quite straight  
forward and flexible to integrate in what ever underlying framework  
you like to use.

>> There was a time when the
>> return on the steep Cocoon learning curve was worth it but that time,
>> for me, has passed.  I now have minimum amount of spare time to hack
>> at Forrest and when I've tried lately, it's no longer a pleasure
>> primarily because I spend much of that time re-learning Cocoon
>> complexity instead of being productive.  I must admit that when I was
>> at the height of my Cocoon knowledge I was unempathetic to Ross'
>> pleas, but now, I probably couldn't agree with his sentiments more.
>> Anyway, I think this is a long way of saying that i honestly don't  
>> see
>> there being a future in a Cocoon-based Forrest.

I have to admit that I am not sure about whole discussion about the  
future of forrest. We have a working product with a small committer  
community behind it. Our user base however is I guess larger then we  
imagine however we do not know them since forrest seems to just work.  
So no problems = no mails = no traffic.

Regarding the traffic on our commit lists is similar, we do not add  
any new functionality to forrest for a while now and more or less  
maintain the code we have with the feedback from the list and  
individual test cases.

>>
>>> D) Develop some other core.
>>>
>>> See past discussion in our dev mail archives.
>>
>> I think it's ultimately going to be this or the Attic.  Implementing
>> something that's intuitive, prefers convention, and doesn't attempt  
>> to
>> solve all problems could very well bring the fun back.  I think we'd
>> have a much easier time attracting new devs too since we wouldn't  
>> have
>> the problem of "yeah, forrest is easy to understand.... *after* you
>> understand this other ridiculously complex beast over there".

The fear that I have that we will replace one complex beast with  
another. However I agree that the shinny new thing phenomenon can  
attract new devs, the only question is whether our focus will attract  
them. What can forrest do for me that xyz cannot do? Does our  
framework of input, internal and output plugins can be slimed down to  
a jar that I can add to my standard project where I need SOME of the  
functionality but not all? In which programming language do we want to  
develop to start with? ....

>>
>>> E) Cease Forrest and move to the Apache Attic.
>>>
>>> http://attic.apache.org/
>>
>> I think there is a niche out there for Forrest.  I've got a need now,
>> for example, for a simple documentation site but, unfortunately,
>> forrest is too much of a burden to use for it - documentation is a
>> side-show that people don't want to have to spend hours/days "coming
>> up to speed".  So I sincerely hope this option isn't where we end up.

I do not see forrest in the attic neither. There are still quite a  
bunch of code in our rep that attracts people with certain usecase. We  
know that people are using our software, we still have people  
answering mails and moving forrest to the Attic seems to be to early.

>>
>>> ---oOo---
>>>
>>> Whatever happens, we still need to make a release.
>>
>> Agreed, I've been poking around at JIRA lately seeing what I can
>> tackle - as i mentioned the Cocoon (re)-learning curve has kept me
>> pretty unproductive though.

To be honest I have not tackle the release because seeing the process  
I feel overwhelmed of the steps involved. I saw other project  
releasing their software in a more straight forward manner.

I totally agree that we should release ASAP.

>>
>>> Whatever happens, more people need to assist with
>>> the project management tasks.
>>
>> Agreed, since I haven't contributed much lately to the coding, I
>> haven't been compelled to contribute at all.  That's not good, I  
>> know.
>>
>>> ---oOo---
>>>
>>> My opinion is that Forrest needs to make a decision
>>> about which direction, and stick with it, developers
>>> get involved to start Forrest moving again, and build
>>> the community.
>>>
>>> Options A to D have previous discussion in the
>>> dev mail archives.
>>
>> Again, I think D or E are the only viable long-term options.

Personally I would more go for cocoon3 (C) but that is my personal  
opinion.

salu2

>>
>> --tim

[rgardler]

2009/10/9 Thorsten Scherler <thorsten@...>:

>
> On 08/10/2009, at 21:07, Ross Gardler wrote:
>
>> I agree with Tim here, especially the bit where he can't agree with me
>> more ;-)
>>
>> I don't know a great deal about Cocoon 3, but I have no personal interest
>> in using it here - sledgehammer to crack a nut. Since I'm not active here my
>> opinion doesn't count for much in that respect though.
>
> I am still developing mostly with cocoon in different versions. Just a
> couple of days back I had a chance to use cocoon 3 within droids and I have
> to say it is not sledgehammer anymore. You can use it without any sitemap if
> you want. ...

When the work on Cocoon 3 started I was excited that many of the
concepts and ideas were what I was calling for in Forrest 2
(embeddability, simplicty, programmatic control etc.) I've not kept up
with it, if you have and you say it is not a sledgehammer then I'm
happy to listen.

>> On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:

...

> I have to admit that I am not sure about whole discussion about the future
> of forrest. We have a working product with a small committer community
> behind it. Our user base however is I guess larger then we imagine however
> we do not know them since forrest seems to just work. So no problems = no
> mails = no traffic.

I think this is true. Forrest is great for knocking together web
sites. If that's all you want then plain vanilla Forrest is great,
presents no problems and therefore no traffic.

> Regarding the traffic on our commit lists is similar, we do not add any new
> functionality to forrest for a while now and more or less maintain the code
> we have with the feedback from the list and individual test cases.

Here I disagree though.

Forrest was originally created as a way of combining content from
multiple sources in a single output format. However, the only well
supported output format is HTML, so if you want to create web pages
it's great. There are some well supported input formats, but most
users just use XDoc. Hence Forrest is used to create web pages and
nothing more.

At its height we had developers who needed the more advanced features
of merging data formats. However, we live in a different world today,
most data is available in some kind of syndicated feed that can be
passed through a simple XSL sheet and we're done. We don't need
complex pipelining anymore - if we do then there are a number of
simple GUI tools to provide them in a much simpler way than Forrest
does.

The world has moved on and the original vision of Forrest, IMHO, is no
longer relevant. It is for this reason that we are not seeing new
features - it is not feature complete with respect to the original
vision (where's version 1?)

> The fear that I have that we will replace one complex beast with another.

This is a legitimate fear.

If that's where this discussion took us then you can count me out.

> Does our framework of input, internal and
> output plugins can be slimed down to a jar that I can add to my standard
> project where I need SOME of the functionality but not all?

IMHO yes - see my weekend hacks on Forrest 2 - that's exactly what
this is (in proof of concept form). If we remove the complex
pipelining and focus on embeddable data translation I think there is
still a space for Forrest. Whilst some people might want the
pipelining features (to produce websites for example) this should not
be a part of core Forrest. I'd not object, in fact I proposed, that
Forrest translations should be embeddable in Cocoon to provide these
pipelining features. If we did it this way round we would remove the
dependency on Cocoon, thus allowing us to proceed independently of
that (or any other project).

> In which
> programming language do we want to develop to start with? ....

At this stage I don't care. I think that would be a diversion from the
important topic of whether it should be done at all.

> I do not see forrest in the attic neither. There are still quite a bunch of
> code in our rep that attracts people with certain usecase.

The attic is for code that is not being maintained. It does not mean
it has no users.  The fact that this conversation is happening shows
that there is some oversight, but how many of us have done anything
really useful for Forrest in the last 18 months? (not me)

Can those who have kept the project alive continue to do so? If so why
hasn't there been a release? I know I have grown tired of answering
questions for a project I no longer use in new projects and is not
under active development.

There have been two people in this thread say they think the right
route is X - so who is going to actually do it? If someone leads,
others may follow.

Ross


--
Ross Gardler

OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk

[David Crossley]

Thorsten Scherler wrote:
>
> IMO A should be the way to wrap up current development. Like pointed  
> out by David we need to have a release that  contains the work of the  
> last years since the release.

It may require two releases in reasonably quick succession.
Otherwise we risk holding up the release for more ages.

> To be honest I have not tackle the release because seeing the process  
> I feel overwhelmed of the steps involved. I saw other project  
> releasing their software in a more straight forward manner.

Do those projects also add their current documentation
as an integrated part of their release package, and provide
the means to generate that same version of the documentation?
This adds some complexity to Forrest's release process.
There are a number of Catch-22 situations and extra hoops.

The release process doc is reminders for me when/if
i was the RM. I wrote down every little step so that
it could be remembered from time-to-time and flow smoothly.
The last release was much easier with those notes.
It also intends to enable other people to assist
with certain parts of the process, so the whole
thing is explicitly defined. Many thanks to those people
that helped to evolve it.

Any committer is free to be RM and to create their
own release process, and to propose different content
for the release.

-David

[David Crossley]

What is "development" and "developer" in the context
of Forrest? IMO every person who creates a documentation
presentation system using Forrest is a developer.

IMO if the requirement is for a basic website,
then Forrest is not the correct tool.

On the other hand, if the content needs to be drawn from
various different places, and integrated, and perhaps some
specific content handled and presented in different ways.
Then Forrest is relevant.

One needs to be a developer to enhance the current set
of plugins or to create new, perhaps private, plugins.
For example i have an on-line store plugin for one of
our websites.

Configuring sitemaps and stuff requires a developer.
IMO the "sitemap" and "locationmap" are fantastic.

-David

[Johannes Schaefer-3]

Hello from a lurking user and committer!

I'm top-posting because I just want to add our use case to the
discussion which is different from producing a web site and maybe
closer to the original vision of Forrest.

I cannot join in the technical issues regarding cocoon and/or
implementation details.

We (as a company) use Forrest to publish big documents up to 1000 pages
like UI specs. We mainly deliver the static HTML output to developers.

Crucial features for us are
* (s)DocBook as input format, as limited as the sdocbook plugin may be
* Excel as input format, dito for the Excel plugin
* Small and distributed files that we put into svn (working as a team)
* Fast HTML preview, i.e. Forrest in live mode ('forrest run')
* PDF output, as limited as is; we need PDFs for archiving

One direct competitor is Café Solo (http://www.cafesolo.biz, in German).

There's much room for Forrest to improve, we always have some hassles
when a new project starts and a long wish list. We don't have the
resources to add substantially to Forrest beyond our internal hacks :-(

I'd love to contribute more but my (working) focus shifted away from
Forrest and as it is we manage to get along with it. Problems don't hit
the mailing lists since most of them we can resolve internally.

Best regards, cheers and all
Johannes

> -----Original Message-----
> From: ross.gardler@... [mailto:ross.gardler@...]
> On Behalf Of Ross Gardler
> Sent: Saturday, October 10, 2009 4:51 PM
> To: dev@...
> Subject: Re: [Important] Status and future direction
>
> 2009/10/9 Thorsten Scherler <thorsten@...>:
> >
> > On 08/10/2009, at 21:07, Ross Gardler wrote:
> >
> >> I agree with Tim here, especially the bit where he can't agree with
> me
> >> more ;-)
> >>
> >> I don't know a great deal about Cocoon 3, but I have no personal
> interest
> >> in using it here - sledgehammer to crack a nut. Since I'm not active
> here my
> >> opinion doesn't count for much in that respect though.
> >
> > I am still developing mostly with cocoon in different versions. Just
> a
> > couple of days back I had a chance to use cocoon 3 within droids and
> I have
> > to say it is not sledgehammer anymore. You can use it without any
> sitemap if
> > you want. ...
>
> When the work on Cocoon 3 started I was excited that many of the
> concepts and ideas were what I was calling for in Forrest 2
> (embeddability, simplicty, programmatic control etc.) I've not kept up
> with it, if you have and you say it is not a sledgehammer then I'm
> happy to listen.
>
> >> On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:
>
> ...
>
> > I have to admit that I am not sure about whole discussion about the
> future
> > of forrest. We have a working product with a small committer
> community
> > behind it. Our user base however is I guess larger then we imagine
> however
> > we do not know them since forrest seems to just work. So no problems
> = no
> > mails = no traffic.
>
> I think this is true. Forrest is great for knocking together web
> sites. If that's all you want then plain vanilla Forrest is great,
> presents no problems and therefore no traffic.
>
> > Regarding the traffic on our commit lists is similar, we do not add
> any new
> > functionality to forrest for a while now and more or less maintain
> the code
> > we have with the feedback from the list and individual test cases.
>
> Here I disagree though.
>
> Forrest was originally created as a way of combining content from
> multiple sources in a single output format. However, the only well
> supported output format is HTML, so if you want to create web pages
> it's great. There are some well supported input formats, but most
> users just use XDoc. Hence Forrest is used to create web pages and
> nothing more.
>
> At its height we had developers who needed the more advanced features
> of merging data formats. However, we live in a different world today,
> most data is available in some kind of syndicated feed that can be
> passed through a simple XSL sheet and we're done. We don't need
> complex pipelining anymore - if we do then there are a number of
> simple GUI tools to provide them in a much simpler way than Forrest
> does.
>
> The world has moved on and the original vision of Forrest, IMHO, is no
> longer relevant. It is for this reason that we are not seeing new
> features - it is not feature complete with respect to the original
> vision (where's version 1?)
>
> > The fear that I have that we will replace one complex beast with
> another.
>
> This is a legitimate fear.
>
> If that's where this discussion took us then you can count me out.
>
> > Does our framework of input, internal and
> > output plugins can be slimed down to a jar that I can add to my
> standard
> > project where I need SOME of the functionality but not all?
>
> IMHO yes - see my weekend hacks on Forrest 2 - that's exactly what
> this is (in proof of concept form). If we remove the complex
> pipelining and focus on embeddable data translation I think there is
> still a space for Forrest. Whilst some people might want the
> pipelining features (to produce websites for example) this should not
> be a part of core Forrest. I'd not object, in fact I proposed, that
> Forrest translations should be embeddable in Cocoon to provide these
> pipelining features. If we did it this way round we would remove the
> dependency on Cocoon, thus allowing us to proceed independently of
> that (or any other project).
>
> > In which
> > programming language do we want to develop to start with? ....
>
> At this stage I don't care. I think that would be a diversion from the
> important topic of whether it should be done at all.
>
> > I do not see forrest in the attic neither. There are still quite a
> bunch of
> > code in our rep that attracts people with certain usecase.
>
> The attic is for code that is not being maintained. It does not mean
> it has no users.  The fact that this conversation is happening shows
> that there is some oversight, but how many of us have done anything
> really useful for Forrest in the last 18 months? (not me)
>
> Can those who have kept the project alive continue to do so? If so why
> hasn't there been a release? I know I have grown tired of answering
> questions for a project I no longer use in new projects and is not
> under active development.
>
> There have been two people in this thread say they think the right
> route is X - so who is going to actually do it? If someone leads,
> others may follow.
>
> Ross
>
>
> --
> Ross Gardler
>
> OSS Watch - supporting open source in education and research
> http://www.oss-watch.ac.uk
>

--
i.A. Johannes Schaefer, Head Usability Ludwigsburg
User Interface Design GmbH, Ludwigsburg (Germany)
phone/fax  [phone] * mobile [phone]
e-mail johannes.schaefer@... * www.uid.com

Offices:
Martin-Luther-Straße 57-59 * 71636 Ludwigsburg
Hansastraße 7-11 * 44137 Dortmund
Friedrichsring 46 * 68161 Mannheim
Truderinger Strasse 330 * 81825 Muenchen

Legal information according to EHUG:
User Interface Design GmbH; Managing Directors: Dr. Claus Goerner,
Franz Koller; Head office: Ludwigsburg; Commercial register of the
local court of Stuttgart, Germany, HRB 205519

[rgardler]

2009/10/12 David Crossley <crossley@...>:
> What is "development" and "developer" in the context
> of Forrest? IMO every person who creates a documentation
> presentation system using Forrest is a developer.

A developer in the context of an open source project is someone who is
contributing to the ongoing sustainability of the project itself.
SOmeone who makes sure their own use of the tool is helping others.

> IMO if the requirement is for a basic website,
> then Forrest is not the correct tool.

Agreed - but that is what most users are using it for.

> On the other hand, if the content needs to be drawn from
> various different places, and integrated, and perhaps some
> specific content handled and presented in different ways.
> Then Forrest is relevant.

I disagree, Forrest *used* to be relevant. In my opinion it is too
hard to get anyting done these days. That's why I no longer use it in
new projects. It's easier to do per site systems now, at least it is
for me. You may have different views.

> One needs to be a developer to enhance the current set
> of plugins or to create new, perhaps private, plugins.
> For example i have an on-line store plugin for one of
> our websites.

Sure, but *you* have it. Why doesn't Forrest? That's the difference
between a user and a developer here. For Forrest to survive the people
who are still finding it useful need to step forward and move the
project onwards and stop relying on people like me who used to find it
useful but no longer do so.

> Configuring sitemaps and stuff requires a developer.
> IMO the "sitemap" and "locationmap" are fantastic.

I agree to an extend, that's why I spent so many thousands of hourse
working on those features (along with many others). Who is working on
it now?

Ross

[rgardler]

2009/10/12 Johannes Schaefer <Johannes.Schaefer@...>:
> Hello from a lurking user and committer!
>
> I'm top-posting because I just want to add our use case to the
> discussion which is different from producing a web site and maybe
> closer to the original vision of Forrest.

Thanks...

> There's much room for Forrest to improve, we always have some hassles
> when a new project starts and a long wish list. We don't have the
> resources to add substantially to Forrest beyond our internal hacks :-(

That, in my opinion is the problem. I find it easier to do internal
hacks of non-Forrest solutions than to work with Forrest now.
Technology has moved on since we started Forrest and Forrest has not
done so. We got bedded down chasing our own tales for a long time and
we never came out of it.

If Forrest was simpler and could be used as a library rather than as a
monolithic system I think we would have some realy developers rather
than real users.

If been involved with Forrest since day one, if even I find it easier
to hack around than to build decent reusable code then I think that is
a symptom of a problem. What I'm reading in this thread from those
other than the usual suspects is that the symptoms are seen elsewehere
too.

How do we solve that?

Ross

[rgardler]

2009/10/12 David Crossley <crossley@...>:
> Thorsten Scherler wrote:
>>
>> IMO A should be the way to wrap up current development. Like pointed
>> out by David we need to have a release that  contains the work of the
>> last years since the release.
>
> It may require two releases in reasonably quick succession.
> Otherwise we risk holding up the release for more ages.

Or even a release every 2-3 months regardless of the state of
development. I think one of our mistakes has been to wait for features
to be finished before releasing. Then they've been redesigned,
rejigged and broken.

Look at Locationmap - it took us three years to get that code in, once
in it was tidied up and polished. The XML config system was put into
the last release as an undocumented feature and, as a result has seen
significant work and is now ready for official release (yet there has
been no release).

It used to be just David doing releases. We discussed and agreed more
frequent releases. So I an Ferdinand cut a release. From memory I
think that was the last release Forrest had. All good intentions, but
no action.

> The last release was much easier with those notes.

+1000 - the process isn't actually that hard. It only looks complex
because it is well documented. Ironically, as David says, it is this
documentation that makes the process easier.

Ross

Ross


--
Ross Gardler

OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk

[Tim Williams]

On Sun, Oct 11, 2009 at 11:36 PM, David Crossley <crossley@...> wrote:
> What is "development" and "developer" in the context
> of Forrest? IMO every person who creates a documentation
> presentation system using Forrest is a developer.

A developer is someone that is responsible for setting up/configuring
an instance of Forrest.

A user is someone that contributes documentation to an instance of Forrest.

One of our problems is that Forrest currently requires some fairly
advanced knowledge to make some contribution to documentation.
Requiring an author to know some markup is reasonable.  Requiring an
author to know site.xml/tabs.xml/custom URI schemes/etc isn't
reasonable.

> IMO if the requirement is for a basic website,
> then Forrest is not the correct tool.

I've heard this before and think there are two problems here:

1) If true, our marketing is either wrong or IMO misleading "Forrest's
focus on low "startup cost" makes it ideal for rapid development of
small sites, where time and budget constraints do not allow
time-wasting HTML experiments."

2) This is where I believe we fall significantly short.  It seems to
me that a "basic website" is the simplest form of the problem forrest
should be able to solve.  It should solve this problem without
intervention, without configuration, it should be opinionated about
the best solution to the basic site and just work.  That it can solve
a more complex problem isn't an excuse for making it hard to solve the
basic problem.

> On the other hand, if the content needs to be drawn from
> various different places, and integrated, and perhaps some
> specific content handled and presented in different ways.
> Then Forrest is relevant.

This is true, and it's reasonable to expect some extra configuration
to solve such a case.  My point above is that we should handle the
'content on filesystem' case without any configuration - just drop the
files and it works.

> One needs to be a developer to enhance the current set
> of plugins or to create new, perhaps private, plugins.
> For example i have an on-line store plugin for one of
> our websites.

Fair enough...

> Configuring sitemaps and stuff requires a developer.
> IMO the "sitemap" and "locationmap" are fantastic.

I think the locationmap is "ok" and the sitemap, an abomination.  I
reckon I think Forrest should do for documentation what Rails does for
database-backed web-apps (or, roughly that anyway)

--tim

[David Crossley]

Ross Gardler wrote:
> David Crossley wrote:
> >
> > It may require two releases in reasonably quick succession.
> > Otherwise we risk holding up the release for more ages.
>
> Or even a release every 2-3 months regardless of the state of
> development. I think one of our mistakes has been to wait for features
> to be finished before releasing. Then they've been redesigned,
> rejigged and broken.

After the last release we suggested that that would
be best.

> Look at Locationmap - it took us three years to get that code in, once
> in it was tidied up and polished. The XML config system was put into
> the last release as an undocumented feature and, as a result has seen
> significant work and is now ready for official release (yet there has
> been no release).

There is a window of time here for someone to
document that and add default configuration
for the sample sites and plugins.

If not done, then we should just release as-is.

> It used to be just David doing releases. We discussed and agreed more
> frequent releases. So I an Ferdinand cut a release. From memory I
> think that was the last release Forrest had. All good intentions, but
> no action.

As i recall, that was just to build the Windows
archive for 0.7 release. For 0.8 the process was
changed (r522705) so that Ant enabled any RM to build
both UNIX and Windows packages. No-one complained
so i guess that it worked.

The whole process of being the Release Manager
and trying to galvanise other Forrest developers,
is where the main effort is required.

Anyway, fantastic to hear that you could readily
follow the necessary parts of the process.

> > The last release was much easier with those notes.
>
> +1000 - the process isn't actually that hard. It only looks complex
> because it is well documented. Ironically, as David says, it is this
> documentation that makes the process easier.

If it had not been written then it might appear
easier. We would likely need to cut various release
candidates because steps were forgotten.

I definitely agree that the process could be easier.
Last time i did not try to refine it, as we needed
to JFDI.

-David

[gavin-105]

> -----Original Message-----
> From: Ross Gardler [mailto:ross.gardler@...]
> Sent: Friday, 9 October 2009 5:08 AM
> To: dev@...
> Cc: dev@...
> Subject: Re: [Important] Status and future direction
>
> I agree with Tim here, especially the bit where he can't agree with me
> more ;-)
>
> I don't know a great deal about Cocoon 3, but I have no personal
> interest in using it here - sledgehammer to crack a nut. Since I'm not
> active here my opinion doesn't count for much in that respect though.
>
> If someone wanted to look at and validate my evening hacks on Forrest
> 2 I might be drawn back in, I do have a need for such a lightweight
> and embeddable solution. However, I don't have the time or resources
> to drive forward alone on this.

I seem to be in the same camp as Ross and Tim. When it comes to the Cocoon
side of things, even after all this time it is a maze [/haze] to me.

I would like to take a look at Forrest2 more before deciding if that could
be a possible future or not. A couple of questions on Forrest2

How usable is it right now?

Does it depend on our current core in any way or can the Forrest2 directory
tree be moved away and still work independently?

How far off do you think it is in terms of the tools that our current
Forrest offers? (can you drop an odt file in from our current plugin system
and get a tei output for example)

Either way, it looks like we should be voting soon on this, and the first
vote should probably be just about Cocoon, should it stay or go, more
decisions on the future of forrest can then have more focus after that
biggie has been decided.


---

Separately, but put here so I don't forget, whichever direction we go, I
would like to see: (edit: this list became larger than anticipated, feel
free to pull it into another thread if deemed appropriate.)

1. Easier plugin usage: for example, instead of referencing a plugin from a
configuration file by adding in 'org.apache.forrest.plugin.output.whatever'
, just drop the plugin into a predetermined directory and that's it, nothing
else.

2. Have far fewer configuration files altogether, merge them in, make them
longer if need be, have them in fewer places, make them easy to find.

3. As well as bundling jetty, bundle tomcat.

4. We should remove plugins altogether and have them as a separate
sub-project, hosted and documented away from the main forrest site. This
will make it easier for those that have not got a clue about how forrest
works and do not care. Don't make plugin devs think they need to know about
forrest/cocoon whatever. I think this is important and will expand the user
and developer base, and overall make forrest more appealing. Those that want
to work on and know about core forrest, its at forrest.apache.org, plugins
and anything else go elsewhere. (someone should just be able to download a
plugin creation tool, create their own plugin and drop it into the
plugins-enabled (or whatever) directory and see it working.)

5. Have a plugin repository manager, usable both from cmd line usage and
also from with a running forrest instance - examples of ease of use are
Hudson and Atlassian Confluence - they have a list of available plugins on
one page, with a install button, press it, job done. Again, the repository
manager and repository itself could be another sub project.

6. Possibly related to plugins, but also could easily be another
sub-project, that is the themes. People should be able to create a theme
easier than it is now (though I do like how it is now, it should be even
easier). Provide a theme builder wizard/tool/foo. choose from a
predetermined selection of layouts or have the ability to use a layout
designer. Also, choose from a variety of colour schemes ( that will work on
all layouts), or be able to edit the CSS directly. This is probably the most
far reaching of all my ideas here, but they are in use elsewhere, this is an
ease of use scenario but may be introducing a layer of complexity at the
developer level, but its here as a possible idea, that we could use some of
it.

7. Don't be afraid to create sub-projects to realise the above ideas. Folks
can narrow down their focus to what area they are interested in. They need
not be afraid of the mammoth that it is now. For those that like to work on
all things as they do now, nothing will stop them.

8. Maybe be a bit more ivy/maven (or even Ubuntu apt-get style) when it
comes to providing the dependencies we don't actually need to work on. There
is much stuff in our svn that we don't touch, so why have it there? - This
is absolutely something I think may stop putting off potential developers,
by making our svn footprint lighter and having a lot less to look at, will
make it less daunting for those looking at our code for the first time. From
a user perspective, there will be minimal impact, they need an internet
connection to download forrest, so once downloaded, running a build for the
first time that pulls the dependencies in wont be a bother.

Some of the above is about re-organisation more than anything, and is
probably equal in importance for me as choosing a new core to work on. It
should also therefore then attract differing types of developers/users.

I think I've said enough for now, except that maybe, I hope to find more
time for forrest soon, may interest has not dwindled, just that it has been
lower down the agenda for me with other stuff going on.

Gav...

>
> David, thank you for raising this issue.
>
> Sorry about top posting...
> Sent from my mobile device.
>
> On 8 Oct 2009, at 13:35, Tim Williams <williamstw@...> wrote:
>
> > Thanks David, this is a tough, but necessary, conversation.
> >
> > I snipped A and B because I don't consider them fruitful options at
> > all.
> >
> >> C) Try to upgrade to Cocoon-3 version.
> >> I don't know whether Cocoon-3 is ready or
> >> possible for Forrest. Would someone else comment.
> >
> > Cocoon-3 seems ready from what I can tell, though it is already
> > suffering from the same things that drove me away from enjoying
> > regular Cocoon.  It's overly complex.  There was a time when the
> > return on the steep Cocoon learning curve was worth it but that time,
> > for me, has passed.  I now have minimum amount of spare time to hack
> > at Forrest and when I've tried lately, it's no longer a pleasure
> > primarily because I spend much of that time re-learning Cocoon
> > complexity instead of being productive.  I must admit that when I was
> > at the height of my Cocoon knowledge I was unempathetic to Ross'
> > pleas, but now, I probably couldn't agree with his sentiments more.
> > Anyway, I think this is a long way of saying that i honestly don't see
> > there being a future in a Cocoon-based Forrest.
> >
> >> D) Develop some other core.
> >>
> >> See past discussion in our dev mail archives.
> >
> > I think it's ultimately going to be this or the Attic.  Implementing
> > something that's intuitive, prefers convention, and doesn't attempt to
> > solve all problems could very well bring the fun back.  I think we'd
> > have a much easier time attracting new devs too since we wouldn't have
> > the problem of "yeah, forrest is easy to understand.... *after* you
> > understand this other ridiculously complex beast over there".
> >
> >> E) Cease Forrest and move to the Apache Attic.
> >>
> >> http://attic.apache.org/
> >
> > I think there is a niche out there for Forrest.  I've got a need now,
> > for example, for a simple documentation site but, unfortunately,
> > forrest is too much of a burden to use for it - documentation is a
> > side-show that people don't want to have to spend hours/days "coming
> > up to speed".  So I sincerely hope this option isn't where we end up.
> >
> >> ---oOo---
> >>
> >> Whatever happens, we still need to make a release.
> >
> > Agreed, I've been poking around at JIRA lately seeing what I can
> > tackle - as i mentioned the Cocoon (re)-learning curve has kept me
> > pretty unproductive though.
> >
> >> Whatever happens, more people need to assist with
> >> the project management tasks.
> >
> > Agreed, since I haven't contributed much lately to the coding, I
> > haven't been compelled to contribute at all.  That's not good, I know.
> >
> >> ---oOo---
> >>
> >> My opinion is that Forrest needs to make a decision
> >> about which direction, and stick with it, developers
> >> get involved to start Forrest moving again, and build
> >> the community.
> >>
> >> Options A to D have previous discussion in the
> >> dev mail archives.
> >
> > Again, I think D or E are the only viable long-term options.
> >
> > --tim
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09
> 20:49:00

[rgardler]

2009/10/16 Gavin <gavin@...>:

>
>
>> -----Original Message-----
>> From: Ross Gardler [mailto:ross.gardler@...]
>> Sent: Friday, 9 October 2009 5:08 AM
>> To: dev@...
>> Cc: dev@...
>> Subject: Re: [Important] Status and future direction
>>
>> I agree with Tim here, especially the bit where he can't agree with me
>> more ;-)
>>
>> I don't know a great deal about Cocoon 3, but I have no personal
>> interest in using it here - sledgehammer to crack a nut. Since I'm not
>> active here my opinion doesn't count for much in that respect though.
>>
>> If someone wanted to look at and validate my evening hacks on Forrest
>> 2 I might be drawn back in, I do have a need for such a lightweight
>> and embeddable solution. However, I don't have the time or resources
>> to drive forward alone on this.
>
> I seem to be in the same camp as Ross and Tim. When it comes to the Cocoon
> side of things, even after all this time it is a maze [/haze] to me.
>
> I would like to take a look at Forrest2 more before deciding if that could
> be a possible future or not. A couple of questions on Forrest2
>
> How usable is it right now?

It isn't usable at all. I merely hacked together a very rough
prototype to illustrate what I was talking about. It works in a very
small number of test cases that are designed to demonstrate rather
than implement.

> Does it depend on our current core in any way or can the Forrest2 directory
> tree be moved away and still work independently?

It is fully independent.

> How far off do you think it is in terms of the tools that our current
> Forrest offers? (can you drop an odt file in from our current plugin system
> and get a tei output for example)

See above - it is a long way off. This is *not* the right route if
people are not fully supportive of the idea.

Ross

[David Crossley]

Gavin wrote:
>
> Either way, it looks like we should be voting soon on this, ...

I disagree. We need to hear from more people.
There are more Forrest PMC members, and there
are over 100 people subscribed to this dev list.

Also please give me a chance to contact the main
projects at ASF that have Forrest-based websites.
See the "assistance with Forrest" thread.

> ... and the first
> vote should probably be just about Cocoon, should it stay or go, more
> decisions on the future of forrest can then have more focus after that
> biggie has been decided.

I would rather consider the whole plan.

-David

[rgardler]

2009/10/16 David Crossley <crossley@...>:
> Gavin wrote:
>>
>> Either way, it looks like we should be voting soon on this, ...
>
> I disagree. We need to hear from more people.
> There are more Forrest PMC members, and there
> are over 100 people subscribed to this dev list.

Yes, there is no need to rush this. It's a very important decision to
make and we need to be sure to make the right one.

So far there have been two opposing views expressed, but I still see
nobody actually stepping up to do the work. Opinions (like mine) are
irrlevent unless they are followed through on.

Ross

[David Crossley]

Rather than try to find one specific direction at this stage, or
creating new wish lists, we need to find a definite way forward.
Let solutions evolve.

Here is one proposal.

*) Current trunk continues as-is, based on Cocoon-2.1

*) Create an SVN area for each group who want to try
to develop something new. A completely empty space for
each group of people to start from scratch.

*) Assign each a simple code name (so as not to descend
into naming wars or set false impressions about what will
be next), e.g. ForA, ForB, ForC.

*) Conduct all discussion on this dev list. Use labels
for each experiment, e.g. [ForB] my subject
So subjects having no label would relate to the general
current project.

*) Let each specific experiment evolve at its own pace.

*) When solutions approach being useful, vote to replace
the trunk codebase.

This also allows the people who currently use, and are
generally happy with Forrest, to continue.

It also lets us all put effort into the much needed release
and enables subsequent faster release cycles.

We have a good community and project infrastructure here.
Let us build upon it.

-David

[Brian M Dube-2]

On Sat, Oct 24, 2009 at 10:37:48AM +1100, David Crossley wrote:

> Rather than try to find one specific direction at this stage, or
> creating new wish lists, we need to find a definite way forward.
> Let solutions evolve.
>
> Here is one proposal.
>
> *) Current trunk continues as-is, based on Cocoon-2.1
>
> *) Create an SVN area for each group who want to try
> to develop something new. A completely empty space for
> each group of people to start from scratch.

One could say we already have that space in the whiteboard, but I've
never thought of it this way. It can't hurt to get some (more)
experiments going. Surely some ideas would show up in experiments
which prove useful in current Forrest, but it also doesn't hurt if
that's not the case.

> *) Assign each a simple code name (so as not to descend
> into naming wars or set false impressions about what will
> be next), e.g. ForA, ForB, ForC.

Yes, good idea. No need to get hung up on names at this stage.

I've joined the thread late, so now I'm no longer sure where the rest
of my comments should go. I'll just continue here.

I fall into the same group as several others in the thread. And that
is that my current needs have shifted from Forrest to something very
Forrest-like. Right now I need a full web application, not just
dynamic mode Forrest. But there is a need for Forrest's transformation
capabilities as part of the system. Making that all work together
should leave an interesting use case scenario to document, as well as
get me back up to speed.

Brian