> -----Original Message----- > From: Ross Gardler [mailto:ross.gard...@googlemail.com] > Sent: Friday, 9 October 2009 5:08 AM > To: dev@forrest.apache.org > Cc: dev@forrest.apache.org > 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 <william...@gmail.com> 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
