Re: [RT] A new Forrest implementation?
Sorry about that. My mail client should have changed it for me. I'll have to go tinker with that Hi folks, I haven't been active on the list for quite a while now but do still skim. I don't use Forrest anymore but still like the concept of it. Not to bore you but just for some context - My main interest in Forrest was that it did format transformations using XML stuff I could (mostly) understand. I am not a lifelong programmer - I'm new to the IT world in general about 4 years ago. I knew how to use email before then - that was about as technical as I got. Today I am mainly an XHTML, CSS developer with enough PHP to hack other people's code and get what I need. I mainly work with PHP-based CMS now but I would still love to have the transformation work that Forrest does. I can't comment on the framework suggestion from a technical point of view - Cocoon is just beyond me to even pretend to evaluate. But anything that smacks of a "simpler" Forrest catches my attention. I really did try to dig in deeper when I first came to Forrest but with my limited programming background it was just too much to hack through. Will changing the framework make it any easier for me? I don't know, but I know that trying to learn the external components that currently go into Forrest didn't work for me. I'll go back to the recesses of lurking again now. - Addi Ross Gardler wrote: Maurice Gittens wrote: Here's an opinion of a dev that has been lurking on this list for some time. Excellent, it's really important that we hear views from everyone with an interest. If we do something radical we have to be sure it is the right thing to do. I much appreciate the conceptual design of forrest where a single internal format is used as the target of input transformations and as the source of output transformations. Yes, I agree. This is something that must not change. In fact, if we make such a radical change on the underlying code then I'm sure we will also take the opportunity to move to XHTML2, something we've wanted to do for a long time. However I agree with Ross that there is much unneeded complexity involved in using Forrest relative to the functionality it provides. I currently choose not to debug problems I encounter in Forrest simply because this entails delving into too many seemingly overengineered components with not much relevance to the problem I am trying to solve. This is precisely what I thought was happening, although we can't assume you are typical, it would be great to hear from others. However, it is true that I have also grown tired of fighting to debug stuff in Forrest. One of the other advantages of moving to a more simple Java implementation is that we will gain the ability to write unit tests for each component and test it in isolation of the rest of the system. Luckily for me, the forrest devs usually quickly fix the problems so that I don't even have to report them. The fact remains however that I would have enjoyed giving something back. This is all to say that I would be happy to contribute to a cleaner implementation of Forrest. It's good to hear that you think such a move might help you become more involved in Forrest. If your case is typical then I'm certain that this would be a good move, but we need to hear from more people like you to help us decide what to do. Ross -- /Addi Berry/ 240-274-0875 [EMAIL PROTECTED] www.rocktreesky.com <http://www.rocktreesky.com> -- /Addi Berry/ 240-274-0875 [EMAIL PROTECTED] www.rocktreesky.com <http://www.rocktreesky.com>
Re: [RT] A new Forrest implementation?
Hi folks, I haven't been active on the list for quite a while now but do still skim. I don't use Forrest anymore but still like the concept of it. Not to bore you but just for some context - My main interest in Forrest was that it did format transformations using XML stuff I could (mostly) understand. I am not a lifelong programmer - I'm new to the IT world in general about 4 years ago. I knew how to use email before then - that was about as technical as I got. Today I am mainly an XHTML, CSS developer with enough PHP to hack other people's code and get what I need. I mainly work with PHP-based CMS now but I would still love to have the transformation work that Forrest does. I can't comment on the framework suggestion from a technical point of view - Cocoon is just beyond me to even pretend to evaluate. But anything that smacks of a "simpler" Forrest catches my attention. I really did try to dig in deeper when I first came to Forrest but with my limited programming background it was just too much to hack through. Will changing the framework make it any easier for me? I don't know, but I know that trying to learn the external components that currently go into Forrest didn't work for me. I'll go back to the recesses of lurking again now. - Addi Ross Gardler wrote: Maurice Gittens wrote: Here's an opinion of a dev that has been lurking on this list for some time. Excellent, it's really important that we hear views from everyone with an interest. If we do something radical we have to be sure it is the right thing to do. I much appreciate the conceptual design of forrest where a single internal format is used as the target of input transformations and as the source of output transformations. Yes, I agree. This is something that must not change. In fact, if we make such a radical change on the underlying code then I'm sure we will also take the opportunity to move to XHTML2, something we've wanted to do for a long time. However I agree with Ross that there is much unneeded complexity involved in using Forrest relative to the functionality it provides. I currently choose not to debug problems I encounter in Forrest simply because this entails delving into too many seemingly overengineered components with not much relevance to the problem I am trying to solve. This is precisely what I thought was happening, although we can't assume you are typical, it would be great to hear from others. However, it is true that I have also grown tired of fighting to debug stuff in Forrest. One of the other advantages of moving to a more simple Java implementation is that we will gain the ability to write unit tests for each component and test it in isolation of the rest of the system. Luckily for me, the forrest devs usually quickly fix the problems so that I don't even have to report them. The fact remains however that I would have enjoyed giving something back. This is all to say that I would be happy to contribute to a cleaner implementation of Forrest. It's good to hear that you think such a move might help you become more involved in Forrest. If your case is typical then I'm certain that this would be a good move, but we need to hear from more people like you to help us decide what to do. Ross -- Addi Berry 240-274-0875 [EMAIL PROTECTED] www.rocktreesky.com
Re: [jira] Closed: (FOR-837) ForrestBar 0.7 will not install on FF 1.5.0.1
The packaged 0.7 xpi that I attached to the JIRA issue worked. I have it installed on my 1.5.0.1 right now. I don't know where it went in the midst of all this but it was not as simple as changing the rdf file to the higher version number to get it working properly. I actually copied over the 0.8 files and removed the 0.8 stuff from it to get it working. I can't remember the details on removing a foobared extensions because it has been a long time since I had to, but there should be info at the Mozilla forums. - Addi Ferdinand Soethe wrote: >Ferdinand Soethe wrote: > > > >>Just updated svn and tried to installed the xpi but after starting the >>install it just never materializes as an installed extension. >>FB 0.8 works just fine. Any ideas? >> >> > >Update: Seems like version 0.7 and 0.8 have some serious conflict: > >After uninstalling version 0.8 I now have a forrestbar >(probably version 0.7) that does not show in the extensions list and >is otherwise pretty useless. And worse, the toolbar cannot be >disabled or uninstalled unless sbdy knows how to trick FF into >uninstalling something that is not in the extension list. > >-- >Ferdinand Soethe > > > > > > >
Gobby for Mac
Just FYI. We were looking at gobby for online collaboration a while back but a major block was the difficult Mac install. It is now available in DarwinPorts. Old threads re: collaborative editing: http://www.mail-archive.com/dev@forrest.apache.org/msg05424.html http://www.mail-archive.com/dev@forrest.apache.org/msg05311.html -- /Addi Berry/ 240-274-0875 www.rocktreesky.com <http://www.rocktreesky.com> Get Thunderbird <http://www.mozilla.org/products/thunderbird/>
Re: [jira] Created: (FOR-836) ForrestBar does not currently install in the latest FF 1.5.0.1
Gotcha. Well, the issue is still a issue for users who want to use the "regular" forrestbar because it will not install on the latest FF. So maybe we should update the regular one so that it will install and keep that as the downloadable xpi on the web page and then edit the page to say that anyone wanting the dev version should build it from SVN. I'll create a new issue in JIRA with patches for this. - Addi Ross Gardler wrote: > Addi wrote: > >> Hm, well I tried to install from the Forrest website >> (http://forrest.apache.org/tools/forrestbar.html) and it would not >> install. I did do a SVN up but didn't build it there because I figured >> the one on the site should be the same as what we have in SVN, no? Now >> that I have opened up the one on the site I see that it is not at >> 1.5+. Do we have two versions of it now - one for the site and one >> for SVN? > > > Yes, unfortunately some features have been added that are only useful > for users of 0.8-dev and therefore we can't release another version > without creating loads of confusion (unless we disable the 0.8-dev > features). > > Ross
Re: [jira] Created: (FOR-836) ForrestBar does not currently install in the latest FF 1.5.0.1
Hm, well I tried to install from the Forrest website (http://forrest.apache.org/tools/forrestbar.html) and it would not install. I did do a SVN up but didn't build it there because I figured the one on the site should be the same as what we have in SVN, no? Now that I have opened up the one on the site I see that it is not at 1.5+. Do we have two versions of it now - one for the site and one for SVN? Sorry for creating confusion as I haven't been around here for quite a few months and when I last used it we had just the one version. If there are indeed two versions now, then the forrestbar page needs to be updated to explain this (or remove the build info) since it has a downloadable xpi as well as build instructions with no indication that they are two different xpis. - Addi Cyriaque Dupoirieux wrote: > Rebuild the last version in svn, the maxversion of the toolbar is > already : >1.5+ > > > Salutations, > Cyriaque, > > le 17/03/2006 17:02 Addison Berry (JIRA) a écrit : > >> ForrestBar does not currently install in the latest FF 1.5.0.1 >> -- >> >> Key: FOR-836 >> URL: http://issues.apache.org/jira/browse/FOR-836 >> Project: Forrest >> Type: Improvement >> Components: Forrestbar Versions: 0.8-devReporter: >> Addison Berry >> Priority: Minor >> Attachments: forrestbar.xpi, install.rdf.diff >> >> Forrestbar's install file limits it to FF 1.5 so it won't install on >> FF 1.5.0.1. I've patched it so that it will install on FF versions >> up to 1.6. Diff and new xpi attached. >> >> > > > > >
Re: Problems installing FORREST on winXP machine
Hi Marijn, If you have FORREST HOME set properly (like this: C:\Documents and Settings\pp\Escritorio\apache-forrest-0.7), then you only need %FORREST_HOME%\bin in your PATH variable. So you should have: FORREST HOME = C:\Documents and Settings\pp\Escritorio\apache-forrest-0.7 PATH = all-of-your-other-path-stuff;%FORREST_HOME%\bin Let us know if that helps. Addi Marijn Somers wrote: > hi, > > we are trying to install APACHE FORREST on our winXP machine, but > somehow it doesn't start.. > > we downloaded the source v0.70 > - latest JAVA JRE is installed > - we made a new system variable called FORREST_HOME > path : C:\Documents and > Settings\pp\Escritorio\apache-forrest-0.7%FORREST_HOME%\bin > > when we type forrest -projecthelp in our cmd window it says it doens't > find the specified route.. > > any idees to what we do wrong ? > > greetings, > > Marijn Somers > > >
Re: Forrest Friday report
Thanks for the report and the work done by everyone. Sorry I couldn't show up - family emergency and a freelance deadline have taken all my time. - Addi Ross Gardler wrote: Forrest Friday was not as well attended as other Forrest Tuesdays. However, this meant we could gets lots done since there was less chatter. Things I noted of importance: - lots of work on the locationmap stuff - core is now fully utilising LM, and many of the plugins are doing so too (FOR-200 is nearly compelete) - Thorsten made a start on updating the views how-to stuff (hurrah, maybe I can catch up with all the great work by the views folk) - some tidying of the issue tracker I have a feeling that the next FF should be focussing only creating the 0.8 release Ross
Re: [off topic] irc client for windows? [was: Re: Forrest Friday for November (was Re: LaTeX output plugin)
I use Trillian (http://www.ceruleanstudios.com) when on my Windows comp. Totally free. Addi Gav wrote: mIRC is excellent and is what I use, free for 30 days I think then costs around $20 but continues on past 30 days anyway. http://mirc.com/ Gav... - Original Message - From: "Tim Williams" <[EMAIL PROTECTED]> To: Sent: Friday, November 11, 2005 12:48 PM Subject: [off topic] irc client for windows? [was: Re: Forrest Friday for November (was Re: LaTeX output plugin) |I usually participate by ssh'ing to my linux box and using xchat but | I'm on travel and don't have that capability. the windows version of | xchat apparently costs money. so, can someone recommend a good free | irc client for windows? I've got cygwin too but don't immediately see | an irc capability in there either. | | --tim | | On 11/10/05, David Crossley <[EMAIL PROTECTED]> wrote: | > 11 November starting at 06:00 Greenwich Mean Time. | > See the calendar for your time zone. | > | > We will use conventional IRC. The main communication | > medium is still the dev mailing list. | > | > The channel name is "for-n". | > | > The topic is to finish locationmap, clean up Jira, | > prioritise issues for next release, more xhtml2 dev. | > See below. | > | > So the start time is 2 hours away. | > | > -David | > | > Ross Gardler wrote: | > > Gav wrote: | > > >From: "Ross Gardler" | > > >| Ferdinand Soethe wrote: | > > >| > | > > >| > Does it make sense to base all transformations on XHTML2 (out soon to | > > >| > be meta-format) rather than document13? | > > >| | > > >| I would love to say yes, but then the danger is not actually getting the | > > >| move to XHTML2 done. We keep agreeing it should be done (for around 2 | > > >| years now), but we seem to be failing in actually tackling the job | > > >| because it is such a major task. | > > >| | > > >| At present I am thinking the only way it will ever happen is if we have | > > >| a complete rewrite of Forrest from the bottom up. | > > >| | > > >| Personally, I think the only way it is ever going to happen, with the | > > >| current method of working, is if an individual just does it. How long it | > > >| will be before one of us has that kind of time is anyones guess. | > > >| | > > >| Therefore, I (that is, me as an individual, this is not necessarily the | > > >| view of the community) would recommend using XDoc for fear of waiting | > > >| forever to make XHTML2 usable. | > > > | > > >Well, maybe this can be part of the discussion for Forrest Friday which | > > >happens | > > >to be THIS FRIDAY people, so whos going to make it for any amount of time | > > >and what should the topic of the day be. | > > > | > > >My opinion, keep on with http://issues.apache.org/jira/browse/FOR-184 | > > >issues and | > > >keep XHTML2 as the main focus along with the usual Jira cleanup. | > > > | > > >I will be there at various points in time. | > > | > > Thanks for bringing this up, sorry I've not been able to respond quicker | > > and help develop a plan for FF. | > > | > > I will present for some of the time. My own focus will be on finishing | > > off the locationmap stuff (FOR-200) which is a precursor to the views | > > integration which, in turn is a precursor to the XHTML2 move. | > > | > > I'll also be spending some time sorting out the issue tracker to | > > prioritise for a 0.8 release - maybe I'll even fix a couple of issues! | > > | > > It would be great if we can see the tasks in FOR-184 (XHTML2) fleshed | > > out by those who understand how the views 2 stuff impacts them. | > > | > > Ross | > | | | -- | This message was scanned for spam and viruses by BitDefender. | For more information please visit http://linux.bitdefender.com/ | | | | | -- | No virus found in this incoming message. | Checked by AVG Free Edition. | Version: 7.1.362 / Virus Database: 267.12.8/166 - Release Date: 10/11/2005 | |
Re: vague issues with Forrest use
Ross Gardler wrote: > Addi wrote: > >> Hm, well I don't know what resources the Apache projects are dealing >> with but I have not implemented Forrest at my work (other than for me >> to play with) because I am the only person who understands anything >> about XML. The biggest hurdles I see at my office are site.xml and >> the actual documents with deployment also being a secondary issue. >> They are hurdles because I can't be the only person who knows how to >> use it. It isn't efficient if I'm the only one who can add docs and >> do anything at all with it. Now that I have spent time with Forrest >> I know there are some tools to help me with those issues. So *for my >> use case situation* things that would make Forrest more viable: >> >> - A simple, intuitive way for non-XMLers to add things to site.xml > > > Have you any suggestions about what this may look like? No, unfortunately I haven't thought too hard on it and I have limited coding skills to even know what can be done. I just know that as soon as I try to explain to coworkers how I add things their eyes sort of glaze and they wander off to do something else. > > Have you taken a look at the Eclipse plugin? This is a (very early > development) of a GUI application for editing of things like site.xml. > It works, but is a long way from perfect. I have installed Eclipse but never seem to have time to play around with it or our plugins. We don't have any need for Eclipse so it doesn't fit into any other work I do. I'll try to make time to check it out. > > The biggest hurdle to its use is that it requires an Eclipse > installation, although it is possible to build a standalone > application for it. > >> - Emphasis and stupid clear instructions on document plugins >> (DocBook, OpenOffice) >> - Emphasis and stupid clear instructions on Forrestbot > > > > >> By stupid clear, I mean so that someone with little XML and Forrest >> experience can understand at least half of what you are saying and >> not be intimidated to at least try. > > > Yes, docs are important and are the hardest things to create. The > problem is that to write them you need to have the inclination to make > them "stupid clear", unfortunately most of the devs don't have such a > drive. > > All help is welcome, and newcomers to Forrest are in the best position > to write these stupid clear docs - with help and guidance from the > devs of course. > > Ross Well I do have an itch for stupid clear docs. I did submit the beginnings (mostly completed) of stupid clear docs for installing Forrest - FOR-699 (http://issues.apache.org/jira/browse/FOR-699). The way I envision documentation though is to actually have a cohesive, comprehensive manual. I know this has been talked about before on the list and we were looking at perhaps really hammering this out at ApacheCon in San Diego, but it looks like a documentathon may not really happen since not many will make it (I'm now leaning towards not being able to go either). So perhaps, for those of us who are interested, we should start discussing a larger plan for documentation and the creation of a new user "Intro to Forrest" that is basic and step-by-step. Of course this kind of project can be tricky since Forrest dev moves so quickly. Anyway, as we move closer to 1.0 release we do need to make the docs easier to use and understand for users who are brand new to the whole concept of what Forrest does and how. As for the two main things on docs I listed above, I still don't grasp Forrestbot well enough to feel like I could write the docs well. I can make it work but I don't have the time to really understand what exactly it is doing. If you look at the Forrestbot doc we have now, I put in lots of fix me's on things I don't get.
Re: vague issues with Forrest use
Hm, well I don't know what resources the Apache projects are dealing with but I have not implemented Forrest at my work (other than for me to play with) because I am the only person who understands anything about XML. The biggest hurdles I see at my office are site.xml and the actual documents with deployment also being a secondary issue. They are hurdles because I can't be the only person who knows how to use it. It isn't efficient if I'm the only one who can add docs and do anything at all with it. Now that I have spent time with Forrest I know there are some tools to help me with those issues. So *for my use case situation* things that would make Forrest more viable: - A simple, intuitive way for non-XMLers to add things to site.xml - Emphasis and stupid clear instructions on document plugins (DocBook, OpenOffice) - Emphasis and stupid clear instructions on Forrestbot By stupid clear, I mean so that someone with little XML and Forrest experience can understand at least half of what you are saying and not be intimidated to at least try. Anyway, those are my knee-jerk thoughts in response. Hope I'm not off-base of your point. - Addi David Crossley wrote: (Sorry, this got too long but i reckon it is important.) As you know, various people are using Forrest. For some see: http://forrest.apache.org/live-sites.html We can only presume they are well aware of what they are doing. They have chosen to use the pre-1.0 software. They will all have someone who knows how to run forrest, and knows to ask questions on the forrest user mailing list if they get stuck with upgrading, usage, installation, etc. However, i wonder if we are doing such a good job with making software that is usable now, even though it is a long way off being a 1.0 release, that some people/projects are getting themselves into hot water by depending on it before it is actually ready. We need to emphasise in our documentation, and in the release announcements, that this is pre-1.0 software. Yet still we can show that it is certainly usable for those who are prepared to move with it. We use it. I am particularly concerned about certain meta-projects at the Apache Software Foundation. For example, xml.apache.org and incubator.apache.org These places decided to use Forrest long ago, IIRC at 0.5 However, they do not now have people who understand how to use it, how to upgrade it, how to get around its quirks. Especially at Apache Incubator. The people are there to introduce new projects, new people, and to write and publish documentation. I don't quite know the history of Incubator, but i presume that people got excited about eating Apache dogfood and decided to go with Forrest. Perhaps the original proponents moved on. Now it seems that people are not happy with it, finding it cumbersome. I have heard some people say that they can't actually point to any particular thing. Mostly it is just silence and lack of use. Recently it was proposed that Forrest might be a solution at another part of ASF Infrastructure. That met with a lot of criticism, yet there was not a lot of concrete feedback. Over-dedicated volunteers like me and Ross, tend to go and help such places. However that is not sustainable. I don't know what to do about this. At the least i thought to send this mail because the Forrest PMC should be aware that there is something happening that could be damaging for our project. People are gumbling. We need to look at ways of making it more user-friendly. It is obviously not easy or the incubator.apache.org issues would not arise. Perhaps the problem is documentation for how to install and use forrest. These projects have a smattering of their own documentation for how to use it, but often it is poor and way out-of-date. Perhaps we need to write a document focussed on use of Forrest at Apache. Perhaps we need to actively go out and ask those Apache projects that use Forrest, what they see as the hindrance. It seems to me that people must be grumbling but not actually saying that they have issues or perhaps not being able to define the issues. -David
Re: Roadmap for v2 (was Re: [heads-up] JXPath upgraded )
Thorsten Scherler wrote: >El jue, 27-10-2005 a las 16:11 +0200, Cyriaque Dupoirieux escribió: >... > > >>Gav... if you have time, can you make a test with the css I recently >>updated. >>normally, default colors for pelt theme should be good without using the >>branding-theme-profiler contract... >> >>Cyriaque, >> >> > >Nice work again Cyriaque. :) I just finished what you have started. When >I creates the pelt.fv it was for http://lenya.apache.org/ and the colors >should always have been like that. Now they are, thx to your excellent >work. :) Still the round-corner issue remains. > >salu2 > > Sorry if this is stupid, I am just (this hour) beginning to play with the views stuff. A non-css v2 question: why are there two sets of different breadcrumbs? - Addi
Re: [jira] Commented: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
David Crossley wrote: >David Crossley wrote: > > >>Addi wrote: >> >> >>> Essentially what needs to happen is: >>>forrestbar/xpi/content needs to be renamed to forrestbar/xpi/chrome >>>forrestbar/xpi/content/forrestbar needs to be renamed >>>forrestbar/xpi/chrome/content >>> >>>I tried doing this a number of ways (svn move, svn copy, mkdir - svn >>>add) and it was just a mess each time. Unfortunately I am slammed at >>>work and won't be able to muck with this further until maybe Sunday so >>>if someone can change around the svn dirs, >>> >>> >>I was just about to suggest that i try to get the bits-and-pieces >>from you patch. >> >> >> >>>I will patch it on Sunday, as >>>well as make the changes David brought up in another post on the list. >>>Sorry that I'm sort of doing a "dump and run" on this. >>> >>> > >No problem. Sorry that it turned difficult for you. >It is bad when time is wasted and frustration mounts. > >Your notes above helped immensely. The problem >is the move (rename) of one directory inside another >moved directory. Needs to be two separate commits, >which you cannot. > >Thanks again. > >-David > Ah, OK, that makes sense. I wasn't sure how to do that and did it both ways (first move the top dir, then move the child dir and vice-versa) but the commit thing would be key there. So, I don't feel so stupid now. I will practice more with svn when I get chance so that I am more comfortable with it in the future. Thanks for taking care of it David. - Addi
Re: [Fwd: SynchroEdit is a browser-based simultaneous multiuser editor]
David Crossley wrote: >Good one. When shall we investigate? >This weekend, next? > >-David > > Yes this looks cool and I had come across it in my search but it is still only alpha and they only have a simple demo of it right now. We can't actually use it currently. I think it is still good to keep an eye on it and here is the link to their milestones which lays out where they are going: http://wiki.synchroedit.com/index.cgi?MileStones. That page says the Open Source release is scheduled for approximately Nov. 11. One thing to look at is the bottom where it lists things that are not currently in the milestones. Also, for those that do want to play with it, I found that clicking on the demo link from the home page doesn't work for me, but if you go to Certificate Page and then click on the demo link in there, it will work. - Addi >Ross Gardler wrote: > > >>This one works on Mac too... >> >> Original Message >>Date: Wed, 19 Oct 2005 22:08:05 -0400 >>From: Gregor J. Rothfuss <[EMAIL PROTECTED]> >>To: dev@lenya.apache.org >>Subject: SynchroEdit is a browser-based simultaneous multiuser editor >> >>http://synchroedit.com/ >> >>SynchroEdit is a browser-based simultaneous multiuser editor, a form of >>same-time, different-place groupware. It allows multiple users to edit a >>single web-based document at the same time, and it continuously >>synchronizes all changes so that users always have the same version. >> >>SynchroEdit's main editor is fully WYSIWYG, dynamically displaying >>bolds, italics, underlines, strikethroughs, with various justifications, >>indents and listing styles as an author inputs them. SynchroEdit also >>supports a simple, text-only editor for more basic documents. To clarify >>the multiuser experience, the editor window clearly depicts every user's >>changes in a specific color and also marks where each user is currently >>editing with a colored flag listing the user's name. >> >>It is our intent to release this under an Open Source license later this >>year. >> >>-- >> >> > > > > > >
Re: [EMAIL PROTECTED]: Project forrest-forrestbar (in module forrest) failed
ForrestBar is still missing a few files. Now that David has changed the dirs for me, I will create a patch that rights all of the files in a few hours. Getting ready for work now... - Addi Gump wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project forrest-forrestbar has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 463 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - forrest-forrestbar : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://vmgump.apache.org/gump/public/forrest/forrest-forrestbar/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/forrest/forrest-forrestbar/gump_work/build_forrest_forrest-forrestbar.html Work Name: build_forrest_forrest-forrestbar (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=20102005 forrestbar [Working Directory: /usr/local/gump/public/workspace/forrest/tools/forrestbar] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar - Buildfile: build.xml init: forrestbar: [mkdir] Created dir: /x1/gump/public/workspace/forrest/tools/forrestbar/build [mkdir] Created dir: /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar [mkdir] Created dir: /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar/chrome [mkdir] Created dir: /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar-jar [copy] Copying 25 files to /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar-jar [jar] Building jar: /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar/chrome/forrestbar.jar [copy] Copying 1 file to /x1/gump/public/workspace/forrest/tools/forrestbar/build/work/forrestbar BUILD FAILED /x1/gump/public/workspace/forrest/tools/forrestbar/build.xml:47: Warning: Could not find file /x1/gump/public/workspace/forrest/tools/forrestbar/xpi/install.rdf to copy. Total time: 0 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/forrest/forrest-forrestbar/rss.xml - Atom: http://vmgump.apache.org/gump/public/forrest/forrest-forrestbar/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2120102005, vmgump.apache.org:vmgump-public:2120102005 Gump E-mail Identifier (unique within run) #3. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
Re: Managing the Forrestbar (Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9)
Addi wrote: > Ross Gardler wrote: > >> Addi wrote: >> >>> David Crossley wrote: >>> >>>> Addi wrote: >>> >>> >> >> ... >> >>>>> I am also looking at getting ForrestBar on the >>>>> official Mozilla extensions site so that updates will be automatic >>>>> for >>>>> users. Is there any problem with this that I'm not aware of? >>>>> >>>> >>>> >>>> >>>> >>>> I don't know anything about it so cannot say. >>>> Is there a URL that explains what is involved? >>>> >>>> >>> Well, I haven't found tons of detailed info. Here is the link from >>> Mozilla Update - https://addons.mozilla.org/developers/ >>> The basic idea is that you can get an account and upload and >>> maintain an extension at the Mozilla Update site. >> >> >> >> Can you release under the Apache license on the Mozilla update site? >> >> Ross > > > As far as I can tell you can release under any license you want. When > I was looking at various extensions to help me figure out what I > needed to do, I saw a range of licenses in the code. I will double > check with the site though. > > - Addi Here is what I found on their wiki: http://wiki.mozilla.org/Update:Requirements/LegalAndReview Pertinent part: 1. All hosted software must be in an acceptable source format. It does not have to be open source, but code must be licensed such that it can be viewed and read by both mozilla.org staff and potential end-users.
Re: Managing the Forrestbar (Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9)
Ross Gardler wrote: Addi wrote: David Crossley wrote: Addi wrote: ... I am also looking at getting ForrestBar on the official Mozilla extensions site so that updates will be automatic for users. Is there any problem with this that I'm not aware of? I don't know anything about it so cannot say. Is there a URL that explains what is involved? Well, I haven't found tons of detailed info. Here is the link from Mozilla Update - https://addons.mozilla.org/developers/ The basic idea is that you can get an account and upload and maintain an extension at the Mozilla Update site. Can you release under the Apache license on the Mozilla update site? Ross As far as I can tell you can release under any license you want. When I was looking at various extensions to help me figure out what I needed to do, I saw a range of licenses in the code. I will double check with the site though. - Addi
Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
David Crossley wrote: Addi wrote: Also, in this patch I "versioned" the ForrestBar extension to version 0.7. I was thinking that we could match the ForrestBar version to the current version of Forrest. I have two reasons for this thinking: 1) I have a link in the toolbar that links to Current Docs so the ForrestBar version number will tell you which version of the Docs it is pointing to and this would lead to 2) every release of Forrest we should revisit ForrestBar to update the Docs link but also to verify continuing compatibility with browsers so we don't let it fall behind again. Does this seem reasonable? Yes. We need to add a note to etc/RELEASE_PROCESS.txt The version number needs to be incremented as part of the lead-up to release. I don't know how to ensure that we update it for each release. Perhaps add an ongoing Jira issue for it. I can do these later this weekend if noone else has by then. I am also looking at getting ForrestBar on the official Mozilla extensions site so that updates will be automatic for users. Is there any problem with this that I'm not aware of? I don't know anything about it so cannot say. Is there a URL that explains what is involved? Well, I haven't found tons of detailed info. Here is the link from Mozilla Update - https://addons.mozilla.org/developers/ The basic idea is that you can get an account and upload and maintain an extension at the Mozilla Update site. Firefox will look for updates to extensions there, so if we make changes to our extension and then upload it, users just need to let Firefox update it for them. One thing I am not sure of, is that your account login is your email address (and this is where the account confirmation email is sent) so I would need to know what email we would use if we do it. I'll see if I can get more substantive info on how it all really works. I am also continuing to play with it to try and get it to work in Netscape 8. I tried to put stuff that I thought would be most useful to us but if something needs to be added, it is really simple to do by looking at the chrome/content/forrestbarOverlay.xul file (or just ask on the list and I'll add it). Thanks for giving it some attention. Our Zone could be added to the Forrest section. forrest.zones.apache.org The Forrest/JIRA link would be better to go via our http://forrest.apache.org/issues.html We will gradually enhance this page to lead them into JIRA and provide ready-to-go searches etc. The References section is a good idea for some high-level references. The Cocoon links will change soon as they re-arrange their documentation. At some stage the Projects/Browse All CVS will be removed. All projects will be migrated to SVN by 2006-01-01 The Projects section could also link to http://www.apache.org/foundation/projects.html Will tweak your suggestions this weekend. The projects all listed out is pretty much the same as it was in the original, just with some corrected links. If we just have a link to the apache projects page rather than actually listing them in the bar (which I'm fine with) I guess it would make sense to get rid of Projects from the bar and just move that to be a link under Apache. - Addi More below ... Addison Berry (JIRA) wrote: [ http://issues.apache.org/jira/browse/FOR-180?page=all ] Addison Berry updated FOR-180: -- Attachment: forrestbar.diff forrestbar.xpi forrestbar.xml.diff This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. The .xpi file attached is the one built running the forrestbar target. I'm not sure how we get the .xpi file that is on the web site - if it is built or just put on the server in it's final form - so I included it here. It is manually generated after any occasional change. It gets added to our "site-author" tree. Everything that is generated from there gets onto the server, e.g. mirrors.cgi and .htaccess site-author/content/xdocs/tools/forrestbar.xpi I just updated the website for forrestbar.html and forrestbar.xpi -David
Re: [jira] Commented: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
David Crossley (JIRA) wrote: [ http://issues.apache.org/jira/browse/FOR-180?page=comments#action_12332314 ] David Crossley commented on FOR-180: Thanks Addi. The new forrestbar.xpi works for me, and the doc patch is fine. However the forrestbar.diff patch fails. It seems that you moved some files. You need to use 'svn move' for that. Similarly if any files were copied, use 'svn copy'. If you need any help with that then ask on the list. If you have moved and altered some files, then move your copy of the file out of the way, do the 'svn move', then replace it with your saved copy. The other way would be to provide a list of what has been moved and i can do the 'svn move' at this end, then you can patch them. Well, I appear to be SVN-challenged. I spent more time than I'd like to admit to trying to do this properly but it just isn't giving me a usable patch. Essentially what needs to happen is: forrestbar/xpi/content needs to be renamed to forrestbar/xpi/chrome forrestbar/xpi/content/forrestbar needs to be renamed forrestbar/xpi/chrome/content I tried doing this a number of ways (svn move, svn copy, mkdir - svn add) and it was just a mess each time. Unfortunately I am slammed at work and won't be able to muck with this further until maybe Sunday so if someone can change around the svn dirs, I will patch it on Sunday, as well as make the changes David brought up in another post on the list. Sorry that I'm sort of doing a "dump and run" on this. - Addi
Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
Also, in this patch I "versioned" the ForrestBar extension to version 0.7. I was thinking that we could match the ForrestBar version to the current version of Forrest. I have two reasons for this thinking: 1) I have a link in the toolbar that links to Current Docs so the ForrestBar version number will tell you which version of the Docs it is pointing to and this would lead to 2) every release of Forrest we should revisit ForrestBar to update the Docs link but also to verify continuing compatibility with browsers so we don't let it fall behind again. Does this seem reasonable? I am also looking at getting ForrestBar on the official Mozilla extensions site so that updates will be automatic for users. Is there any problem with this that I'm not aware of? I am also continuing to play with it to try and get it to work in Netscape 8. I tried to put stuff that I thought would be most useful to us but if something needs to be added, it is really simple to do by looking at the chrome/content/forrestbarOverlay.xul file (or just ask on the list and I'll add it). - Addi Addison Berry (JIRA) wrote: > [ http://issues.apache.org/jira/browse/FOR-180?page=all ] > >Addison Berry updated FOR-180: >-- > >Attachment: forrestbar.diff >forrestbar.xpi >forrestbar.xml.diff > >This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. >The .xpi file attached is the one built running the forrestbar target. I'm >not sure how we get the .xpi file that is on the web site - if it is built or >just put on the server in it's final form - so I included it here. > > >
Re: Changing the Day of Forrest Tuesday?
David Crossley wrote: Well it seems that Friday is the decision. Now to decide which Friday. Cocoon don't seem to do theirs anymore. Pity. Anyway if it ever revives then it would be first Friday. So i suggest that we have ours on the second Friday of each month. Any objections or better ideas? -David Works for me. - Addi
ForrestBar questions
I was poking around the Forrest site looking at the tools section and saw ForrestBar does not work with newer versions of Firefox. Since I have always been a little curious about how extensions work I figured I would update it. I have created a new extension that works in Firefox 1.0.x and the upcoming 1.5 releases. Now I have two questions/issues: 1. The links currently on the website for "install" and "download" of the current forrestbar do not work for me. The javascript install link [] just opens a new window with the word false on it and the download link that references the .xpi file [] just opens garbage on the screen and does not download. I was finally successful by right-clicking the download link, doing Save As... and then either dragging the file for Mozilla or doing Open File for Firefox. I am rewriting the site-author page for ForrestBar in light of the new versions but I am not sure how to supply download links that actually work properly by clicking on them. Of course, I can write out the directions that I did but there must be a better, more correct way. Maybe it is something with the install.js script in the xpi? I dunno much about it, so any answers or ideas are welcome. Otherwise I will just keep researching. 2. I actually have 2 versions of the toolbar now - the original (in both Moz and FF now, with bad links removed) and I also made a brand new version for me that consolidated a lot of the Apache stuff, added more Forrest stuff (Docs, JIRA, our mail list, our SVN), more reference manuals (SVN, Cocoon) and made the search bar search within the dev mail archive rather than just a generic google search (which I am already lovin'). Should I put both the original and new up or just the new? Any other feedback/concerns? Addi
Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)
On Friday October 07 2005 3:06 am, Ferdinand Soethe wrote: > Ross Gardler wrote: > > One of our community has raised a concern, > > we have to address it. In this case I feel the call is yours as to > > whether the changes stay or not (others will speak up if they have an > > opinion). > > Yes 'others' please do! Just piping up to say that I definitely agree that this is a fix that needs to be addressed. I think an explanation in the upgrade docs will suffice. - Addi > > Problem is the interpretation of bugs and features here and I really > think community should clarify this once and for all. > > For better understanding: > > 1. The old behavior will overwrite any class-attributes in >table-elements (of any type of document) with class="ForrestTable" >and also set borders= and other presentational attributes right in the >html-code. > >My view is that this is broken functionality because > >- it makes it impossible to custom format a table with a custom > class-attribute and css (a documented feature). > >- it goes against our concept of using css as much as possible. > >In fact, a final solution should go even one step further and >replace all presentational attributes in table with css-styling >in the stylesheet. > >In summary: I consider the changes to be fixes. > > 2. Any change in existing behavior has the potential to break >somebody's Forrest even if it is just fixing a bug. > >For example: If somebody tried using their own class-attributes for >table (which had no effect because it was swallowed) they will now >find their custom class tables to have no borders and no more >padding and will have to add extra-css to get them back. > >(Pls. note that non-customized tables (without class-attributes) will >continue to work as before!) > >I figured that this would be considered to be an improvement >because people who added class="xyz" in the first place likely did >so to customize design, but who knows ... > > 3. While I accept the general policy of maintaining backward >compatibility, I think this should be limited to documented features >and should always consider what is involved in achieving that goal. > >We should _not_ end up creating super complex stylesheets or >bazillions of configuration options to ensure backward >compatibility for bugs or leftovers from previous re-factoring >steps (in this case moving from a non-css to a css-based design). > >Especially if all that is required on upgrading would be a piece of >css added to the extra-css in ones project. (A step which I agree >should be documented in the upgrade info). > > wdyt? > > > -- > Ferdinand Soethe
Changing the Day of Forrest Tuesday?
I know this has been discussed before and I wanted to raise the topic again now, so we have time to discuss and decide before next month. I have great difficulty partaking on a weekday because I cannot access IRC from within my DCN at work which means I have to hop off to an outside wireless to join, but then I can't work effectively. I normally have a few hours in the evening, but if something comes up - either working late or home matters, like last night, then my only window is gone. Personally, weekends would work much better for me since I am a lot more flexible then - even Fridays because then I can burn the midnight oil and know it won't burn me the next day. I know that for others though, workdays are more flexible and personal life space is harder to manage, so I know there is no perfect solution. Anyway, just reviving it for discussion so we can determine whether or not the community wants to move FT to another day of the week. - Addi
Re: Forrest Tuesday on 4 October
For those interested, the running log is at http://casa.che-che.com/~bot/forrest/forrest.log.04Oct2005 David Crossley wrote: >http://forrest.apache.org/forrest-tuesday.html >4 October starting at 06:00 Greenwich Mean Time. >See the calendar for your time zone. > >We will use conventional IRC. The main communication >medium is still the dev mailing list. > >The channel name is "for-oct". > >-David >
Re: collaborative editing tools (Was: svn commit: r293179)
On Monday October 03 2005 3:51 pm, Ross Gardler wrote: > [EMAIL PROTECTED] wrote: > > Quoting David Crossley <[EMAIL PROTECTED]>: > >> Ross Gardler wrote: > >>> David Crossley wrote: > >>> >We should also explore other tools. I got a bit worried > >>> >that we rushed to a certain software. > >> > > >> >A quick Google found me this for example ... > >> >http://www.inkscape.org/ > > ... > > > I have Inkscape .42 and it is a great little SVG program but as far as I > > can > > tell, you can't use it to edit the kind of text files we are working > > with - at > > least I can't open a .xml file in it. If I'm wrong about that, Inkboard > > will > > be in .43 which is in hard freeze and due to be released soon. Again > > though, > > the demo only showed WYSIWYG editing of SVG files. > > Yes, that is the mistake I made. I'm an Inkscape user and didn't realise > that David had found a reference saying that they planned to add > collaborative editing. I'm still to check this out. Yes, that is the Inkboard I refered to, but it is a collaborative GUI *SVG* editor from what I can see so far. I haven't found anything about additional text editing capabilities in any of the documentation or mail lists. As far as I know Inkscape only allows editing of SVG files, so unless it is an additional feature of the Inkboard code I don't think we will be able to open and work with regular xml files in it. > > Inkscape is a cool tool, collaborative editing with it would be killer. I agree and this is definitely something to keep an eye on but I don't think it is going to be a code editor like we need. Also, for those who are interested the Inkboard component uses Jabber for the sessions so you will need a Jabber account to use it. - Addi > > [For those interested, Cocoon is having a similar discussion for use at > the forthcoming GetTogether] > > Ross
Re: collaborative editing tools (Was: svn commit: r293179)
Quoting David Crossley <[EMAIL PROTECTED]>: Ross Gardler wrote: David Crossley wrote: > >We should also explore other tools. I got a bit worried >that we rushed to a certain software. >A quick Google found me this for example ... >http://www.inkscape.org/ ... snip ... I agree we should examine alternatives, but the only one in this list that is an alternative is SubEthaEdit, unfortunately that is Mac only (is it not?). Gobby is cross platform, although too dificult to install on Mac at this time (work in progress). As i was suggesting, my quick search revealed one possibility. There must be more. -David I did some more poking around re: David's concerns and really didn't come up with much. From my searches I came across a few free collaborative editors (oxyd, DocSynch, Yarrr) that were in very early development (pre-alpha or planning) or were plugins/extensions to other programs. Besides Gobby the only other one I found that is free, stand-alone and currently usable is MoonEdit but it only has Linux, FreeBSD and Win versions with no mention of Mac at all. Besides stand-alone there is also the option of web-based, but all the ones I came across were designed for editing html pages in a gui and none with real code editing in mind. (JotSpot Live, Writely) I have Inkscape .42 and it is a great little SVG program but as far as I can tell, you can't use it to edit the kind of text files we are working with - at least I can't open a .xml file in it. If I'm wrong about that, Inkboard will be in .43 which is in hard freeze and due to be released soon. Again though, the demo only showed WYSIWYG editing of SVG files. So, after spending a goodly amount of time wandering around, Gobby is the most referenced and, I think, still at the top of our list. Hopefully they will complete the ports for Mac soon. - Addi
Re: Collaborative editing with Gobby
On Saturday October 01 2005 12:38 pm, Gav wrote: > - Original Message - > From: "Ross Gardler" <[EMAIL PROTECTED]> ... snip ... > | I really like this. Perhaps we can use Gobby instead of IRC for future > | Forrest Tuesdays. The problem I have with the last two Forrest Tuesdays > | is that nobody has the time to write up the IRC logs and reading them > | after the event is not all that helpful - too difficult to follow. > | > | I notice that Gobby has an IRC like chat client built in. Given Sjur's > | experiences above I'd like to run a test session with a couple of > | people. Just 10-20 minutes playing with it to see if we can use it for > | Forrest Tusedays. > | > | If we can get just three people to drop in at the same time that owuld > | be great. So we are not wasting our time we could use the session to > | write a How-To on doing collaborative meetings. Please raise your hand > | if you will attend (meeting time being suitable of course). > | > | Ross > > I have Gobby installed successfully on my Win System and can either host > or join the session, if it happens. > > Looks a great tool. > > Gav... I have it installed on Ubuntu and WinXP and should be around now for sessions. I'm pretty flexible with times. - Addi
Re: Proposal: interactive planning session for views/xhtml2/internals
Thorsten Scherler wrote: On Wed, 2005-09-14 at 06:34 -0400, addi wrote: On Wednesday September 14 2005 4:17 am, David Crossley wrote: Thorsten Scherler wrote: Any from this times. We just to state *when*. That is why i needed to start asking people specifically. The lack of reply seemed that there was no interest. Okay so lets try a different approach. The design session will be by IRC and it will be on Sunday 18 September starting at 20:00 UTC for between one and two hours. I will be on a plane to Texas at that time but I'm not a player, just a spectator right now so as long as it is logged, I'll read it later. If anyone has a problem then please suggest another time. Till now only two stated that there can at this time. Can you follow David hint and suggest a time that suit you better. I would like to see/hear your feedback. ;-) You are already playing with us that makes you a player. ;-) salu2 Well, times I'm available would be Saturday 17th from about 10:00 - 23:00 UTC or Sunday 18th from 10:00 - 17:00 UTC.
Re: Proposal: interactive planning session for views/xhtml2/internals
On Wednesday September 14 2005 4:17 am, David Crossley wrote: > Thorsten Scherler wrote: > > Any from this times. We just to state *when*. > > That is why i needed to start asking people specifically. > The lack of reply seemed that there was no interest. > > Okay so lets try a different approach. > > The design session will be by IRC and it will be > on Sunday 18 September starting at 20:00 UTC > for between one and two hours. > I will be on a plane to Texas at that time but I'm not a player, just a spectator right now so as long as it is logged, I'll read it later. > If anyone has a problem then please suggest > another time. > > The next thing is that we need to decide > what we want to achieve from the meeting. > > -David
Re: [RT] Split cocoon from forrest
On Tuesday September 13 2005 8:53 pm, Thorsten Scherler wrote: > Hi all, > > the update try experience made me think why are we not splitting cocoon > apart from forrest. > > I mean you would need them both to make forrest running. That would > overcome the whole procedure. We can set certain revision numbers of > cocoon-2.2 till it is not released. Kind of we having in lenya. > > Any thoughts? Hm, well, coming from a user perspective I think that is a big step. The more pieces someone has to track down and check off, the less likely they are to experiment. Generally if I am looking for a solution and I come across one that has a list of things I need, I will keep looking and see if I can find one that doesn't have as many pieces, especially if I am looking at deadlines. Not only is there the tracking down and installing but what if a prerequiste doesn't install right? Even if it is my mistake with a typo or something, it stalls the whole thing. The more pieces, the more points of potential issues. I know that currently Forrest is in dev and rough and you need to sort of know something to use it really so installing cocoon is no big deal to most us, but I guess the question is what is the long-term goal in terms low-barrier entry for an average puter user? I don't mean that as a rhetorical question either, because if the idea is that it will mainly be used by computer proficient people rather than "just someone who would like a cool app to make a web site", then that really sort weighs in here in my opinion. Cocoon is not geared toward the average puter user They have a lot of documentation (which is great) but in their install instructions it says things like "Your mileage may vary, but you know how to setup environments, right?" while Forrest strongly promotes on the front page: " Forrest is designed with the new user in mind. Much effort has gone into making the process of generating a new site easy and simple." So anyway I am -1 on the idea but I am also honestly curious about the community's concept of the future target user of Forrest. And if I'm off the mark or misunderstanding the intent, please let me know. Addi
Re: ApacheCon US 2005 Documentathon (was Re: [FT] 2005-09-06 Summary)
On Sunday September 11 2005 4:03 am, Ferdinand Soethe wrote: > Time to move this to it's own thread with a distracting title (or > we'll get too many people interested in trying that ale :-) Yeah, I thought right after I sent my last one that I shoulda changed the subject first... > > addi wrote: > > On Saturday September 10 2005 5:07 am, Ferdinand Soethe wrote: > >> >> But I should warn you, so you're not shocked if you meet me, I'm > >> >> actually a she. :) > >> > >> I think we are getting a little distracted from the real issues here: > >> DO you brew good beer of don't you? And will you bring some to SD? > > > > Yes, back to the point, I do brew good beer, assuming that you like good, > > hearty ales of the IPA, bitter, stout variety and/or european wheat ales > > (I'm not a big fan of American Wheats). > > My only frame of reference really are German beers, but I'm curious > ... Well most German beers are lagers and while I like them (especially a good Marzen) I am not into brewing them as they have more complicated needs. As for wheat beer, I'm talking weissbier/hefeweizen (Weihenstephaner is considered a classic standard). I love dunkel weizen and wiezenbock but haven't gotten around to brewing them myself yet. > > > since I don't think a > > pressurized keg of beer is likely to go over well with the airlines. :) > > Yes, I was wondering about that. Given the current state of things you > might end up getting free accommodation for a long time ;-) > > > You know, I find this very tempting. I would love to really be able to > > contribute more to the project and a face-to-face sit down would > > really get a > > manual off to a good start. > > Yes and having people come there just for the purpose of doing that > would probably keep me from going kayaking instead :-) > > > I don't think I can afford to actually go to the conference itself > > (airfare, hotel AND the conference is a bit steep for me) but I may be > > able to come out for a few days and do a "Social and Expo Pass" if they > > offer it. > > Conference Fees: > > Well, last ApacheCon the Hackathons were scheduled the days before the > conference so everybody could participate. And even though I'll > probably have to do my half day tutorial during that time, that would > still leave us quite some time to get things started. > That is ideal for me since I can come out for a long weekend instead of taking off most of the week. > If we found a free meeting place somewhere in SD we could even arrange > for some open-for-all meetings before or after the conference. In > Stuttgart the technical college was kind enough to host us, perhaps we > could find something in SD as well? > > Who else is interested in joining this effort or attend a more general > meeting? Diwaker? > > Accommodation: > > If it doesn't have to be a hotel, check out > http://www.hospitalityclub.org/. It's a free hospitality exchange and > works great for finding you a place to sleep for events like this. I > just checked, there are 112 hosts in SD at this time, so accommodation > should not become a major expense. In fact, I'll do that for the days > that my accommodation is not covered by the conference budget. Ah now that is cool. I have signed up. I think between inexpensive accomodations and the timing of a long weekend, I can probably do this trip pretty easily assuming no major things come up. Besides who can say no to a few days in SD in December (when it is cold and wet at home)? - Addi
Re: Proposal: interactive planning session for views/xhtml2/internals
Ross Gardler wrote: David Crossley wrote: ...snip ... We need one to two hours sometime soon where we can get together and coordinate xhtml2/views/internals Would next weekend suit, or should we try during this week? For me: Anytime during the week apart from Monday 10am - 8pm (BST, UTC +1) Next weekend is OK on Sunday afternoon/evening (BST, UTC +1) I'll therefore suggest three times, I'm sticking with Davids suggested start time since I guess it is somwhere in the middle of Europe/Australia/US times, express you preferences or alternatives please: Tuesday 13th, 19:00 UTC Thursday 15th, 19:00 UTC Friday 16th, 19:00 UTC Sunday 18th, 19:00 UTC Ross I'm available on Tues. and Thurs. and those times are good for me but I can do other times too. - Addi
Re: [FT] 2005-09-06 Summary
On Saturday September 10 2005 5:07 am, Ferdinand Soethe wrote: > >> But I should warn you, so you're not shocked if you meet me, I'm > >> actually a she. :) > > I think we are getting a little distracted from the real issues here: > DO you brew good beer of don't you? And will you bring some to SD? Yes, back to the point, I do brew good beer, assuming that you like good, hearty ales of the IPA, bitter, stout variety and/or european wheat ales (I'm not a big fan of American Wheats). As for bringing some to SD that would depend on whether I am going and if I have any brew ready at the time. I normally just keg my beer and bypass the whole bottling mess, but an exception could be made to share with friends since I don't think a pressurized keg of beer is likely to go over well with the airlines. :) > > But more seriously: This might be a good opportunity to have a > Hackathon focused on getting the structure for our Forrest manual > started? You know, I find this very tempting. I would love to really be able to contribute more to the project and a face-to-face sit down would really get a manual off to a good start. I don't think I can afford to actually go to the conference itself (airfare, hotel AND the conference is a bit steep for me) but I may be able to come out for a few days and do a "Social and Expo Pass" if they offer it. I will be spending a decent chunk of money and leave time from work starting next weekend to go down to Texas to help with Katrina relief effort as a volunteer so I will have to assess the real possibility of SD once I return in October. Hopefully they will get the details about the conference posted relatively soon so I can more accurately assess what I can do. Diwaker: How is public transportation in SD? If I stay at some cheapy hotel not down by the water will I be able to get to the conference easily? > > -- > Ferdinand Soethe
Re: Proposal: interactive planning session for views/xhtml2/internals
On Saturday September 10 2005 2:42 pm, Diwaker Gupta wrote: > > Looking for a suitable time. If it doesn't suit > > then propose another: > > http://www.timeanddate.com/worldclock/meetingtime.html?day=11&month=9&yea > >r= 2005&p1=136&p2=48&p3=176&p4=240&p5=224&p6=213 1) Saturday, September > > 10, 2005 at 20:00:00 > > 1) Sunday, September 11, 2005 at 19:00:00 > > Wow, that was kind of sudden! :-) Is it still happening? I don't think it is going to happen this weekend as we would need more people to be available (and want to participate) for it to be worthwhile. > I assume the > time's David mentioned are UTC? I have a busy weekend, but I'll still try > to be online whenever its happening. > > Diwaker
Re: Proposal: interactive planning session for views/xhtml2/internals
On Saturday September 10 2005 3:12 am, David Crossley wrote: ... snip ... > Well that is a few interested, but we are not going to > do it unless the project is well-represented, with a > majority of the people who are interested in the core > views/xhtml/sitemaps issues. Yeah, I think that doing this without people like Thorsten and Tim here (not slighting anyone else, just giving examples) as well will sort of defeat the purpose. > > Remember, the proposal is not about making decisions > or doing work. > > Looking for a suitable time. If it doesn't suit > then propose another: > http://www.timeanddate.com/worldclock/meetingtime.html?day=11&month=9&year= >2005&p1=136&p2=48&p3=176&p4=240&p5=224&p6=213 1) Saturday, September 10, > 2005 at 20:00:00 > 1) Sunday, September 11, 2005 at 19:00:00 > > So far the following people are interested. Please > state if you have time or date restrictions: > > Ross > Diwaker > David - any time, any day, try Skype, IRC okay > Addi I can do pretty much anytime this weekend as long as I know when. My sleeptime here is typically 4:00 UTC to 12:00 UTC but I can work in the edges of those times as well. - Addi
Re: xhtml2 tonights update & questions
On Friday September 09 2005 4:40 pm, Ross Gardler wrote: ...snip ... > I'd prefer Skype, I feel it is a higher bandwidth communication and is > less open to misinterpretation. > > As an additional thought, there is a new thing called vSkype that allows > up to 200 people to participate and you can share one persons desktop. > We could use the shared desktop to allow someone to take real time notes > (if we use the Lenya instance, which seems to be up and running now, we > can switch the "note taker" around. Just a note: Biggest problem I see with vSkype is that it is currently only available for Windows. I prefer IRC just because I am more familiar with it (never used Skype but am willing to try it out), although I agree about the misinterpretation being higher with written rather than spoken communication. I would mainly be listening anyway so whatever works best for others is fine with me. > > I'm not saying no to IRC, I'll use whatever is appropriate, it does have > the advantage of being self logging. > > Whatever medium we need I think it is important that we follow > Ferdinands recomendation of taking a minute after each statement to > consider what has been said by the previous speaker (man that will be > hard for me!) > > Ross
Re: [FT] 2005-09-06 Summary
On Friday September 09 2005 3:41 am, Ross Gardler wrote: > addi wrote: > > On Thursday September 08 2005 5:15 pm, Ross Gardler wrote: > >>>I also like cheches Interesting summary at: > >>>http://casa.che-che.com/~bot/forrest/ > >>> > >>>made me laugh. > >> > >>That is cool, I would like to highlight one of the random quotes as I > >>feel it is particularly important for the community: > >> > >>addi 49 "matter of fact I'm a brewer" > >> > >>In othr words, Addi is candidate number one to host our next get > >>together (at least in my book - he brews good beer too). > > > > LOL, well if ApacheCon comes to Washington, DC you're all welcome to my > > place. But I should warn you, so you're not shocked if you meet me, I'm > > actually a she. :) > > Ooops - I'm sorry I made wrong assumptions (shame on me) - thanks for > being understanding and putting a smiley in there, the joke is > definetely on me.. > > Ross I am not easily offended and I know that maleness is sort of a general assumption in the world (for many reasons) and particularly so in the computer world. I do not judge harshly about it because I find myself and my girlfriend do the same thing more often than we care to admit as well. It is a deeply rooted assumption for many and is a concious work in progress to modify. - Addi
Re: [FT] 2005-09-06 Summary
On Thursday September 08 2005 5:15 pm, Ross Gardler wrote: > > I also like cheches Interesting summary at: > > http://casa.che-che.com/~bot/forrest/ > > > > made me laugh. > > That is cool, I would like to highlight one of the random quotes as I > feel it is particularly important for the community: > > addi 49 "matter of fact I'm a brewer" > > In othr words, Addi is candidate number one to host our next get > together (at least in my book - he brews good beer too). LOL, well if ApacheCon comes to Washington, DC you're all welcome to my place. But I should warn you, so you're not shocked if you meet me, I'm actually a she. :) > > Cheche - thanks for getting Jenny to work so hard. > > Ross
Re: Proposal for Forrest-Cocoon-Lenya commit access
Ok, I am not a PMC member nor committer so ignore/listen as you like. Also if
I seem riled up, please take my general attitude with a grain of salt as
"Katrina/lack of response to" has gotten me rather upset lately. I do not
mean to offend at all.
On Friday September 02 2005 8:42 pm, David Crossley wrote:
> Tim Williams wrote:
> > David Crossley wrote:
> > > Anyway, i just want to ensure that we all, especially
> > > our new PMC members, understand the implications.
> >
> > This new PMC member doesn't see the value in it as I attempted to
> > express in my earlier mail on this topic. I don't believe in the
> > "field of dreams" ("if you build it, they will come") -- "if you give
> > access, they will contribute". Truth is, people contribute because of
> > their own personal interest not just because there's an easy
> > opportunity.
>
> That is the way that i see it too.
>
> > I can only imagine that for an existing committer on
> > another project, the bar would likely be set pretty low for a
> > committership offer anyway -- so asking them to add a JIRA issue and
> > and contribute a patch to determine whether they're truly committed to
> > forrest or just stumbled across a couple bugs isn't a great burden for
> > someone already familiar with the process anyway.
I totally agree with this. Thorsten points out that this takes time, but
seriously, for someone familiar with the patch submission process this is
really minimal in my mind. I am not a committer and maybe committers are
used to the "easy access" to do things so the idea of having to go through
JIRA seems like such a burden, I don't know. But shouldn't we be tracking
what we are doing in JIRA anyway? What is the huge burden to actually create
an issue and submit a patch? If someone is not willing to take 3 minutes to
help the project to that level then, well, it seems kinda like spoiled
behavior to me. I mean, lots of people who submit patches don't have tons of
free time to just sit around and create JIRA issues and upload patches for
Forrest. Sorry if I'm ranting but I do feel that it is coming across *a
little bit* as though submitting patches is somehow "beneath" or not as
effective as all the hard work that many, many people without commit access
do here regularly (and I'm not referring to myself at all).
The concept of committing and PMC being a combined responsibilty makes sense
to me and committing without "commitment to the project" - aka PMC - still
strikes me as odd. But that's just me. I wonder if not being a committer
makes me more sensitive or aware of this line, since it seems like a big line
to cross and not taken lightly, per our recent discussions on this.
>
> I have a personal example on that. We had a need
> in Forrest for another Apache Ant task. It was easy to
> develop and test it here, then contribute it back.
> If i had such commit access to Ant, i would not have
> used it anyway. I would still send a patch, complete
> with test case and doc. Let them handle it.
>
> > Opening the doors because we trust folks to know their own limitations
> > sounds unnecessary to me. Open the doors because we trust your
> > self-control? I mean, I suppose there's no harm given that if they
> > don't have self control commits could be reverted and svn locked down,
> > but what's it buy us?
> >
> > I suppose when I came on I read the roles and merit stuff, emails from
> > existing PMC members on these sort of topics and came to a certain
> > conclusion and respect for it. Now it seems like we're changing
> > "merit - earned by consistent contributions" and "committer==someone
> > who is committed to a particular project".
>
> We want to make sure that we don't change any of that,
> which is why we are discussing this all before rushing
> to a decision.
>
> > I mean, based on these
> > definitions, I don't understand why Lenya for instance, votes me a
> > committer on their project.
>
> Thorsten corrected that mis-understanding.
>
> > Between your hypothetical and Nicola's Ant experience, I just don't
> > see the value in it -- is it just a "good will" jesture or what?
Again, I am agreeing with Tim here, because I am really curious to know, not
because I am trying to be a jerk. If this is really about "good will" and
building a feeling of combined community so they will want to help with this
integration of Forrest and Lenya, then call a spade a spade. I just don't
buy the "low-entry barrier" stuff honestly.
- Addi
View Plugin link on site is broken
From plugin page (http://forrest.apache.org/pluginDocs/plugins_0_70/index.html#Whiteboard+Plugins) trying to go to view plugin page... Not Found The requested URL /pluginDocs/plugins_0_70/org.apache.forrest.plugin.view was not found on this server.
Re: Automated formatting of XML files
On Monday August 29 2005 6:33 pm, Diwaker Gupta wrote: > > So do we all want to work with the same editor for cleaning or do we > > want to use a cleaning tool and give up our blank lines in XML files? > > Many of us are sensitive to our development environments (atleast I > am!), and forcing a particular choice of editor would not be a good > idea IMHO :-) Yes, I agree. I actually didn't get to fully think out and write what I wanted to say because I realised I was late for my train so I just signed and hit send. :p > > The reason I don't want to use any IDE for this cleanup task, and > instead a tool like Tidy, is that things can be automated much more > easily. We can schedule clean-ups periodically, add targets to the > build process to do it automatically -- there's a lot of flexibility > in how we go about it. > > Using an XSL transform for cleanup is attractive because we don't need > any external utility; Forrest is all about XML processing anyywas :-) > > So I'm +1 on either Tidy or XSL (personally, I prefer Tidy since in my > experience its much smarter and faster). -0 on jEdit plugins and such. I would say that I am +1 on XSL, +0 on Tidy and -0 on any IDE/editor. I am doing more research to see if I can come up with a solution that leaves the blank lines in. Turns out that Tidy has a config option vertical-spacing, but that puts a blank line after every element closing tag so it ends up looking pretty weird and adding lots of lines we wouldn't want. You can try it out by adding "vertical-spacing=yes" to your config.txt file. I am mainly not so keen on tidy at the moment because I am having trouble with it not wanting to process due to errors that need to be resolved and it is giving me a headache to figure out what the hell it wants from me, whereas the XSL just works and stays "native" to Forrest, as it were. I wish there was a way in the xsl to preserve-space a blank line. Any xml experts out there have any ideas? I don't know diddly about xsl. Here is the basic XSL for cleanup: http://www.w3.org/1999/XSL/Transform"; xmlns:xalan="http://xml.apache.org/xalan"; version="1.0"> - Addi
Re: Automated formatting of XML files
Diwaker Gupta wrote: I think that it is doing too much, e.g. removing the blank lines before major elements, e.g. Hmm, I can't seem to make Tidy not do this :-( Is this a blocker? If not, then I'd like to stick with Tidy. If it is, read on. I'm not sure if it is a blocker but I think it would be nice to retain the blank lines if we can since it makes it a little easier to follow the code, especially for someone like me that is relatively new to xml. The question is, is there a tool that will do it? See below. I was researching XML pretty printers a bit to see if we had alternatives. It seems one can just write a simple stylesheet [1] to clean up XML (since its part of the XSL language -- see the xsl:output element [2]) [1] http://lists.xml.org/archives/xml-dev/200110/msg00620.html [2] http://www.zvon.org/xxl/XSLTreference/Output/xslt_output.html Although I haven't tried this method yet and its not configurable at all. So I'm not sure how well it'll work. I did go ahead and test this (using xalan:indent-amount="2" rather than the saxon example) and it gave an identical file to the tidy file (except that the line wrap was longer). It removed the blank lines as well. What I have used on the test files so far to clean them up with minimal impact is jEdit with the Whitespace and XML Indenter plugins. The whitespace cleans the tabs and spaces and the indenter sets the proper depth and doesn't touch anything else. I assume other editors could do similar things. So do we all want to work with the same editor for cleaning or do we want to use a cleaning tool and give up our blank lines in XML files? - Addi
Re: Automated formatting of Java files
Diwaker Gupta wrote: Can you tell me what settings you are using so I can try to match them with my Jalopy plugin without thinking too hard? :) Attaching the convention file. I use it with the Ant plugin. But you can use whatever you want. Ugh. I am using jEdit and it took me a while to figure out that the standard jEdit plugin through the plugin manager uses an older version of Jalopy and so couldn't read your file properly. I got a newer plugin from the Jalopy site and successfully imported your file but now I always get a StackOverflowError when I try to clean a file. I understand that to mean that it is recursing too deeply but I have no idea what that really means or how to fix it. I'm using JDK 1.5.0_04. Any suggestions other than trying another app? - Addi 14 <description>Forrest Coding Conventions</description> <name>Forrest</name> false [A-Z][a-zA-Z0-9]+ [A-Z][a-zA-Z0-9]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [A-Z][a-zA-Z0-9]+ \w+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z]+(?:\.[a-z]+)* [a-z][\w]+ [a-z][\w]+ [a-z][\w]* false false false false false false false false false false false false false false false false false false 6 3 3 3 3 3 3 true 1 true false true true true bak 0 1 0 1 0 1 1 1 2 1 1 1 0 1 1 1 1 1 1 0 0 1 false false true true true true true false false false false false false true true true false false false true 0 0 0 0 false */ * @throws $exceptionType$ DOCUMENT ME! * @param $paramType$ DOCUMENT ME! * @return DOCUMENT ME! /**| * DOCUMENT ME! false false false - true false Inner Classes Constructors Instance fields Instance initializers Inner Interfaces Methods Static fields/initializers 0 false The Apache Software Foundation 0 /*| * Copyright 1999-2004 The Apache Software Foundation or its licensors,| * as applicabl
Re: *using* metadata in forrest
On Sunday August 28 2005 12:18 pm, Tim Williams wrote: > I've been exploring the XPathDirectory Generator lately to actually > *use* the document metadata for driving a site. Our doctype supports > metadata but we don't (so far as I can tell) actively use the > metadata. I'm exploring this in terms of a webblog use-case. I'm not > so interested in using forrest as a blog publisher as I am in the more > generic metadata driven site problem. I'm doing it via a plugin > locally. So I'll describe it here and if anyone is interested in this > type of problem, then I'll put what I'm doing in the whiteboard? ... snip the good stuff ... > Other use-cases I've thought of are: > o) Product catalogs where each product might belong to more than one > category. o) Product documentation where each document may apply to more > than one version of the product. > o) News site where each article might fall under more than one category. > > Others might be already doing this stuff but I recently discovered the > power of xpathdirectory generator and it's caused me to explore it a > little. > > I'm interested in hearing if anyone's already doing this sort of thing > and whether it's generally interesting or just peculiar to me. > --tim I don't know if anyone is doing anything with this but I do find the feature very interesting and useful. I could definitely use it for my use case at work where we are putting all documentation in one central location broken down by category and I can see several things already that could/should be in several categories. I'm kinda slow and not very well versed but I'd be willing to help where I could as this is something I would definitely use. - Addi
Re: Automated formatting of XML files
On Friday August 26 2005 4:00 am, Thorsten Scherler wrote: > Can't we have *one* thread for that? > > I do not see the point that we copy n' paste our replies between > threads. David you give here nearly the same reply as in "Automated > formatting of Java files". Is there a reason to treat java seperate from > other files? Yes, this is getting confusing having so many threads to check through. > > salu2 > > On Fri, 2005-08-26 at 16:57 +1000, David Crossley wrote: > > Diwaker Gupta wrote: > > > When I say XML, I mean all kinds of XML files (XSL, *.fv, *.ft) > > > > How will the tool know which are xml file-types? > > We have a multitude of xml filename extensions. > > There is a list on one of the tools in the > > "committers" svn repository at relicense/src/insert.pl > > > > > As with Java, I have committed a "tidied" version of the > > > html2document.xsl sample document in the test-whitespace directory. As > > > with Jalopy, Tidy (http://tidy.sf.net) is extremely configurable, so if > > > you don't like something or have a suggestion, just let me know. > > > > I think that it is doing too much, e.g. removing the > > blank lines before major elements, e.g. I noticed that as well and in my admittedly cursory search about it, it seems that it does that to all XML files. Apparently it retains them for HTML and XHTML but *not* XML? More research/playing around would be necessary because I didn't really have time to look far on that. > > > > We should start with very simple stuff, e.g. just tabs > > and trailing whitespace, then gradually add other operations. > > However we don't want to get too strict on code style. > > > > I suggest that we define a list of what we would possibly > > want to adrress. Here is a start: > > > > 1 whitespace at end-of-line > > 2 tabs to four-space Cut and paste gone wrong... XML types would be two-space no? - Addi
Re: Automated formatting of XML files
Diwaker Gupta wrote: When I say XML, I mean all kinds of XML files (XSL, *.fv, *.ft) As with Java, I have committed a "tidied" version of the html2document.xsl sample document in the test-whitespace directory. As with Jalopy, Tidy (http://tidy.sf.net) is extremely configurable, so if you don't like something or have a suggestion, just let me know. Diwaker What are your settings? Tidy is giving errors around the CDATA sections and it won't tidy til those errors are "corrected". - Addi
Re: Automated formatting of Java files
Diwaker Gupta wrote: Following up with our earlier discussion on whitespace cleanup, I have added two "jalopied" Java source files in the test-whitespace directory. I would urge the devs to take a look at both the original Java file and the formatted file and see if it suits their tastes. Please post any comments and suggestions in this thread. Bear in mind that with Jalopy, almost *anything* is configurable. So if you find anything, however small/trivial it is that you don't like, please let me know. Its a great tool, so lets make the best use of it. To see exactly what is configurable, take a look at: http://jalopy.sourceforge.net/manual.html As an example of things that it can do: o automatically add/update headers (the Apache license, for instance. In future if we have to change one line in the license, Jalopy will automatically delete the old one and insert the new one) o sorting/group of imports, methods, variables o alignments, braces, spaces -- you name it! o automatic javadoc generation, correction Can you tell me what settings you are using so I can try to match them with my Jalopy plugin without thinking too hard? :) - Addi
Re: whitespace cleanup
David Crossley wrote: Addi wrote: I went ahead and cleaned the test files with my editor. How would you like to check/compare them to your editor to make sure we are on the same page? I tried doing a reformat using IDEA and it was too zealous. It could be configured to be more minimal, but i bet that it would still be different to yours. Using specific external tools to assist, like Diwaker suggests, sounds the best approach to me. If that is not suitable, then we should settle on one particular editor to do the cleanup. -David Yeah, I agree that having an external tool that does it in a standardized way would be ideal. I currently use jEdit as my main editor but I can install anything we agree on as long as its free. :) - Addi
Re: whitespace cleanup
David Crossley wrote: Addi wrote: David Crossley wrote: I suggest that we do a test of one quiet directory, to ensure that our various text editors do the job consistently. Agreed. Not much point to cleaning up if we have to clean up afterwards because someone's editor was out of line. I added some examples of our own java and xml files with a variety of problems into trunk/etc/test-whitespace/ -David I went ahead and cleaned the test files with my editor. How would you like to check/compare them to your editor to make sure we are on the same page? Note that all I did was change/remove whitespace, I did not correct issues of odd number spaces on indents yet. - Addi
Re: whitespace cleanup
On Tuesday August 23 2005 10:58 pm, David Crossley wrote: > Addi wrote: > > David Crossley wrote: > > >We could add a list of all directories to a file in the > > >"etc" directory. You can still see remnants of previous > > >half-finished jobs there. That list could provide notice > > >of which sections have been done and which are next. > > > > OK, I found those and have created a new list that I added to JIRA. I'm > > sure I have some typos and missed dirs in there somewhere but the main > > stuff is there. We can correct the file as we find the mistakes on our > > cleanup sweep. (btw, those plugin dirs almost made me go cross-eyed so > > most mistakes will probably be there :)) > > Did you use the UNIX command 'tree' or create it manually? > The former i hope. > > -David No, I did it manually. Everything that I know about computers has been self-taught so unfortunately I have huge gaps in my knowledge. I end up being a big Rube quite a bit as I continue to learn. I also know less about the windows command line than I do linux and I was on my windows laptop. Now I know. The time was well spent anyway since I really got a detailed look at all of Forrest which I hadn't really done before. I guess I should redo the file using 'tree' as that would probably be more accurate... - Addi ps - to those that do not know what a Rube is, it is taken from Rube Goldberg who invented ways of doing simple things in a very complicated manner. Check out http://www.rube-goldberg.com/ for a laugh.
Re: whitespace cleanup
David Crossley wrote: ... snip ... We need to properly define what our whitespace treatment is for each class of file-type: *.java and *.x* and *.txt etc. I started that in docs_0_80/howto/howto-dev.xml and linked to Cocoon's decision. We could adopt the same. I agree with that. It seems sound to me. We could add a list of all directories to a file in the "etc" directory. You can still see remnants of previous half-finished jobs there. That list could provide notice of which sections have been done and which are next. OK, I found those and have created a new list that I added to JIRA. I'm sure I have some typos and missed dirs in there somewhere but the main stuff is there. We can correct the file as we find the mistakes on our cleanup sweep. (btw, those plugin dirs almost made me go cross-eyed so most mistakes will probably be there :)) I suggest that we do a test of one quiet directory, to ensure that our various text editors do the job consistently. Agreed. Not much point to cleaning up if we have to clean up afterwards because someone's editor was out of line. I will first do a sweep of our whole space to find any Windows line-endings problems. -David Addi
Re: whitespace cleanup
David Crossley wrote: ... snip ... This is actually not correct. The editor needs to not touch whitespace at all (unless to format new files). Existing whitespace needs to be left as-is otherwise there will be complex diffs when the devloper contributes a patch. We need to gradually cleanup the whitespace inconsistencies in our SVN first, then people can do auto-formatting properly. I am willing to help with the cleanup. I don't know what the best way to organize and execute is though. Could I just post to the list that I am cleaning "xyz" dir today and please don't do any commits. Then, when I am finished cleaning and upload the patch, JIRA will email the list and everyone will know that dir is done and can resume commits? Obviously sections under heavy development right now are not the best canidates but if you all can make clear which dirs I should just leave alone right now, I can easily skip over. Then again, even for the heavy dev dirs, if I can knock out sections of them in an hour or two's time, it will disrupt dev work very little I think. It just requires good communication. Anyway, not sure if that is what you all are thinking in terms of cleaning process, but let me know what I can do to help. - Addi There was a huge discussion at Cocoon: Re: whitespace cleanup and efficiency drive http://marc.theaimsgroup.com/?t=10684399772 The dos2unix stuff is discussed: http://cocoon.apache.org/community/committer.html http://www.apache.org/dev/version-control.html#https-svn http://svnbook.red-bean.com/en/1.0/ch07s02.html (svn:eol-style) -David
Re: [jira] Commented: (FOR-603) How to become a Forrest Committer
David Crossley (JIRA) wrote: [ http://issues.apache.org/jira/browse/FOR-603?page=comments#action_12319173 ] David Crossley commented on FOR-603: Youch, i pressed the worng button and deleted it. Could you please re-attach. Whitespace inconsistencies cause havoc. Could we discuss that on the dev list please. Geez, OK I finally figured out my whitespace issue. I had changed my editor to match the document (2 soft space tabs and 80 char hard wrap) but it was also set to remove trailing whitespaces on save and most of that file had trailing whitespaces so the whole thing got screwy. I changed that setting and redid the diff and it looks much better now. Sorry I have been submitting such crazy patches, but I think I have it worked out now. I will put the new diff up now. - Addi How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Priority: Minor Fix For: 0.8-dev Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-dev&m=112239074108858&w=2 re: creating documentation on becoming a committer in Forrest.
Re: photographs from ApacheCon EU 2005
And I notice that David is conspicuously absent... Ferdinand Soethe wrote: Cyriaque Dupoirieux wrote: It's fun to see what some of you looks like... Only if you are not in the fotos :-) -- Ferdinand Soethe .
Re: Simple committership
s not code, but project management, then why not consider the opposite of the "incubator" being proposed and create a PMC incubator where potential committers can be given more direct involvement in the project management/infrastructure side of things without the right to commit yet? I don't know how/if that could work because obviously I'm not in the PMC and honestly I'm not sure what all that entails. I am also not entirely sure that I think a distinct incubator is a good idea altogether. It seems to me, that if used properly by the PMC, the dev list is already a good place for incubation and assessment of potential committers. A lot is in here if you pay attention. Perhaps taking the mentor role more directly on the list (like when Ross put on his mentor hat with Anil) would serve our purposes. Basically in the end noone gets a sense of how a place runs until they step through the front door. The more transparent you make the entrance, by exposing and explaining as much as you can on the list, the easier it may be, but it will always be a learn as you go thing. That's my little shout from the peanut gallery. - Addi One thing that helped me is that the PMC normally watch the committs of new committer more careful to ensure that e.g. all legal issues are meet. PMC membersnot only have to help new committers to learn the duty of a PMC member in the specific project (b) but also like the incubator teach the values of an ASF project and its duties (a). There have been a thread on all PMC lists about the duties (around 10 points) of a PMC member by Davanum Srinivas. I was given committership to apply my own patches for cocoon, forrest and xml. That leveraged this project (faster process) because other PMC members do not had to do that. Then especially David taught me as well the PMC duties and I became a PMC member. The main reason that there was a delay with you becoming a PMC member, was because we had to spend many months discussing our project guidelines before we could get any new people as PMC members/committers. Pulling in one of my comments from earlier in this thread: When we look for new committers, we need to see a few qualities. They should be helping other users and developers, able to work co-operatively, be a mentor, and be repectful of others opinions. Essentially be committed people who understand the Apache way. Rather than "understand", i meant: show that they have at least some clues and have the potential to learn the way. Not expected to know it all yet. Some people have no idea how to behave in a co-operative manner and only have respect for themselves. We do not encourage those types. The important point is that new committer are generally overwhelmed by the information and infrastructure of the project and the ASF. Some learn better step by step understanding what is ASF all about and what a PMC member have to do (I consider myself as such a somebody). I was lucky and made my experience in the incubator *and* here but the committers we vote in normally do not have this "incubator" experience which I consider most valuable. Take me as a different case. Cocoon was my first real opensource project. I had no Incubator to go through. The Cocoon people were nice and helpful all the way. But still i had to figure most of it out for myself, before and after becoming a committer. That is still the case being an ASF member. I still stumble in the dark. It is ongoing, and only the committed remain. In essence, Jakarta became a small Apache, creating sub-roles where the PMC members were like Apache members, and committers were like PMC members. In Jakarta it's usual that committers vote, but in fact their vote is not legally valid, and they *cannot* release code without a PMC vote. This also created a big disconnect between the Board of Directors and Jakarta, and most projects were having little or no oversight, and the number of Jakarta committers that was an Apache member was extremely low. The point you are maybe up to is that we can create a closed group that new committer are not able to enter. We limit the PMC membership to a certain group of people for whatever particular reason. The downside is that committers cannot be responsible for the projects because they are not in the "management" PMC. That will slow down the progress of this project(s) because it slow down their processes. I guess it happened because many projects emerged from Jarkata (e.g. tomcat, struts,...) and people felt better in having a good working team then to better leverage their pmc duties in teaching new committer this duties. One sentence of [2] seems very interesting at this point: "Section 6.3. Project Management Committees. ... Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolut
Re: user-friendly plugin names
Diwaker Gupta wrote: The naming convention for the plugins is fine, but I think it would be nice if users are able to declare required plugins using simpler names like "pdf", "text", "docbook" and so on. We can figure out what simple names exactly to use later. I just wanted to see what people feel about this? It should be trivial to implement (though I have _no_ clue how! :-D), and I think it'll make config much less intimidating (even I get scared typing org.apache.forrest.input.viewHelper.xhtml.ls) Diwaker Yup, I have to say I agree. It is also a pain when going to the plugin dir in linux to manually install the plugin because I like to use tab to finish out long filenames but I pretty much have to type the whole thing in since they all start with the same long name before getting to the actual useful part of the name. - Addi
Broken links on website
All of the whiteboard plugin links on the website are not found: The requested URL /pluginDocs/plugins_0_70/org.apache.forrest.plugin.view was not found on this server. Regular plugin links seem OK. - Addi
Re: [VOTE] merge locationmap branch with trunk
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 our demo junk out of it first I love this idea. Such a pain to go back in and "clean" when all I want to do is get to working. AND perhaps some custom targets for common applications such as - myPersonalForrestHomepage - myForrestBusinessSite with a few prefab pages that can be filled by a novice user. -- Ferdinand Soethe
Re: Project participation and hackability
Nicola Ken Barozzi wrote: Tim Williams wrote: Imagine that all cutting-edge users can use the trunk in production. A patch is just a couple of actions away. And after incorporation, the check is instantaneous, and on a *real* test, as it actually get used. I may be very well be in a unique situation but I can't imagine many folks are able to run a trunk on a live production machine? What about the CM baggage? If I were a client of that *real* test, I think I'd be concerned. If the recent JRE-version related discussion around release time are any indiciation, this is not necessarily unique. I have a small company with about 15 people that use the Intranet site. Being also a developer, I have no problem in using the latest code in "production". It's a small percentage of all usages, but still relevant for us. This can only work if the trunk is always *usable*, and not only _buildable_. This can make our trunk be really bug-free, as there would really be a lot of eyes looking at the code. I said before that I do like a usable trunk (i.e. buildable + runnable with no hoop jumping). I would thus propose that the trunk be always *releaseable* at all times, and that all new functionality that interferes with usage of prior features be developed on separate branches. 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] release quality is bold. Ok, probably the wording is too strong. Furthremore, these branches should merge whenever possible between them in a single branch so that they can be coded together, and get merged with the trunk only when all developer-known bugs are fixed. I understand that there will inevitably be dependencies between branches but I don't care for merging branches into a single branch (btw, wouldn't that ultimately become the defacto dev trunk?). There should not be dependencies between branches. If there is, then it should merge in a single branch. This will also make it easier for us to release often, and to learn to make smaller reversible changes rather than big ones that are hard to understand by other developers and users. Let me know what you think. I guess the summary is that this sounds like an "Always-Branch" system as opposed to the more pragmatic "Branch-When-Needed system" and that seems overly rigid for little return. In other words, I doubt that a lot of folks are able to run a trunk in a production environment and so burdening yourselves with the overhead of maintaining a trunk in a "releasable state" for what would amount to a handful of folks that could use it (and likely already have svn loaded anyway) doesn't seem worth it. I am one of those, and I think that most Forrest developers are. If we have at least a couple of others willing to use it, we're set. I have omitted another thing though, that I would like to release Forrest *with* SVN stuff, so that patches can always be easy to make and to send. As for the difficulty of maintaining a "releaseable" trunk, see my next reply. Thanks for your mail, it helps :-) I just wanted to pipe in here real quickly to add another data point to the discussion. I am not a real dev, just a tweaker and poker, so most of this discussion is not really for me to get involved in but I do want to work with forrest and help as much as possible. I do like the idea of a using trunk for production. I am serving about 150 people on our intranet and wouldn't mind using it for our stuff. We haven't implemented Forrest yet, but I plan to by October. I already have our test system set up to run off trunk while I've been playing, so if trunk were always in a usable state, I don't have to change anything. Addi
View HowTos small questions
I've been going through the View HowTos, which are really spot on and
easy to follow (thanks Thorsten!).
As I'm going, I have been doing a little reader editing, mainly small
typos or just sentence flow kind of things. I do have some
documentation clarification questions that I wasn't sure about.
in View Install:
The note on why we set leather-dev as the default skin states:
"We exchanging only site2xhtml.xsl of leather-dev skin by the plugins
and some contracts are based on e.g. document2html.xsl output of
leather-dev."
I wasn't sure what exchanging the .xsl by the plugins really meant.
Does this mean to say that the plugins require leather-dev's
site2xhtml.xsl or is something actually getting exchanged between
leather-dev and views?
in View DSL:
1) When we create our first view it says to create a file named
"index.ft". As we proceed and add the contract-main, the HowTo states
what our "index.fv" file should look like. I'm assuming the first is a
typo? I wanted to check before I changed it.
2) When creating the custom css file it says to save it to
{project:skins-dir}{path} and the example goes to
...src/documentation/skins/css... but skins/css/ does not exist in the
src dir from a forrest seed so maybe it should be made clear that you
need to create those dirs?
If you want to see my patch, should I open a new issue to submit it or
do you have an issue open that you would rather I attach to?
Thanks
Addi
PS: I agree with Ross, Views Rocks!
Couldn't attach screenshot to JIRA
I just opened a new issue and had to load the screenshot up by attaching a gif file (using attach file). When I tried to use the attach screenshot option, it seemed like it was working (paste screenshot, add comment, click attach) but after I clicked attach and the page reloaded, there was no screenshot or comment for the issue. Tried twice before I just decided to attach file. Addi
404 Not Found for simplified docbook plugin
Quick note: The link from 0.7 Plugin page for simplified docbook plugin (http://forrest.apache.org/0.7/docs/plugins/simplified-docbook) is giving a 404 error. The url does not have the "org.apache.forrest.plugin.input" part of the name in it like the others do. Addi
Re: [jira] Updated: (FOR-518) Change toolbox font in skinconf.xml for pelt
Ross Gardler wrote:
Addison Berry (JIRA) wrote:
[ http://issues.apache.org/jira/browse/FOR-518?page=all ]
Addison Berry updated FOR-518:
--
Attachment: toolbox-font.txt
Last night I fixed this by editing the pelt/css/profile.css.xslt file
by moving #menu .menupagetitle {color: select="@font"/>;} up to toolbox, rather than where it was in dialog
(since dialog doesn't seem to be used in pelt?) and also adding the
font attribute to the toolbox color element in
fresh-site/skinconf.xml. Worked just the way I wanted. See the
attached diffs.
When I did a build clean, build on a new svn today, I am now getting
an error when I try to forrest site:
X [0] linkmap.html BROKEN: The
content of elements must consist of well-formed character data or
markup.
I'm not sure what the problem is now...
Have a look in webapp/WEB-INF/logs/error.log you should get a more
detailed error.
Do I have to turn logging on? I don't have a logs dir in WEB-INF.
A file somewhere is not well formed, most likely
pelt/css/profile.css.xslt since that is the one you say you edited.
I saw the well-formed bit and looked at the files I changed to make sure
I didn't have any typos and such. It was weird because it apparently
was well-formed prior to the svn build clean. I then changed the two
files back to the original and still got the error. Now I have blown
that svn away and gotten a whole new, fresh svn. I made the same
changes to the same files as I had before and it is working perfectly
like it did the first time. It's gone through a build clean and is
still working so maybe I did something weird elsewhere before. Who knows...
- Addi
Re: Duplicate copyright date
Thanks for finding that for me. I agree that the only difference should be the vendor hyperlinked or not and the year always there. I found where you are and I commented out line 301 to do it this way instead. I hadn't ever ventured into these files so it took me a while to figure out where line 289 was LOL :) For others who dont know the files so well: forrest\main\webapp\skins\pelt\xslt\html\site2xhtml.xsl - Addi Tim Williams wrote: For the proper fix, I'm not sure what *should* happen if there is a copyright-link. Right now the copyright year is not included when copyright-link exists, should it? Seems to make sense that the only difference would be if copyright-link exists then vendor would be a hyperlink instead of text? --tim On 6/2/05, Tim Williams <[EMAIL PROTECTED]> wrote: Looks like a bug in pelt. When you don't have a copyright-link it prints it out both explicitly before the choose and again inside the "otherwise". A quick fix is to just comment out line 289. I think this should be an issue though. --tim On 6/2/05, Addi <[EMAIL PROTECTED]> wrote: I'm using 0.7 svn and when creating a new site I am getting a duplicate copyright date ( Copyright (c) 2005 2005 The Acme Software Foundation.) prior to making any edits to anything. The year is only in the skinconf.xml file once so it looks like it is getting duplicated somewhere in processing. Pedro mentioned this in his earlier thread on user, Some Feedback on Using Forrest (http://www.mail-archive.com/user@forrest.apache.org/msg00619.html). He had made lots of mods so the issue got lost. Am I missing something or should I open a bug on it? - Addi
Duplicate copyright date
I'm using 0.7 svn and when creating a new site I am getting a duplicate copyright date ( Copyright © 2005 2005 The Acme Software Foundation.) prior to making any edits to anything. The year is only in the skinconf.xml file once so it looks like it is getting duplicated somewhere in processing. Pedro mentioned this in his earlier thread on user, Some Feedback on Using Forrest (http://www.mail-archive.com/user@forrest.apache.org/msg00619.html). He had made lots of mods so the issue got lost. Am I missing something or should I open a bug on it? - Addi
Re: documentation additions and issue tracking (Was: App vs Data)
** (from users, brought over to dev - replies will go to dev) ** Brought this over to dev to continue the discussion on exactly how to proceed with beginner documetation. As David points out we should figure out whether this is something that should be a separate HowTo, incorporated into the main docs or something else. Originally I was thinking of it as a HowTo and that we could take some of the more important bits and add them to the main docs. But I do think (actually hope) that the average user skills will decrease as forrest spreads. Right now it feels very geeky and I have friends who know something about html and css who may be interested in a program like this but would't really be able to pull this off with their current knowledge and, frankly, aren't going to take time to figure it out. If we want to bring more folks like that into the fold, then maybe moving more of the basic stuff into the main docs would make more sense. WDYT? To clarify a little what I mean by beginner, I am starting with as few assumptions as I think reasonable. The perspective is someone who uses html and css, probably using a GUI editor, has no command line experience and can follow directions :). Most linux users have some command line experience but from linux forums I can see lots of new to linux users who don't really grasp it beyond the specific thing they are told to type in an answer to their question. Most windows users don't have any of it. I use it all the time on my linux/unix boxes but forrest is the first time I had to figure any of it out in windows (I now hate backslashes in a whole new way). -Addi David Crossley wrote: Addi wrote: I am planning on working on beginner, step by step type documentation over time (as I learn the answers to my own questions). It would be best if we created a shell of a new document so that you and any others can work on it together. More below about that ... I was wondering if it would be OK to start a new issue in JIRA for an improvement in docs on this. That way, as people see problems that new users are having in the lists, we can add them to the list of those issues in JIRA to make it easier to keep track of it. Is that appropriate or is there another system set up for something like this? I feel that keeping my own scratchpad of issues is not terribly efficient, since I don't know all the issues ... This sounds like a good idea. I recommend separate issues for each item. After we have incorporated that piece into the documentation, then we close the issue. There is a category for "Documentation". Give each issue a useful Summary title. Keep the Description concise, and use Comments for more detail. Link to mail list discussions where appropriate. Are you working with the head of development, i.e. the trunk of SVN? ... and it would suck for myself and someone else to be writing docs on the same issue at the same time, thereby wasting someone's time. That is exactly why we try to work on every document in the SVN repository. It is then collaborative. It is also good practice to do it bit by bit, i.e. progressively build the document rather than do a whole swag by yourself, only to find that when it comes time for us to commit the work, that you have gone off track. Remember too, that it is quite okay to have "Fixme:" banners inside the published docs. It would probably be useful to discuss the overall aim of this beginners documentation. Will it be one document in the main section of the website, will it be a HowTo. That sort of discussion is more appropriate for the dev mailing list. This is exciting, thanks for helping out. --David What do you all recommend/already have in place? Thanks Addi Ross Gardler wrote: Tim Williams wrote: Embarrassingly enough, I was having a difficult time understanding the much simpler multiple statically built sites with one Forrest. Ross' answer was helpful and I think my problem was that I never created a subdirectory to do the seed in so that I had a single "src" at a higher level than it should have been. Having the "mkdir->cd->forrest see" and maybe a little explanation of having "multiple sites" would be helpful somewhere. We would love a patch for the docs making this clearer, sometimes we forget these critical points that are less obvious than we assume them to be. Ross
