Tim Williams wrote:
I personally like a stable trunk -- builds and runs without
hoop-jumping.
I think it is critical to keep the hoops required to an absolute
minimum for two simple reasons:
- even well documented hoops take time each time I set up a new
instance of Forrest (ok, this
Ross Gardler wrote:
I hadn't thought of that, but it triggered another requirement in my
mind, which happens to provide a solution.
I might add the need for a simple minimum seed for people who want to
start a fresh site w/o having to move all our demo junk out of it
first
AND
perhaps some
Ross Gardler wrote:
Personally, I think the current state of views is good enough for Trunk
(if we address the fresh-site issue). I've started to use it for a new
project, that's what I usually use as my yardstick. Lets see what others
say.
Playing with the default implementation it looks
Ross Gardler wrote:
Why do I want to automate it? Because I'd like (meaning it is my itch)
to have the build target site do things like ask the user for the
project name and other config values. Thus the various config files that
the user needs to edit to get started are already customised
xml comments from html sources are no longer generated or are stripped
--
Key: FOR-555
URL: http://issues.apache.org/jira/browse/FOR-555
Project: Forrest
Type: Bug
Components: Core operations
David Crossley wrote:
Ferdinand Soethe wrote:
Ross Gardler wrote:
I hadn't thought of that, but it triggered another requirement in my
mind, which happens to provide a solution.
I might add the need for a simple minimum seed for people who want to
start a fresh site w/o having to move all
Ferdinand Soethe wrote:
Ross Gardler wrote:
Personally, I think the current state of views is good enough for Trunk
(if we address the fresh-site issue). I've started to use it for a new
project, that's what I usually use as my yardstick. Lets see what others
say.
Playing with the default
Ferdinand Soethe wrote:
Ross Gardler wrote:
Furthermore, in my work on versioned plugins for the 0.7 release I took
us nearly all the way to having plugins used from the plugins directory
if they are present there. That would remove the need for a download or
a local-deploy for people using
Tim Williams wrote:
Since this is about project process, hopefully by my opinions I'm not
violating some unspoken pmc-only line here...
We are a very open community. We do not discuss anything like this in
private. The only stuff that goes on in private is votes for new
committers and
Nicola Ken Barozzi wrote:
Tim Williams wrote:
This, however, is quite a committment. While I'm for a usable trunk,
extending that though to a releasable trunk is more committment than
I'd want. Maybe I'm reading too much into it but claiming that at any
given moment the trunk is [apache]
Nicola Ken Barozzi wrote:
Ross Gardler wrote:
...
Once we have an RC built we only allow bug fixes in trunk, new
features are developer in a branch.
I wouldn't be that strong. If I'm adding a new feature to the trunk, but
this does not interfere with prior behaviour, there are no
[ http://issues.apache.org/jira/browse/FOR-454?page=all ]
Ross Gardler closed FOR-454:
Resolution: Fixed
add content about major changes for this release
Key: FOR-454
URL:
Ross Gardler wrote:
So, I would like to welcome Anil Ramnanan to the Apache Forrest
community.
Thank you for the welcome. I look forward to working with Forrest and
the Forrest community. Just be warned that I will be asking many
questions. :)
Regards,
Anil Ramnanan
[
http://issues.apache.org/jira/browse/FOR-554?page=comments#action_12314534 ]
Tim Williams commented on FOR-554:
--
With further testing it seems that this patch causes a new problem. It's going
to take me some time to figure this one out I think. It
[
http://issues.apache.org/jira/browse/FOR-554?page=comments#action_12314536 ]
Ross Gardler commented on FOR-554:
--
I wonder if Cocoons error handlers can help in a more controllable way:
http://cocoon.apache.org/2.1/userdocs/concepts/errorhandling.html
Here are the current deliverables that I intend to produce for the
Summer of code project and the order in which I intend to do them. I was
wondering if there were any comments from the community on them. The
entire project proposal with details on each of the deliverables was
posted in Ross's
Anil Ramnanan wrote:
Here are the current deliverables that I intend to produce for the
Summer of code project and the order in which I intend to do them. I was
wondering if there were any comments from the community on them. The
entire project proposal with details on each of the deliverables
Hello devs
I am away from home and just had a glance over the latest discussion
about the merge. Instead of answering all the threads I just want to
state what I am thinking about merging views.
1) Views are and will be in the whiteboard! That means we can merge them
without a problem into what
Thorsten Scherler wrote:
On Thu, 2005-06-23 at 20:54 +0100, Ross Gardler wrote:
Tim Williams wrote:
On 6/23/05, Diwaker Gupta [EMAIL PROTECTED] wrote:
Now that the release is just around the corner (since the website is
already updated, I guess we're just waiting for the announcement,
Just some quick comments:
On Mon, 2005-06-27 at 10:08 -0400, Anil Ramnanan wrote:
Here are the current deliverables that I intend to produce for the
Summer of code project and the order in which I intend to do them. I was
wondering if there were any comments from the community on them. The
Thorsten Scherler wrote:
Do you want to create a wizard for views? Maybe another for contracts? I
would be more then happy to give you a hand on that.
That is my intention. I had originally planned a wizard for the skins
but Ross suggested that I focus on views instead.
Regards,
Anil
Anil Ramnanan wrote:
Thorsten Scherler wrote:
Do you want to create a wizard for views? Maybe another for contracts? I
would be more then happy to give you a hand on that.
That is my intention. I had originally planned a wizard for the skins
but Ross suggested that I focus on views
On Mon, 2005-06-27 at 11:22 -0400, Anil Ramnanan wrote:
Thorsten Scherler wrote:
Do you want to create a wizard for views? Maybe another for contracts? I
would be more then happy to give you a hand on that.
That is my intention. I had originally planned a wizard for the skins
but
Thorsten Scherler wrote:
Just some quick comments:
On Mon, 2005-06-27 at 10:08 -0400, Anil Ramnanan wrote:
Here are the current deliverables that I intend to produce for the
Summer of code project and the order in which I intend to do them. I was
wondering if there were any comments from the
Update Site for Forrest Plugin
--
Key: FOR-557
URL: http://issues.apache.org/jira/browse/FOR-557
Project: Forrest
Type: New Feature
Components: Tool: Eclipse config
Versions: 0.8-dev
Reporter: Anil Ramnanan
An Update
On Mon, 2005-06-27 at 16:00 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
Seriously, coming back to metadata:
I recommend to split the forrest:properties from the view. Ross was
never really comfortable with their existence in the view and I agreed
saying they are right now a
Thorsten Scherler wrote:
On Mon, 2005-06-27 at 16:00 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
...
The *.prop would contain the view specific extra content dispatcher
(nuggets) that are now stored in the view.
Sorry, I'm not familiar enough with views terminology yet. Can you
Without per directory we need three files for every page - bad.
I agree. If Forrest requires me to create 3 files for each page, I'm
going to be concerned.
With per directory config we need three files for each directory - good.
And of course, Forrest should always fall back to a default
Anil Ramnanan (JIRA) wrote:
[ http://issues.apache.org/jira/browse/FOR-557?page=all ]
Anil Ramnanan updated FOR-557:
--
Attachment: forrestplugin.updatesite.zip
Expand this file to the area on the web server where you want to create an
update site for the
[ http://issues.apache.org/jira/browse/FOR-558?page=all ]
Diwaker Gupta updated FOR-558:
--
Attachment: default.fv
skin update
---
Key: FOR-558
URL: http://issues.apache.org/jira/browse/FOR-558
Project: Forrest
[ http://issues.apache.org/jira/browse/FOR-559?page=all ]
Jeremias Maerki updated FOR-559:
Attachment: forrest-force-toc.diff
The proposed patch.
FAQ+TOC problem: force-toc option
-
Key: FOR-559
[ http://issues.apache.org/jira/browse/FOR-557?page=all ]
Anil Ramnanan updated FOR-557:
--
Attachment: org.apache.forrest.eclipse.updateSite.zip
org.apache.forrest.eclipse.feature.zip
Import both org.apache.forrest.eclipse.feature and
[
http://issues.apache.org/jira/browse/FOR-554?page=comments#action_12314560 ]
Tim Williams commented on FOR-554:
--
Only as a workaround, right? Or do you mean something else?
The problem has nothing (or at least very little) to do with locationmaps. It
Anil Ramnanan wrote:
Ross Gardler wrote:
So, I would like to welcome Anil Ramnanan to the Apache Forrest
community.
Thank you for the welcome. I look forward to working with Forrest and
the Forrest community. Just be warned that I will be asking many
questions. :)
That is exactly
Ross Gardler wrote:
[mentor hat on] Anil, this is a perfect example of why we must conduct
all design discussion on list rather than via private email. I cannot
possibly remember everything that is going on with Forrest. With just a
few words Thortsen could have saved us lots of wasted
Thorsten Scherler wrote:
Anil Ramnanan wrote:
July 6 - Editors of Site, Tabs, Locationmap and Skinconf
Hmm, actually I think the skinconf need discussion before you make a
wizard. IMO we need to use the proposed one from Nicola. I will prepare
a new thread for this.
Yes, my alarm bells
Thorsten Scherler wrote:
Hello devs
I am away from home and just had a glance over the latest discussion
about the merge. Instead of answering all the threads I just want to
state what I am thinking about merging views.
1) Views are and will be in the whiteboard! That means we can merge
On 6/27/05, David Crossley [EMAIL PROTECTED] wrote:
Thorsten Scherler wrote:
Anil Ramnanan wrote:
July 6 - Editors of Site, Tabs, Locationmap and Skinconf
Hmm, actually I think the skinconf need discussion before you make a
wizard. IMO we need to use the proposed one from Nicola. I
[ http://issues.apache.org/jira/browse/FOR-391?page=all ]
David Crossley closed FOR-391:
--
Fix Version: 0.8-dev
Resolution: Fixed
I have done some tweaks to the .htaccess.
Nobody is reporting any problems with the new website, so closing this
[ http://issues.apache.org/jira/browse/FOR-542?page=all ]
David Crossley closed FOR-542:
--
Resolution: Fixed
Done.
'build test' should run validate-config target
Key: FOR-542
URL:
40 matches
Mail list logo
