Re: Forrest-lenya instance
Thorsten Scherler wrote: http://lenya.zones.apache.org:1/index.html Please test a wee bit. ;-) I did login as editor okay, but File-New-xhtml failed the first time, second time was okay. Then the create action failed. The new Cocoon error reporting is excellent. -David
Re: Forrest-lenya instance
Thorsten Scherler wrote: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: The wiki worked well for Cocoon. The big advantage is that it is not a synchronous medium so it doesn't matter that we will not all be online at the same time. However, I'd rather see Thorsten get a Lenya instance up and we start using that, both Thorsten and I are keen to push forward on the Doco thing and this could be the first exposure of many devs to Lenya. Yes please. I took this to the Lenya list, there is momentum gathering on Doco and as a result Thorsten has stepped forward to create a Lenya instance for us by Sept. 6th. Thanks Thorsten. You are welcome. http://lenya.zones.apache.org:1/index.html Please test a wee bit. ;-) Errors reported. Thanks for getting it this far, a good start. We can set up a basic lenya pub for us, where we will use the ac and our working structure (workflow,...). We should keep this pub here in our code base. Then we have as well a starting point for the doco move and the work of Joachim, David et. al.. Would it be alright to keep the content of this pub in a jcr-rep? What are the options? Your suggestion sounds good, but i don't know what are the implications. Some repository that is as easy as possible to start with. When there are more people involved, we can look at options that requirement more management. -David
Re: Planning the move to XHTML2 (Re: (FOR-184) Switch to XHTML2))
David Crossley wrote: I revised the list, taking the replies into account and adding some new queries. - agree the subset of XHTML2 to be used and document that via example. See other thread. - create DTD's Why do we need DTDs for use with internal structure? For using XHTML2 as an input format. In fact it will be a modularization of XHTML2 via RelaxNG validation. - Decide how to make the pipeline process. Now we have body-*.html and stuff, but a simpler process should be devised. - Convert all sitemaps and transformers to utilise that new process. - add a sitemap that processes *.xhtml2 files in a parallel section Does this refer to XHTML2 as input source files? It refers to all processing. What processing is needed? That's what has to be decided ;-) Whoever does it gets to try a simpler pipeline (without the body, header, etc doc matches, but just a single transformation). - convert all forrest:contracts to accept XHTML2 as input rather than XDoc while keeping the old ones in the meantime - convert forrest:views to work with XHTML2 and make them work in the extra pipeline. Here we should be able to accept XHTML2 input and produce the usual output. For legacy: - xdoc to XHTML2 stylesheet and create XDoc input plugin - document migration process -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Planning the move to XHTML2 (Re: (FOR-184) Switch to XHTML2))
Nicola Ken Barozzi wrote: David Crossley wrote: I revised the list, taking the replies into account and adding some new queries. - agree the subset of XHTML2 to be used and document that via example. See other thread. - create DTD's Why do we need DTDs for use with internal structure? For using XHTML2 as an input format. For that part i did understand the need. If the xml instances declare them, then the parser needs to resolve them locally. Same with any document type. Of course there are no DTDs yet at Appendix F or G. However, we are discussing internal processing, and i was wondering what is the need for DTDs there. Is there any need? Or am i misunderstanding something about XHTML2 and DTDs? In fact it will be a modularization of XHTML2 via RelaxNG validation. - Decide how to make the pipeline process. Now we have body-*.html and stuff, but a simpler process should be devised. - Convert all sitemaps and transformers to utilise that new process. - add a sitemap that processes *.xhtml2 files in a parallel section Does this refer to XHTML2 as input source files? It refers to all processing. Okay, then i will ask parallel to what? Do you mean keep the existing pipelines and starting this new one so that old and new can work side-by-side until the new stuff is ready. -David What processing is needed? That's what has to be decided ;-) Whoever does it gets to try a simpler pipeline (without the body, header, etc doc matches, but just a single transformation). - convert all forrest:contracts to accept XHTML2 as input rather than XDoc while keeping the old ones in the meantime - convert forrest:views to work with XHTML2 and make them work in the extra pipeline. Here we should be able to accept XHTML2 input and produce the usual output. For legacy: - xdoc to XHTML2 stylesheet and create XDoc input plugin - document migration process -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Proposal] Development process and a stable trunk
Thorsten Scherler wrote: On Sun, 2005-08-28 at 14:19 +1000, David Crossley wrote: Thorsten Scherler wrote: Before you read this reply, please read again my original reply. Did you read it, ok then go ahead and please be not offended that your name may not be mentioned here or in the other thread but you actually contributed to views in any form. That is not my intention. I was focusing on code for views and the common danger of ignoring threads. First of all, you will need to try very hard to be able to offend me. You were not. :) Cheers for telling me this, that is a relief. I am lucky that you are know me quite well because you help me from the beginning. That is true, but the point I was trying to make about offending people is that many people do not know us quite so well. We have to be careful not to offend newcomers. Did you see the recent thread on the infra@ list about netiquette? It asked if there is a problem here in Apache. The only conclusion I drew from it was that too many of us have formed a little group within the community who know each other well and so cutting remarks are taken in context of that relationship. These remarks often alienate newcomers who do not have the background of the older community members. I only raised the issue to keep us aware of the potential problem. I think we all know the intention was not to discredit anyone. But even in your response you said something about nobody else has committed code. That is also not true, nor is it important since discussion is an equally valued part of the community. We need to be careful about statements that remove the recognition of the community from people who contribute. There's no need for you to respond, I know you well enough to see it as an oversifght. I am raising it as a broader community issue, and I know you have the thick skin to cope with any percieved criticism - we all know that we write poor emails sometimes, this is a community awareness broadcast. Interestingly, when I wrote the original mail it wasn't David or myself that I thought may be offended, but some other newer members of the community who have also contributed to forrest:views - seems my own mail was a problem in the community sense :-(( .. I agree whole-heartedly with your warning about ignoring threads and at the same time i am saying that we need to allow people to particpate in some things and not others. Yes, I agree but we need to define core components and this core components should be understood and enhanceable from many active PMC member. I really do not want to see that we depend on individuals, we have do depend on the community. That is as well why I think we should rename whiteboard to incubation. All components that need more community support should go here. If we want to follow Stephano's dreamlist we have to be very clear on the community part of components. I have no problem renaming the whiteboard. There is sense in your proposal. I would recomend starting a new thread saying you are going to do it unless someone objects. ... If other people helped more with applying patches, then people like me would be relieved and could help more with views development. There is one patch sitting there from a new developer. Who is going to commit it before i get compelled to jump in? You are right. That is really a thing that I need working on. Anyway, like always said, I see views different and by getting into views I understood that this will change the general parts of the project. That is why I keep on asking for getting the views integration done. Just do it (in a branch), I proposed removal of views from whiteboard immediately after the 0.7 release. You refused, wanting it to stay in whitebaord, you said it wasn't ready. I had the time then, but not now. I took that time to build a site using views. That site is now in production - in my opinion views is stable enough, it is only implementation details that will change. Don't wait for me (speaking personally) since I am more keen to simplify our sitemaps using the locationmap, I think this will make forrest:views integration easier. However, I don't know when I will be able to do this, other commitments are in the way right now. Let me give you an example. The xhtml2 change will force us to rewrite the same pipes that we need to change for the views core integration! So will the locationmap work :-( Another point is the integration of the locationmap. Right now it is set up but there have to be touched a lot of pipes to really use it, again that are nearly the same like for views. Knowing this made me ask everybody to get into views. I'm sorry, it just doesn't owrk that way. Most of us are not here as a hobby or a play thing. Most of us use Forrest as part of our jobs. THat means we have to focus on the parts that are important to our job function. Get views into trunk (you have my +1 for a long time
Re: use of whiteboard in forrest
Thorsten Scherler wrote: On Sat, 2005-08-27 at 14:51 +0100, Ross Gardler wrote: David Crossley wrote: Thorsten Scherler wrote: c) refactoring of old code into a new version which would break the usability of the old code while refactoring. I think that would be better done in a branch. +1 Actually I was referring to your example of refactoring the Daisy plugin. I have chosen different wording I have to admit. The refactoring of the Daisy plugin is a good example of code that should be done in a branch. I broke some functionality of the 0.1 plugin during this refactoring whilst I worked out how it should be done. In this case it was done in the locationmap branch because it used the locationmap. If I'd done it in core then it would not have always been releasable. If it had been a straight refactoring (tidying of code) I would agree with you though. NOTE: If we agree to move all plugins out into a separate repo module we will be able to branch individual plugins. IMO branches should only be used if necessary. Refactoring code not always have to be done in branches. If they are components that can be capsuled then they should be refactored in incubation. That is more efficient (I do not have to check out a whole branch). Plugins cannot have a version in whiteboard/incubation and one in the core - their names would clash. This is another good reason to move plugins into their own repo, we can then branch just that plugin code and not the whole tree. Core code normally do not allow that, another good reason to try to make the core as small as possible. +1 Ross
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
David Crossley wrote: I would like to deal with Internal structure is XHTML2 and the associated issues. +1 Though simplifying Forrest directory structure is a close second on my list ... -- Ferdinand Soethe
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
Ross Gardler wrote: The *implementation* of the move to XHTML2 would be eased considerably by refactoring our sitemaps to use the locationmap. Why is that? In my limited understanding lm allows to specify the location of a resource in more sophisticated ways, where is the connection? Tim reports that the project locationmap mount doesn't work properly yet, but unless he tells us otherwise I think we can safely move forward with this refactoring. Not sure this kind of lazy consensus is the right approach here. I understand is that Tim has pointed out a problem with the lm implementation. Should it not be up to us now to demo that this problem has been solved (us of course including Tim :-) rather than expecting Tim to object? I am +1 on the move to XHTML2 being a primary goal for Forrest Tuesday, but with the provision that w work in a top down approach. That is, we start by creating the stylesheets, templates etc. We should *not* work on the core sitemaps, instead we should focus on a single path through the sitemap and build it as an internal plugin. I'd suggest the path should be DocumentV1.3 as the input format. ... so that using this plugin Forrest will translate any documentv1.3 to xhtml2 and from there create html4 and pdf? Can we also include direct support for the subset of xhtml2 that we are gonna use? -- Ferdinand Soethe
Re: [Proposal] Development process and a stable trunk
Thanks everybody for taking the time to respond and giving me a change to re-think and refine my own thoughts on these issues. Here are some comments for a start: - Ignoring of threads (or developments) I'm sorry to say this but I'm simply not able to read everything that's on this list all the time. And even though this might have to do with going kayaking too often in my case :-), I think that with growing volume of project and list this will happen to most of us sooner or later. For me prioritizing stuff in this list is a necessity rather than a choice. And at the moment I can never tell the relevance of a thread to Forrest as a hole. I know that it would be nice if all of us could follow all the threads, but honestly, is that realistic? Also: A lot of people might join the list without the interest or the capacity to follow all our discussion from the start. Following new developments from when a merger is proposed gives them a good interface to cutting-edge forrest development without the bloodloss :-). - When to branch After considering your responses I realize that I need to refine the criteria for branching: Changes should happen in a branch when they - change (not fix) to output - require additional or different input - change (not add) existing configuration options The reason behind this demand is, that all these changes require users and developers to adjust their applications or their coding work in progress. So in order to do that efficiently they should have well defined, finalized and properly documented changes to deal with. In addition I would suggest branching also - when the internal workings of a module are altered in a major way. The reason for this being that anybody also working on, extending or even debugging such a module does not get in the middle of somebody else's major change or has to guesswork about the function of some undocumented new piece of code. - Vote on merging branches I have no problem with the lazy consensus model her. What is more important to me is that fact that at least some developers not involved in the implementation should have looked at (not just 'have had a chance to look at') and tried the new functionality. Now I know that this is hard because you have to get somebody to do this and perhaps even wait for them to do it. But on the other hand I expect this to have a couple of useful side effects: - Documentation and value of the new developed functionality have to be properly balanced or nobody will do the testing. - The time waiting for a tester is often useful to rethink and refine the solution and perhaps even improve on the docs. -- Ferdinand Soethe
Re: Forrest-lenya instance (was Re: Forrest Tuesday)
Thorsten Scherler wrote: On Fri, 2005-08-19 at 00:30 +0100, Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: The wiki worked well for Cocoon. The big advantage is that it is not a synchronous medium so it doesn't matter that we will not all be online at the same time. However, I'd rather see Thorsten get a Lenya instance up and we start using that, both Thorsten and I are keen to push forward on the Doco thing and this could be the first exposure of many devs to Lenya. Yes please. I took this to the Lenya list, there is momentum gathering on Doco and as a result Thorsten has stepped forward to create a Lenya instance for us by Sept. 6th. Thanks Thorsten. You are welcome. http://lenya.zones.apache.org:1/index.html Please test a wee bit. ;-) Logging in as editor for the default publication gave: Unable to get transformer handler for cocoon://lenya-page/default/authoring/index.xml?doctype=homepage at map:serialize type=xhtml - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/lenya/pubs/default/sitemap.xmap:188:44 at map:transform - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/lenya/pubs/default/sitemap.xmap:174:85 at map:transform - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/lenya/pubs/default/sitemap.xmap:172:152 at map:generate - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/lenya/pubs/default/sitemap.xmap:161:165 at map:mount - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/global-sitemap.xmap:408:113 at map:mount - file:/export/home/lenya/src/lenya-1.4.x-forrest/build/lenya/webapp/sitemap.xmap:523:110 We can set up a basic lenya pub for us, where we will use the ac and our working structure (workflow,...). We should keep this pub here in our code base. Then we have as well a starting point for the doco move and the work of Joachim, David et. al.. If you get this started with an initial commit to our SVN I'll have a play. I've installed a local copy of Lenya 1.4 so should be able to experiment with the publicaiton offline, once I have something together I guess I commit to ourt SVN and you will put it into the Lenya zone - is that right? Ross
Re: [Proposal] Development process and a stable trunk
Ross Gardler wrote: ... We need to decide how to use Jira to create this ToDo list and then we need to start actually using it. I'd concentrate on the actually doing stuff part (not directed to you Ross, it's a general remark). After having been on vacation, I now see hundreds of mails with lots of words and very little content, and even ignoring complete threads like I'm already doing is proving to be not enough. If the signal to noise ratio will not improve, we will have more problems with newcomers, and I will be forced to unsubscribe for lack of time. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Proposal] Development process and a stable trunk
Ferdinand Soethe wrote: Thanks everybody for taking the time to respond and giving me a change to re-think and refine my own thoughts on these issues. Here are some comments for a start: - Ignoring of threads (or developments) I'm sorry to say this but I'm simply not able to read everything that's on this list all the time. And even though this might have to do with going kayaking too often in my case :-), I think that with growing volume of project and list this will happen to most of us sooner or later. For me prioritizing stuff in this list is a necessity rather than a choice. And at the moment I can never tell the relevance of a thread to Forrest as a hole. I know that it would be nice if all of us could follow all the threads, but honestly, is that realistic? Also: A lot of people might join the list without the interest or the capacity to follow all our discussion from the start. Following new developments from when a merger is proposed gives them a good interface to cutting-edge forrest development without the bloodloss :-). I agree with everything said and feel that this is what the conclusion of the thread has been. It is the respopnsbility of the PMC to read *all* commits, not *all* mails. We should not *ignore* threads though. I tend to read the first post in a thread, if it is a priority for me I read all subsequent posts otherwise I skin read the subsequent posts. I also have filters set up on my mail client that will detect if someone types my name. So if someone says I wonder what Ross thinks or Ross, how would this fit into plugins or something like that my client flags the message for me. In addition, as you point out well worded subjects are important. I'm not sure about prefixing with a branch name since a discussion about something in a branch is also a discussion about what will end up in core. So it is no less relevant just because it is in a branch. - When to branch After considering your responses I realize that I need to refine the criteria for branching: Changes should happen in a branch when they - change (not fix) to output - require additional or different input - change (not add) existing configuration option In earlier threads (linked to in my prevoius mail) we discussed criteria for branching. I think the conclusion was that it should be up to the individual dev do decide. It isn't really possible to create a set of rules - nothing wrong with examples like those above (and below) though. The reason behind this demand is, that all these changes require users and developers to adjust their applications or their coding work in progress. So in order to do that efficiently they should have well defined, finalized and properly documented changes to deal with. +1, I think Tim expressed this as something like a realeasable trunk does not requrie users to jump through any hoops. In addition I would suggest branching also - when the internal workings of a module are altered in a major way. The reason for this being that anybody also working on, extending or even debugging such a module does not get in the middle of somebody else's major change or has to guesswork about the function of some undocumented new piece of code. - Vote on merging branches I have no problem with the lazy consensus model her. What is more important to me is that fact that at least some developers not involved in the implementation should have looked at (not just 'have had a chance to look at') and tried the new functionality. Since all PMC members have a responsability for reading *all* commits, then (in theory) all developers will ahve watched what was going on in the branch anyeay. There should be no need for a separate review cycle before merge. In my opinion the docs + tests we discussed are more important. Now I know that this is hard because you have to get somebody to do this and perhaps even wait for them to do it. But on the other hand I expect this to have a couple of useful side effects: - Documentation and value of the new developed functionality have to be properly balanced or nobody will do the testing. - The time waiting for a tester is often useful to rethink and refine the solution and perhaps even improve on the docs. Here you are proposing a formal test process before merging. I'm not sure how I feel about this. Speaking personally, I don't have the time to test *all* of other peopls code, they could wait for me for a long time, this will cause problems. I prefer to trust that they have tested it sufficiently before commiting and merging. (longer term I would prefer a proper test suite in Forrest, but that is a whole different thing and should not delay progress on your proposal). Ross
Re: *using* metadata in forrest
Tim Williams wrote: On 8/28/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: That's all right now, it's rough and not incredibly useful at the moment but it should give an idea of where I'm going with it. Since it's not a traditional plugin, more of an example of how to use the xpathgenerator in forrest, I wasn't sure if it was appropriate for the whiteboard or not. How about documenting it in a How To? Even dumping the code into a How To and adding a little padding text would be a great start and since the plugin doesn't do anything itself as yet it will prevent users getting confused by it. It's premature for a How-To as I don't quite have the how figured out as yet. I was hoping to find a home for it so that others might be able to take a look and help me flesh a couple things out. I can figure it out locally then write a how-to though. I understand now, probably best to put it in the whiteboard but don't add it to whiteboard-plugins.xml. That way we have access via SVN but it won't appear on the plugins page or when someone does forrest available-plugins Ross
Refactor sitemaps for XHTML2 and the LM (Re: Forrest Tuesday)
Ferdinand Soethe wrote: Ross Gardler wrote: The *implementation* of the move to XHTML2 would be eased considerably by refactoring our sitemaps to use the locationmap. Why is that? In my limited understanding lm allows to specify the location of a resource in more sophisticated ways, where is the connection? Right now the sitemaps are a complex web of possible locations for many resources, with extensive tests for the existence of a file. These are duplicated across many sitemaps. The LM will remove all of that by having a central file describing the location of resources. That is, there will be only one place to edit as we replace chunks of the sitemap functionality. Tim reports that the project locationmap mount doesn't work properly yet, but unless he tells us otherwise I think we can safely move forward with this refactoring. Not sure this kind of lazy consensus is the right approach here. I understand is that Tim has pointed out a problem with the lm implementation. Should it not be up to us now to demo that this problem has been solved (us of course including Tim :-) rather than expecting Tim to object? No, you misunderstand the issue Tim has identified. As Locationmaps currently stand there is only one locationmap file. Tim is working on allowing that file to import a project locationmap as well. The project locationmap will be able to override the default locationmap, thus users can customise Forrests directory layout without having to redefine the whole thing. Tim is having a problem with this *extension* to the locationmap not with the locationmap itself, which works perfectly. I am +1 on the move to XHTML2 being a primary goal for Forrest Tuesday, but with the provision that w work in a top down approach. That is, we start by creating the stylesheets, templates etc. We should *not* work on the core sitemaps, instead we should focus on a single path through the sitemap and build it as an internal plugin. I'd suggest the path should be DocumentV1.3 as the input format. ... so that using this plugin Forrest will translate any documentv1.3 to xhtml2 and from there create html4 and pdf? Yes (this is how we will provide backward compatability) What I didn't say above is that this will be an internal plugin because it is overriding existing matchers in the sitemaps. These would be moved into core as the first part of the refactoring of the sitemaps to use locationmap. Of course, the conversion of XDoc to XHTML2 would be an input plugin. Can we also include direct support for the subset of xhtml2 that we are gonna use? Sorry, I don't understand the question. Perhaps my poor description above has mislead you. Ross
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
Ferdinand Soethe wrote: David Crossley wrote: I would like to deal with Internal structure is XHTML2 and the associated issues. +1 So far there has been plenty of agreement for this. Clearly (at least in my mind) this work will be done in Forrest:views not in skins, is my mind correct? If so, the internal plugin I referred to in an earlier post would presumably be the internal.views plugin since it already overrides the affected pipelines. --- Is it worth us identifying when we expect to be online during the day? I'm not talking about a commitment, it's just that we may be able to maximise benefit by trying to get online in groups. Unfortunately, that day corresponds with a site visit for me. This means I will probably not be online during the day (BST). I will try and get online at something like (times in BST): 6am - 8am 7.30pm - 11.59pm Ross
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
Ross Gardler wrote: Is it worth us identifying when we expect to be online during the day? I'm not talking about a commitment, it's just that we may be able to maximise benefit by trying to get online in groups. I for one will do blocks throughout the whole day. I will certainly be there for the initial few hours, then away for our evening meal, back until i fall asleep. Then hopefully also do some during our next day. Unfortunately, that day corresponds with a site visit for me. This means I will probably not be online during the day (BST). I will try and get online at something like (times in BST): 6am - 8am 7.30pm - 11.59pm Well the current plan is to start at 9:00 am your time. I think it would be better to always start at 6:00 am. -David
Re: Planning the move to XHTML2 (Re: (FOR-184) Switch to XHTML2))
Nicola Ken Barozzi wrote: David Crossley wrote: Nicola Ken Barozzi wrote: David Crossley wrote: I revised the list, taking the replies into account and adding some new queries. I've now put these into Jira as sub-tasks. Thanks for your input. Ross
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
- Original Message - From: Ross Gardler [EMAIL PROTECTED] To: dev@forrest.apache.org Sent: Monday, August 29, 2005 9:23 PM Subject: Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest)) | David Crossley wrote: | Ross Gardler wrote: | | Is it worth us identifying when we expect to be online during the day? | I'm not talking about a commitment, it's just that we may be able to | maximise benefit by trying to get online in groups. | | | I for one will do blocks throughout the whole day. | I will certainly be there for the initial few hours, | then away for our evening meal, back until i fall asleep. | Then hopefully also do some during our next day. | | | Unfortunately, that day corresponds with a site visit for me. This means | I will probably not be online during the day (BST). I will try and get | online at something like (times in BST): | | 6am - 8am | 7.30pm - 11.59pm | | | Well the current plan is to start at 9:00 am your time. | | Sorry, I thought we were doing midnight to midnight - not sure why I | made that assumption, it clearly states otherwise on | http://forrest.apache.org/forrest-tuesday.html | | I think it would be better to always start at 6:00 am. | | You make the call, I'll fit in with whatever time is defined. I have no | problem running from 9am to 9am instead, I'll just do it the other way | around 7.30pm - 11pm and 6am - 8am (actually I can do until 9am anyway | the following day as I am not on site that day). | | Ross Although I doubt I'll be able to contribute much, I would like to look in on IRC and see whats being said and just say Hello really. I am in Australia, I can be on from 7PM my time which is 12PM noon GMT, with this times, it looks like I will probably miss most of you but I will look in anyway. Gav... -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: Is it worth us identifying when we expect to be online during the day? I'm not talking about a commitment, it's just that we may be able to maximise benefit by trying to get online in groups. I for one will do blocks throughout the whole day. I will certainly be there for the initial few hours, then away for our evening meal, back until i fall asleep. Then hopefully also do some during our next day. Unfortunately, that day corresponds with a site visit for me. This means I will probably not be online during the day (BST). I will try and get online at something like (times in BST): 6am - 8am 7.30pm - 11.59pm Well the current plan is to start at 9:00 am your time. Sorry, I thought we were doing midnight to midnight - not sure why I made that assumption, it clearly states otherwise on http://forrest.apache.org/forrest-tuesday.html I think it would be better to always start at 6:00 am. You make the call, I'll fit in with whatever time is defined. I have no problem running from 9am to 9am instead, I'll just do it the other way around 7.30pm - 11pm and 6am - 8am (actually I can do until 9am anyway the following day as I am not on site that day). Starting at 06:00 is better because that gives people in the European quarter a chance to join the beginning of the ForrestTuesday before going to work. It would be good to have as many people there for the start as possible. If people are still keen at the end of the day, we could close a bit later. Decide at the time. However we do need to close the channel. -David
Re: XHTML2 - let's do it!
David Crossley wrote: CAUTION: I have only skim read the recommendations, I do not consider myself clued in yet. Internationalisation: - Do we also need the i18n? 14. XHTML I18N Attribute Module In our current sitemap, the i18n text is being handled towards the end of the process, so we need to carry the i18n attributes all the way through. I think that we will need this, probably not to support what we have at present, but we are getting an increasing number of requests for i18n support. We may as well consider the future now and reuse what XHTML2 gives us. Entity references: -- Entity references (e.g. ouml; and trade;) in the input are resolved and expanded by the xml parser, so i don't think that the internal mechanism needs to carry them around and know how to resolve them. Does anyone see it differently? I see it as you do. Ross
Re: [Discuss] Seed targets - publication templating
Ross Gardler wrote: Anil Ramnanan wrote: Thorsten Scherler wrote: Another thing is that lenya 1.4.x brings publication templating through the usecase-fw (framework). That means that through a webinterface you can invoke the seeding of new publications. In general the usecase-fw is a very interesting component of lenya. IMO forrest would benefit to adopt the codebase and enable usecase within forrest. Like lenya will benefit from adapting plugins. http://lenya.apache.org/1_4/reference/usecase-framework/index.html The publication templating would be very useful. It would be nice to see the ability to create your own custom site template. Something like: forrest seed-custom mytemplate I agree it owuld be useful, however, my mind is on other things right now and I notice a lack of further comment from others. Perhaps this should go into JIRA so we don't lose this good idea. I have been concerned that this is too much too quick. Lets get some other functionality settled first. I am not keen on replicating code from Lenya at this stage. Perhaps later we can get better interaction with Lenya. -David
Re: XHTML2 - let's do it!
Nicola Ken Barozzi wrote: 10. XHTML Hypertext Module http://www.w3.org/TR/xhtml2/mod-hypertext.html * 10.1. The a element We don't need this, it's use is deprecated in XHTML2 by allowing an href attribute on any element: Linking: In HTML 3, only a elements could be the source and target of hyperlinks. In HTML 4 and XHTML 1, any element could be the target of a hyperlink, but still only a elements could be the source. In XHTML 2 any element can now also be the source of a hyperlink, since href and its associated attributes may now appear on any element. So for instance, instead of lia href=home.htmlHome/a/li, you can now write li href=home.htmlHome/li. Even though this means that the a element is now strictly-speaking unnecessary, it has been retained. - http://www.w3.org/TR/2005/WD-xhtml2-20050527/introduction.html#s_intro_differences I understand that we will, most likely, want to support this within our input formats, but I propose we don't support it internally, it only serves to add more complexity to our stylsheets since we will have to support the @href attribute anyway (it is part of 13. XHTML Hypertext Attributes Module - http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html) Ross
Re: [jira] Commented: (FOR-605) CSS enhancements needed for MOTD area inside Table of Contents
David Crossley wrote: Gav wrote: Also , in regard to the differing screenshot that I get from your version, do you still see it as before or as I now see it (see new screenshot of same page) As before. Hmmm, i thought that your issue report was saying that you had done some tweaks and now it looks better for you. There is something strange happening then. Perhaps browser related. ... testing: yes, that was using Mac FireFox, different on Safari. I will try some other tests later today. , just wondering if something has been done somewhere or possibly you are set up for 800x600 resolution whereas I am on 1024x768.? Nope, this report was on an even bigger resolution screen than yours. Aha, i finally understand what you were meaning by resolution. I do use browser windows that are not full-screen. They are about 800 wide. -David I take it for now I just need to be looking at pelt basic.css and screen.css. Start there, but there are other things involved, e.g. some CSS is generated by forrest, so you may need to look into the xslt and sitemaps. Concentrate on 'pelt' and 'common'. You would learn a lot about forrest mechanisms by following the processing. Personally i would not worry too much about this MOTD layout bug. It would be better to concentrate on the overall CSS cleanup for both the existing skins functionality (but only pelt) and the new views functionality. -David
mail lists activity (Was: [Proposal] Development process and a stable trunk)
Gav wrote: Can I ask, How many people are subscribed to the dev list? How many of those are regular posters and/or contributors? The answer is for my curiosity, but also may enlighten myself and others as to actually how many people are working on this project, it might have a bearing on expected help/workload. Ken shows some statistics: http://people.apache.org/~coar/mlists.html#forrest.apache.org Answering your second question is harder, but Stefano's brilliance will keep you awake all night trying to answer that: http://people.apache.org/~stefano/agora/ Load a few months of forrest-dev archives and then click-and-drag some people. It will show the interactions and who talks to who. As you can see, we are still a small community. -David
[jira] Updated: (FOR-383) Always opens a new browser instance
[ http://issues.apache.org/jira/browse/FOR-383?page=all ] Anil Ramnanan updated FOR-383: -- Attachment: ForrestRunner.290805.diff This allows Eclipse to reuse the same browser instance Always opens a new browser instance --- Key: FOR-383 URL: http://issues.apache.org/jira/browse/FOR-383 Project: Forrest Type: Bug Components: Tool: Eclipse config Versions: 0.7 Reporter: Ross Gardler Priority: Minor Attachments: ForrestRunner.290805.diff When starting Forrest using the Eclipse plugin a new browser window is opened even if there is already one present within the current instance of Eclipse. We should re-use the browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-659) Fully enable XHTML2 in the core
Fully enable XHTML2 in the core --- Key: FOR-659 URL: http://issues.apache.org/jira/browse/FOR-659 Project: Forrest Type: Sub-task Reporter: Ross Gardler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-651) Daisy Repository view throws exception when renewing document list
[ http://issues.apache.org/jira/browse/FOR-651?page=all ] Anil Ramnanan updated FOR-651: -- Attachment: RepositoryView.290805.diff Fix for the problem with refereshing the repoistory view Daisy Repository view throws exception when renewing document list -- Key: FOR-651 URL: http://issues.apache.org/jira/browse/FOR-651 Project: Forrest Type: Bug Components: Tool: Eclipse config Reporter: Ross Gardler Priority: Minor Fix For: 0.8-dev Attachments: RepositoryView.290805.diff When refreshing the document list from a daisy repository using the repository plugin for eclipse the console reports the following exception: org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not permitted. at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.insertBefore(Unknown Source) at com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(Unknown Source) at org.apache.forrest.repository.daisy.RepositoryInterface.SearchRepository(RepositoryInterface.java:50) at org.apache.forrest.repository.ui.views.RepositoryView$5.run(RepositoryView.java:202) at org.eclipse.jface.action.Action.runWithEvent(Action.java:996) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-658) Modify internal.views pluign to use XHTML2 input
Modify internal.views pluign to use XHTML2 input Key: FOR-658 URL: http://issues.apache.org/jira/browse/FOR-658 Project: Forrest Type: Sub-task Components: Plugins (general issues) Reporter: Ross Gardler Priority: Critical -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Email confirmation of issue changes
I notice that every thime I submit or update an issue I get an email from Jira. I have submitted a number of pathches today and I have onle gotten email confirming the last one which I just submitted (http://issues.apache.org/jira/browse/FOR-383). I am sure that the other patches were submitted since they show up when I browse the issues page. Here are the others that I submitted today: http://issues.apache.org/jira/browse/FOR-382 http://issues.apache.org/jira/browse/FOR-651 http://issues.apache.org/jira/browse/FOR-653 Did anyone else experience this ? Anil.
Re: XHTML2 - let's do it!
Ross Gardler wrote: Nicola Ken Barozzi wrote: 10. XHTML Hypertext Module http://www.w3.org/TR/xhtml2/mod-hypertext.html * 10.1. The a element We don't need this, it's use is deprecated in XHTML2 by allowing an href attribute on any element: IMHO we should eventually support every xhtml2 module, but it's not strictly needed. Ok to leave it out for now, and see later to include it via an input module, as it's just a (legacy induced) substitute for span href=/span. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Refactor sitemaps for XHTML2 and the LM (Re: Forrest Tuesday)
On 8/29/05, Ross Gardler [EMAIL PROTECTED] wrote: Ferdinand Soethe wrote: Ross Gardler wrote: The *implementation* of the move to XHTML2 would be eased considerably by refactoring our sitemaps to use the locationmap. Why is that? In my limited understanding lm allows to specify the location of a resource in more sophisticated ways, where is the connection? Right now the sitemaps are a complex web of possible locations for many resources, with extensive tests for the existence of a file. These are duplicated across many sitemaps. The LM will remove all of that by having a central file describing the location of resources. That is, there will be only one place to edit as we replace chunks of the sitemap functionality. Tim reports that the project locationmap mount doesn't work properly yet, but unless he tells us otherwise I think we can safely move forward with this refactoring. Not sure this kind of lazy consensus is the right approach here. I understand is that Tim has pointed out a problem with the lm implementation. Should it not be up to us now to demo that this problem has been solved (us of course including Tim :-) rather than expecting Tim to object? No, you misunderstand the issue Tim has identified. As Locationmaps currently stand there is only one locationmap file. Tim is working on allowing that file to import a project locationmap as well. The project locationmap will be able to override the default locationmap, thus users can customise Forrests directory layout without having to redefine the whole thing. Tim is having a problem with this *extension* to the locationmap not with the locationmap itself, which works perfectly. This is correct, it does *not* effect the refactoring work. Anyway, I hope to have this resolved within the next day or so anyway so that we can mount project-level locationmaps *if* they exist. --tim
[jira] Created: (FOR-653) Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser
Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser Key: FOR-653 URL: http://issues.apache.org/jira/browse/FOR-653 Project: Forrest Type: Improvement Components: Documentation and website Versions: 0.8-dev Reporter: Anil Ramnanan Includes instructions on configuring and using the repository browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Forrest-lenya instance
On Mon, 2005-08-29 at 16:13 +1000, David Crossley wrote: Thorsten Scherler wrote: http://lenya.zones.apache.org:1/index.html Please test a wee bit. ;-) I did login as editor okay, but File-New-xhtml failed the first time, second time was okay. Then the create action failed. The new Cocoon error reporting is excellent. :) yeah I do not understand why that is happening but I have actually the same problem on my local drive. Will need to investigate it. Cheers for the report. -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Created: (FOR-657) Move XDoc processing to an Input plugin
Move XDoc processing to an Input plugin --- Key: FOR-657 URL: http://issues.apache.org/jira/browse/FOR-657 Project: Forrest Type: Sub-task Components: Plugins (general issues) Reporter: Ross Gardler With the move to XHTML2 as our internal format we need to provide an XDoc input plugin that converts from XDoc to XHTML2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-653) Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser
[ http://issues.apache.org/jira/browse/FOR-653?page=all ] Anil Ramnanan updated FOR-653: -- Attachment: eclipse.290805.diff Included documentation on the respository browser Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser Key: FOR-653 URL: http://issues.apache.org/jira/browse/FOR-653 Project: Forrest Type: Improvement Components: Documentation and website Versions: 0.8-dev Reporter: Anil Ramnanan Attachments: eclipse.290805.diff Includes instructions on configuring and using the repository browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-382) Must right click on project root to get Forrest context menu
[ http://issues.apache.org/jira/browse/FOR-382?page=all ] Anil Ramnanan updated FOR-382: -- Attachment: plugin.290805.diff Allows the Forrest menu item to show up when you right click on any item in a project. Must right click on project root to get Forrest context menu Key: FOR-382 URL: http://issues.apache.org/jira/browse/FOR-382 Project: Forrest Type: Bug Components: Tool: Eclipse config Versions: 0.7 Reporter: Ross Gardler Priority: Minor Attachments: plugin.290805.diff The Forrest context menu only appears when right clicking on the root of the project, it should appear when clicking on any item in a Forrest project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-654) Create Schema for XHTML2 subset
Create Schema for XHTML2 subset --- Key: FOR-654 URL: http://issues.apache.org/jira/browse/FOR-654 Project: Forrest Type: Sub-task Reporter: Ross Gardler Priority: Critical We need a RelaxNG schema for the subset of XHTML identified in: http://marc.theaimsgroup.com/?l=forrest-devm=112489488330888w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Profiling Forrest [FOR-572]
Monday, August 29, 2005, 5:21:07 PM, David Crossley wrote:
Ron Blaschke wrote:
David Crossley wrote:
Currently, I am wondering about three things:
- How can the top level pipes be replaced with their profiling
counterparts, without too much hassle?
Perhaps this is possible using an input.xmap
in the plugin. However i don't understand what
you mean by top level.
I was thinking about the map:pipes in sitemap.xmap. Can these be
changed globally by a plugin? Only those parts that are processed
through the profiling pipelines can be seen in the profile.html.
If I understand things correctly, the profiling pipelines put the
collected data into a global store. This data can be extracted by a
profile generator, and tranformed into HTML through some transformers.
- For static site generation, profile.html would need to be the
last page generated.
Normally that order cannot be specified. I wonder if
the java code of the LinkGatherer can be enhanced
to put it last.
Another way would be to add it to the files requested from Cocoon, in
site.xml, like below. But I guess this would only be a temporary
workaround.
java classname=org.apache.cocoon.Main
...
arg value=${project.start-uri}/
arg value=profile.html/
...
/java
Ron
re-defining tasks as subtasks in jira
How do we re-define existing tasks as Sub-Tasks in JIRA? I thought that creating an is part of relationship would make it a subtask but it apparently doesn't. Do you have to create a new sub-tasks and merge it or something? The example I'm working with is FOR-200 (the major task) and FOR-573 (the sub-task of FOR-200). Thanks, --tim
[jira] Updated: (FOR-572) run a memory profiler while forrest is operating
[ http://issues.apache.org/jira/browse/FOR-572?page=all ] Ron Blaschke updated FOR-572: - Attachment: step1_profiling.patch This patch adds partial support for profiling through Cocoon pipelines. You still need to replace the /standard pipes/ with the /profiling pipes/ in sitemap.xmap. The profiling results can be accessed via http://localhost:/profile.html during forrest run. Note that you need to load a page first, to get some profiling data. Also note that after this change profile.html is reserved for the profiling page. This will go away after step 1 below, I guess. Next steps probably are: 1) Refactor profiler.xmap into a (output) plugin, probably including a profile2document stylesheet 2) Find out how to automatically replace the pipes with their profiling counterparts 3) Find out how to best get some profile.html during static site generation Ron run a memory profiler while forrest is operating Key: FOR-572 URL: http://issues.apache.org/jira/browse/FOR-572 Project: Forrest Type: Task Components: Core operations Versions: 0.8-dev Reporter: David Crossley Priority: Critical Fix For: 0.8-dev Attachments: step1_profiling.patch We need to run a memory profiler while forrest is operating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-573) Provide locationmap mounting capability
[ http://issues.apache.org/jira/browse/FOR-573?page=comments#action_12320465 ] Thorsten Scherler commented on FOR-573: --- I tried to rewrite the internal.view plugin with the locationmap, but that was not working like I expected. I only have been able to see the lm rewritting when I did forrest run in the root of the plugin. I reckon it is because of this issue. Is there a an example of the mount in the lm? Provide locationmap mounting capability --- Key: FOR-573 URL: http://issues.apache.org/jira/browse/FOR-573 Project: Forrest Type: Improvement Components: Locationmap Versions: 0.8-dev Reporter: Ross Gardler Assignee: Tim Williams Fix For: 0.8-dev Currently we cannot mount (or import) a locationmap from within another. We need this feature so that we can allow projects and/or plugins to override the default Forrest locationmap in the same way that we can override the default sitemaps. This will then enable us to remve the workaround in map:match pattern=locationmap.xml in main/webapp/sitemap.xmap in which we have the project sitemap completely overriding the forrest locationmap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Email confirmation of issue changes
Anil Ramnanan wrote: I notice that every thime I submit or update an issue I get an email from Jira. I have submitted a number of pathches today and I have onle gotten email confirming the last one which I just submitted (http://issues.apache.org/jira/browse/FOR-383). I am sure that the other patches were submitted since they show up when I browse the issues page. Yes, there appears to be a problem with the mail from Jira today. Here are the others that I submitted today: Thanks fo rthe list, that will help me keep on top of your patches. Ross
locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
On 8/29/05, Thorsten Scherler (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/FOR-573?page=comments#action_12320465 ]
Thorsten Scherler commented on FOR-573:
---
I tried to rewrite the internal.view plugin with the locationmap, but that
was not working like I expected. I only have been able to see the lm
rewritting when I did forrest run in the root of the plugin. I reckon it is
because of this issue.
Is there a an example of the mount in the lm?
I'm replying onlist instead of through JIRA to keep JIRA clean of
free-flowing discussion -- assuming that's desired.
I've pasted a mounting example below. Note that because of another
issue, the lm being mounted *must* exist. I'm hoping to fix that this
evening though. Then the syntax will change to become:
select
mount src=somelocationmap.xml/
/select
That said, I'm not sure if that's causing your issue or not. Are you
saying you the locationmap isn't working when you try it on a
seed-sample site? I actually would have expected it to be the other
way around since plugin-locationmaps have yet to be tested at all and
aren't even being mounted via the workaround AFAIK.
--tim
locationmap xmlns=http://apache.org/forrest/locationmap/1.0;
components
matchers default=lm
matcher
name=lm
src=org.apache.forrest.locationmap.WildcardLocationMapHintMatcher/
/matchers
/components
mount src={project:content}locationmap2.xml/
locator
match pattern=rewriteDemo/**
location src=http://www.burrokeet.org/{1}.xml; /
/match
match pattern=remoteDemo/**.xml
location
src=http://svn.apache.org/repos/asf/forrest/trunk/site-author/content/xdocs/{1}.xml;
/
/match
/locator
/locationmap
Re: re-defining tasks as subtasks in jira
Tim Williams wrote: How do we re-define existing tasks as Sub-Tasks in JIRA? I thought that creating an is part of relationship would make it a subtask but it apparently doesn't. Do you have to create a new sub-tasks and merge it or something? The example I'm working with is FOR-200 (the major task) and FOR-573 (the sub-task of FOR-200). I don't think you can, although I have only just started playing with sub-tasks. I did a quick search on http://www.atlassian.com/support/ and found nothing I reckon the only way is to the is part of relationship or copy and paste the content to the parent issue. We should decide on an issue by issue which way round to do it. I think your suggestion is importnat. I've put in a feature request at Atlassin, if it is somehow possible and I missed it in the support stuff I'm sure they will let me know via the RFE: The issue is http://jira.atlassian.com/browse/JRA-7794 Ross
[jira] Closed: (FOR-383) Always opens a new browser instance
[ http://issues.apache.org/jira/browse/FOR-383?page=all ] Ross Gardler closed FOR-383: Fix Version: 0.8-dev Resolution: Fixed Assign To: Ross Gardler Applied, thanks Always opens a new browser instance --- Key: FOR-383 URL: http://issues.apache.org/jira/browse/FOR-383 Project: Forrest Type: Bug Components: Tool: Eclipse config Versions: 0.7 Reporter: Ross Gardler Assignee: Ross Gardler Priority: Minor Fix For: 0.8-dev Attachments: ForrestRunner.290805.diff When starting Forrest using the Eclipse plugin a new browser window is opened even if there is already one present within the current instance of Eclipse. We should re-use the browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-651) Daisy Repository view throws exception when renewing document list
[ http://issues.apache.org/jira/browse/FOR-651?page=all ] Ross Gardler closed FOR-651: Resolution: Fixed Assign To: Ross Gardler Applied, thanks Daisy Repository view throws exception when renewing document list -- Key: FOR-651 URL: http://issues.apache.org/jira/browse/FOR-651 Project: Forrest Type: Bug Components: Tool: Eclipse config Reporter: Ross Gardler Assignee: Ross Gardler Priority: Minor Fix For: 0.8-dev Attachments: RepositoryView.290805.diff When refreshing the document list from a daisy repository using the repository plugin for eclipse the console reports the following exception: org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not permitted. at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.insertBefore(Unknown Source) at com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(Unknown Source) at org.apache.forrest.repository.daisy.RepositoryInterface.SearchRepository(RepositoryInterface.java:50) at org.apache.forrest.repository.ui.views.RepositoryView$5.run(RepositoryView.java:202) at org.eclipse.jface.action.Action.runWithEvent(Action.java:996) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-653) Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser
[ http://issues.apache.org/jira/browse/FOR-653?page=all ] Ross Gardler closed FOR-653: Fix Version: 0.8-dev Resolution: Fixed Assign To: Ross Gardler Applied, thanks Update Eclipse Plugin Documentation to include information about new features such as the Repository Browser Key: FOR-653 URL: http://issues.apache.org/jira/browse/FOR-653 Project: Forrest Type: Improvement Components: Documentation and website Versions: 0.8-dev Reporter: Anil Ramnanan Assignee: Ross Gardler Fix For: 0.8-dev Attachments: eclipse.290805.diff Includes instructions on configuring and using the repository browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-382) Must right click on project root to get Forrest context menu
[ http://issues.apache.org/jira/browse/FOR-382?page=all ] Ross Gardler closed FOR-382: Resolution: Fixed Assign To: Ross Gardler Applied, thanks Must right click on project root to get Forrest context menu Key: FOR-382 URL: http://issues.apache.org/jira/browse/FOR-382 Project: Forrest Type: Bug Components: Tool: Eclipse config Versions: 0.7 Reporter: Ross Gardler Assignee: Ross Gardler Priority: Minor Attachments: plugin.290805.diff The Forrest context menu only appears when right clicking on the root of the project, it should appear when clicking on any item in a Forrest project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
updating the public forrest web site
Do we have a document equivalent to this? http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto That shows how to publish changes made in site-author to the public facing web site? I assume any committer can do it? Thanks, --tim
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. xsl:template 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: updating the public forrest web site
Tim Williams wrote: Do we have a document equivalent to this? http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto http://svn.apache.org/viewcvs.cgi/forrest/trunk/etc/publishing_our_site.txt?view=markup I *think* this is up to date, David will tell us if it is not (right after he recovers from fainting at the shock of someone helping with his many management tasks ;-) Ross
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
On Mon, 2005-08-29 at 15:39 -0400, Tim Williams wrote:
On 8/29/05, Thorsten Scherler (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/FOR-573?page=comments#action_12320465 ]
Thorsten Scherler commented on FOR-573:
---
I tried to rewrite the internal.view plugin with the locationmap, but that
was not working like I expected. I only have been able to see the lm
rewritting when I did forrest run in the root of the plugin. I reckon it is
because of this issue.
Is there a an example of the mount in the lm?
I'm replying onlist instead of through JIRA to keep JIRA clean of
free-flowing discussion -- assuming that's desired.
I've pasted a mounting example below. Note that because of another
issue, the lm being mounted *must* exist. I'm hoping to fix that this
evening though. Then the syntax will change to become:
select
mount src=somelocationmap.xml/
/select
That said, I'm not sure if that's causing your issue or not. Are you
saying you the locationmap isn't working when you try it on a
seed-sample site? I actually would have expected it to be the other
way around since plugin-locationmaps have yet to be tested at all and
aren't even being mounted via the workaround AFAIK.
Your suspected right.
I added
plugins/org.apache.forrest.plugin.internal.view/src/documentation/content/locationmap.xml
and changed the internal.xmap to use {lm:test}.
When I now change to org.apache.forrest.plugin.internal.view and do
forrest run then everything works fine like I expected.
Now I change my test project and the locationmap {lm:test} do not get
matched anymore within views.
I wonder how the daisy plugin is working from a new seed.
To understand it right, we would have to mount all locationsmap from
plugins from the main lm in forrest, right. Did we thought about
mounting them dynamically?
Thx.
salu2
--tim
locationmap xmlns=http://apache.org/forrest/locationmap/1.0;
components
matchers default=lm
matcher
name=lm
src=org.apache.forrest.locationmap.WildcardLocationMapHintMatcher/
/matchers
/components
mount src={project:content}locationmap2.xml/
locator
match pattern=rewriteDemo/**
location src=http://www.burrokeet.org/{1}.xml; /
/match
match pattern=remoteDemo/**.xml
location
src=http://svn.apache.org/repos/asf/forrest/trunk/site-author/content/xdocs/{1}.xml;
/
/match
/locator
/locationmap
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
Thorsten Scherler wrote: I wonder how the daisy plugin is working from a new seed. The daisy plugin does not provide a locationmap, it is up to the user to do this in their project. This is Ok since the URL of the repository is dependant on the project rather than the plugin. I'd like to make it a config value and provide a plugin locationmap, but that is for the future. To understand it right, we would have to mount all locationsmap from plugins from the main lm in forrest, right. Did we thought about mounting them dynamically? Yes, what Tim is doing right now is a starting point that will allow locationmaps to be mounted in the same way that plugin sitemaps are mounted (i.e. configured at runtime). When the config changes come along I am hoping to be able to enable true dynamic mounting, but again, that is for later. One step at a time. Ross
Re: Automated formatting of XML files
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 :-) 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. -- Web/Blog/Gallery: floatingsun.net
Re: updating the public forrest web site
On 8/29/05, Ross Gardler [EMAIL PROTECTED] wrote: Tim Williams wrote: Do we have a document equivalent to this? http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto http://svn.apache.org/viewcvs.cgi/forrest/trunk/etc/publishing_our_site.txt?view=markup I *think* this is up to date, David will tell us if it is not (right after he recovers from fainting at the shock of someone helping with his many management tasks ;-) I think it is. Atleast I followed it to the word and it worked for me (great job, David!). The first time I tried though, I ran into some svn related issues (don't remember the exact error I got). But its been fine since. Also see this message: http://www.mail-archive.com/dev@forrest.apache.org/msg03955.html -- Web/Blog/Gallery: floatingsun.net
Re: updating the public forrest web site
Ross Gardler wrote: Tim Williams wrote: Do we have a document equivalent to this? http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto The general instructions are the similar, except we don't have a server-side installation where occasional people can generate a site. /etc/publishing_our_site.txt I *think* this is up to date, David will tell us if it is not (right after he recovers from fainting at the shock of someone helping with his many management tasks ;-) :-) ... i will answer this thread immediately. That uses the forrestbot to do it. I have been seeing a problem recently whereby it only commits new files, not changed ones, unless i remove the build directory and get forrestbot to start afresh. So i have resorted to the manual method, which i actually like because one can see the changes. I answered this topic again recently ... rumages through archives: http://marc.theaimsgroup.com/?l=forrest-devm=112374964332446 Lets make a doc for that. -David
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
Thorsten Scherler wrote: On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote: Thorsten Scherler wrote: I wonder how the daisy plugin is working from a new seed. The daisy plugin does not provide a locationmap, it is up to the user to do this in their project. This is Ok since the URL of the repository is dependant on the project rather than the plugin. Actually that is really bad for views and a showstopper to use the lm within views. Right now you have to do so much preparation that another step is just overkill. The activation of views already needs more time then building forrest. I have suggested, many times, that views should go into core in order to remove the multiple dependencies between your plugins. It is precisely because of this kind of complication that plugins are not supposed to have dependencies as argued by Nicola and myself in, for example, http://marc.theaimsgroup.com/?l=forrest-devm=111900690921015w=2 I'd like to make it a config value and provide a plugin locationmap, but that is for the future. Please, no offense, [Hmmm... I'm bracing myself... I've written a reply and come back to remove the reaction parts... ] but when you knew this, how could you suggest that I should refactor the view resolver code with the locationmap? Please, do not get upset that someone does not have the foresight to anticipate every potential hiccup in the development of the project. The reality is that my not forseeing this particular hiccup is no worse than you not foreseeing it - I don't know every detail of the project, just as you do not. If I check in my local version of views that means every project has to copy and paste the internal.view locationmap. Not really copyless. I don't understand what the problem is. Forrest:views are going in core (eventually), therefore the locationmap settings for views should end up in the core Forrest locationmap not some plugin locationmap. What am I missing? In the meantime we have a number of potential solutions: Start a branch and move internal-views into core. This will remove all the dependencies between your plugins as we have always insisted must happen. If you don't want to move it to core yet then we can rely on users copying the locationmap into the project since the plugin is still in the whiteboard and so is not in a finished state. If this is too much for views to be enabled and you still insist on working with the internal plugin model then I'd recomend that we enhance the plugin loading code and, if necessary, the locationmap to mount a lm provided by a plugin. Tell us what you need, we will help you achieve it. Ross
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
On 8/29/05, Thorsten Scherler [EMAIL PROTECTED] wrote:
On Mon, 2005-08-29 at 15:39 -0400, Tim Williams wrote:
On 8/29/05, Thorsten Scherler (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/FOR-573?page=comments#action_12320465
]
Thorsten Scherler commented on FOR-573:
---
I tried to rewrite the internal.view plugin with the locationmap, but
that was not working like I expected. I only have been able to see the lm
rewritting when I did forrest run in the root of the plugin. I reckon it
is because of this issue.
Is there a an example of the mount in the lm?
I'm replying onlist instead of through JIRA to keep JIRA clean of
free-flowing discussion -- assuming that's desired.
I've pasted a mounting example below. Note that because of another
issue, the lm being mounted *must* exist. I'm hoping to fix that this
evening though. Then the syntax will change to become:
select
mount src=somelocationmap.xml/
/select
That said, I'm not sure if that's causing your issue or not. Are you
saying you the locationmap isn't working when you try it on a
seed-sample site? I actually would have expected it to be the other
way around since plugin-locationmaps have yet to be tested at all and
aren't even being mounted via the workaround AFAIK.
Your suspected right.
I added
plugins/org.apache.forrest.plugin.internal.view/src/documentation/content/locationmap.xml
and changed the internal.xmap to use {lm:test}.
When I now change to org.apache.forrest.plugin.internal.view and do
forrest run then everything works fine like I expected.
Now I change my test project and the locationmap {lm:test} do not get
matched anymore within views.
I wonder how the daisy plugin is working from a new seed.
To understand it right, we would have to mount all locationsmap from
plugins from the main lm in forrest, right. Did we thought about
mounting them dynamically?
There hasn't been a use-case for plugin locationmaps yet. It
shouldn't be too difficult to do though. I think the model is already
there with the *.xmap's for plugins, however they are added to a
project, the same approach would be taken along with an exists-based
mounting in forrest:locationmap.xml.
Having said that, I think Ross's reply is the preferred approach --
let's go ahead with views' final destination and get it in the core
via a branch.
Either way, I'm here to help you get this working however you want to proceed.
--tim
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
On 8/29/05, Thorsten Scherler [EMAIL PROTECTED] wrote: On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote: Thorsten Scherler wrote: I wonder how the daisy plugin is working from a new seed. The daisy plugin does not provide a locationmap, it is up to the user to do this in their project. This is Ok since the URL of the repository is dependant on the project rather than the plugin. Actually that is really bad for views and a showstopper to use the lm within views. Right now you have to do so much preparation that another step is just overkill. The activation of views already needs more time then building forrest. I'd like to make it a config value and provide a plugin locationmap, but that is for the future. Please, no offense, but when you knew this, how could you suggest that I should refactor the view resolver code with the locationmap? If I check in my local version of views that means every project has to copy and paste the internal.view locationmap. Not really copyless. To understand it right, we would have to mount all locationsmap from plugins from the main lm in forrest, right. Did we thought about mounting them dynamically? Yes, what Tim is doing right now is a starting point that will allow locationmaps to be mounted in the same way that plugin sitemaps are mounted (i.e. configured at runtime). Tim, I am more then willing to help. I do not want to touch the same classes that you may have changed on your drive. Please tell me how I can assist you. I will try tomorrow the mounting and report back. Maybe I can help enabling it the way you planed Tim. Thanks, it was embarrassingly simple. This was clearly a case of me over-thinking it which, unfortunately, happens more often than I care to admit. I was worried about breaking backwards compatibility and it took me some time to realize that the good old selector should just be used on mounts as well. Anyway, it's done now so if we decide to go the plugin-locationmap-mounting, the foundation is there. --tim
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
On 8/29/05, Ross Gardler [EMAIL PROTECTED] wrote: Thorsten Scherler wrote: On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote: Thorsten Scherler wrote: I wonder how the daisy plugin is working from a new seed. The daisy plugin does not provide a locationmap, it is up to the user to do this in their project. This is Ok since the URL of the repository is dependant on the project rather than the plugin. Actually that is really bad for views and a showstopper to use the lm within views. Right now you have to do so much preparation that another step is just overkill. The activation of views already needs more time then building forrest. I have suggested, many times, that views should go into core in order to remove the multiple dependencies between your plugins. It is precisely because of this kind of complication that plugins are not supposed to have dependencies as argued by Nicola and myself in, for example, http://marc.theaimsgroup.com/?l=forrest-devm=111900690921015w=2 I assume Ross mis-typed here between *your* plugins and really meant between view-related plugins ;) I'd like to make it a config value and provide a plugin locationmap, but that is for the future. Please, no offense, [Hmmm... I'm bracing myself... I've written a reply and come back to remove the reaction parts... ] but when you knew this, how could you suggest that I should refactor the view resolver code with the locationmap? Please, do not get upset that someone does not have the foresight to anticipate every potential hiccup in the development of the project. The reality is that my not forseeing this particular hiccup is no worse than you not foreseeing it - I don't know every detail of the project, just as you do not. Add me to the list of those without foresight -- I failed to think through that the selectors wouldn't work for views, leading you to have to implement locationmap actions wait a minute... now we have a more robust locationmap... shortsightedness ain't so bad sometimes;) If I check in my local version of views that means every project has to copy and paste the internal.view locationmap. Not really copyless. I don't understand what the problem is. Forrest:views are going in core (eventually), therefore the locationmap settings for views should end up in the core Forrest locationmap not some plugin locationmap. What am I missing? In the meantime we have a number of potential solutions: Start a branch and move internal-views into core. This will remove all the dependencies between your plugins as we have always insisted must happen. If you don't want to move it to core yet then we can rely on users copying the locationmap into the project since the plugin is still in the whiteboard and so is not in a finished state. If this is too much for views to be enabled and you still insist on working with the internal plugin model then I'd recomend that we enhance the plugin loading code and, if necessary, the locationmap to mount a lm provided by a plugin. I wonder if there's not another option. It seems like your locations wouldn't collide with anything so would there be any harm in just putting them in the seed locationmap? If so, you could at least put them in there with comments wrapping them. Tell us what you need, we will help you achieve it. +1 --tim
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: ?xml version=1.0? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xalan=http://xml.apache.org/xalan; version=1.0 xsl:output method=xml indent=yes xalan:indent-amount=2/ xsl:strip-space elements=*/ xsl:template match=/ xsl:copy-of select=./ /xsl:template /xsl:stylesheet - Addi
Re: updating the public forrest web site
On 8/29/05, David Crossley [EMAIL PROTECTED] wrote: Ross Gardler wrote: Tim Williams wrote: Do we have a document equivalent to this? http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto The general instructions are the similar, except we don't have a server-side installation where occasional people can generate a site. /etc/publishing_our_site.txt I *think* this is up to date, David will tell us if it is not (right after he recovers from fainting at the shock of someone helping with his many management tasks ;-) :-) ... i will answer this thread immediately. That uses the forrestbot to do it. I have been seeing a problem recently whereby it only commits new files, not changed ones, unless i remove the build directory and get forrestbot to start afresh. So i have resorted to the manual method, which i actually like because one can see the changes. I answered this topic again recently ... rumages through archives: http://marc.theaimsgroup.com/?l=forrest-devm=112374964332446 Lets make a doc for that. -David I'm getting authorization failed on CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap' Any ideas? I followed the automated instructions. I didn't try the manual process you described in the linked email yet. --tim
Re: updating the public forrest web site
Tim Williams wrote: I'm getting authorization failed on CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap' Any ideas? I followed the automated instructions. Can you do a normal checkout of https://...forrest/site ? You will need that anyway for the occasions where you don't want to use the forrestbot. -David I didn't try the manual process you described in the linked email yet. --tim
Re: locationmap mounting [was: Re: [jira] Commented: (FOR-573) Provide locationmap mounting capability
I've taken an initial look at the plugin code and it seems that we
could get this working quickly if it's desired. It looks like we just
need to do roughly the following:
1) create a new target configure-locationmap in targets/plugins.xml
2) obviously make the call to it probably in configure plugin
3) create an pluginMountLmSnippet.xsl
4) add the following to forrest:locationmap
select
mount src={project:temp-dir}/locationmap.xml/
/select
5) cross fingers and test...
Having written this, I'm still not convinced it's needed. The only
use-case I can think of is the views and, since that's a temporary
use-case, I'm not sure it's worth it.
--tim
On 8/29/05, Tim Williams [EMAIL PROTECTED] wrote:
On 8/29/05, Ross Gardler [EMAIL PROTECTED] wrote:
Thorsten Scherler wrote:
On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
I wonder how the daisy plugin is working from a new seed.
The daisy plugin does not provide a locationmap, it is up to the user to
do this in their project. This is Ok since the URL of the repository is
dependant on the project rather than the plugin.
Actually that is really bad for views and a showstopper to use the lm
within views. Right now you have to do so much preparation that another
step is just overkill. The activation of views already needs more time
then building forrest.
I have suggested, many times, that views should go into core in order to
remove the multiple dependencies between your plugins. It is precisely
because of this kind of complication that plugins are not supposed to
have dependencies as argued by Nicola and myself in, for example,
http://marc.theaimsgroup.com/?l=forrest-devm=111900690921015w=2
I assume Ross mis-typed here between *your* plugins and really meant
between view-related plugins ;)
I'd like to make it a config value and provide a plugin locationmap, but
that is for the future.
Please, no offense,
[Hmmm... I'm bracing myself... I've written a reply and come back to
remove the reaction parts... ]
but when you knew this, how could you suggest that I
should refactor the view resolver code with the locationmap?
Please, do not get upset that someone does not have the foresight to
anticipate every potential hiccup in the development of the project. The
reality is that my not forseeing this particular hiccup is no worse than
you not foreseeing it - I don't know every detail of the project, just
as you do not.
Add me to the list of those without foresight -- I failed to think
through that the selectors wouldn't work for views, leading you to
have to implement locationmap actions wait a minute... now we have
a more robust locationmap... shortsightedness ain't so bad sometimes;)
If I check in my local version of views that means every project has to
copy and paste the internal.view locationmap. Not really copyless.
I don't understand what the problem is. Forrest:views are going in core
(eventually), therefore the locationmap settings for views should end up
in the core Forrest locationmap not some plugin locationmap. What am I
missing?
In the meantime we have a number of potential solutions:
Start a branch and move internal-views into core. This will remove all
the dependencies between your plugins as we have always insisted must
happen.
If you don't want to move it to core yet then we can rely on users
copying the locationmap into the project since the plugin is still in
the whiteboard and so is not in a finished state.
If this is too much for views to be enabled and you still insist on
working with the internal plugin model then I'd recomend that we enhance
the plugin loading code and, if necessary, the locationmap to mount a lm
provided by a plugin.
I wonder if there's not another option. It seems like your locations
wouldn't collide with anything so would there be any harm in just
putting them in the seed locationmap? If so, you could at least put
them in there with comments wrapping them.
Tell us what you need, we will help you achieve it.
+1
--tim
Re: updating the public forrest web site
On 8/29/05, David Crossley [EMAIL PROTECTED] wrote: Tim Williams wrote: I'm getting authorization failed on CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap' Any ideas? I followed the automated instructions. Can you do a normal checkout of https://...forrest/site ? Yeah, that worked fine, no problems. Didn't even ask for credentials. You will need that anyway for the occasions where you don't want to use the forrestbot. -David
Re: Automated formatting of XML files
addi wrote: Diwaker Gupta wrote: 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. But we cannot do such cleanup automatically. I do agree that we can have tools to assist us, even stand-alone build targets. 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. Expert, no. I wonder if Saxon has better indenting. Google found discussion about whitespace and blank lines http://saxon.sourceforge.net/saxon7.4/changes.html By the way, there is a tool called CodeWrestler started by a fellow ASF committer. It is a framework for adding code management modules. For example there is one module whose sole job is to strip trailing whitespace from a set of files. I like this approach. http://henning.schmiedehausen.org/wingnut-diaries/archives/14 -David
Re: updating the public forrest web site
Tim Williams wrote: David Crossley wrote: Tim Williams wrote: I'm getting authorization failed on CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap' Any ideas? I followed the automated instructions. Can you do a normal checkout of https://...forrest/site ? Yeah, that worked fine, no problems. Didn't even ask for credentials. I just removed my site-author/build to get rid of forrestbot's work area and am in the process of trying again. Will report back. Please give some context about your error. I presume this is the 'deploy' stage. -David
Re: updating the public forrest web site
On 8/29/05, David Crossley [EMAIL PROTECTED] wrote: Tim Williams wrote: David Crossley wrote: Tim Williams wrote: I'm getting authorization failed on CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap' Any ideas? I followed the automated instructions. Can you do a normal checkout of https://...forrest/site ? Yeah, that worked fine, no problems. Didn't even ask for credentials. I just removed my site-author/build to get rid of forrestbot's work area and am in the process of trying again. Will report back. Please give some context about your error. I presume this is the 'deploy' stage. Yeah it's the deploy stage. I did the build stage and it worked. I've pasted in the complete session here. --tim C:\src\apache-forrest-trunk-s\site-authorforrest -f publish.xml deploy Apache Forrest. Run 'forrest -projecthelp' to list options Buildfile: publish.xml deploy.svn: svn: warning: 'live-sites.html' is already under version control svn: warning: 'live-sites.pdf' is already under version control svn: warning: 'abs-linkmap' is already under version control svn: warning: 'tools\eclipse.html' is already under version control svn: warning: 'tools\eclipse.pdf' is already under version control svn: warning: 'committed-1.png' is already under version control svn: warning: 'abs-menulinks' is already under version control svn: warning: 'docs_0_70\linking.pdf' is already under version control svn: warning: 'docs_0_70\your-project.pdf' is already under version control svn: warning: 'docs_0_70\primer.pdf' is already under version control svn: warning: 'mail-lists.html' is already under version control svn: warning: 'mail-lists.pdf' is already under version control svn: warning: 'dtdx\document-v20.pdf' is already under version control svn: warning: 'dtdx\document-v12.pdf' is already under version control svn: warning: 'dtdx\document-v13.pdf' is already under version control svn: warning: 'skin\print.css' is already under version control svn: warning: 'skin\profile.css' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2searchbox-3searchbox.png' is alread y under version control svn: warning: 'skin\images\rc-t-r-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2tab-unselected-3tab-unselected.png' is already under version control svn: warning: 'skin\images\rc-t-r-5-1header-2searchbox-3searchbox.png' is alread y under version control svn: warning: 'skin\images\rc-t-r-5-1header-2tab-unselected-3tab-unselected.png' is already under version control svn: warning: 'skin\images\rc-b-l-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-b-r-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-t-r-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-b-r-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\screen.css' is already under version control svn: warning: 'skin\basic.css' is already under version control svn: 'M pluginDocs\plugins_0_70\org.apache.forrest.plugin.internal.IMSManife st\repositoryCommand\getSCO\HowTo\repositoryURI\www.burrokeet.org\repositoryData ' is not a working copy Result: 1 svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap': authoriz ation failed (https://svn.apache.org) BUILD FAILED C:\src\apache-forrest-trunk-s\tools\forrestbot\core\deploy.xml:157: com.alternat ecomputing.jsvn.command.CommandException: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap': authoriz ation failed (https://svn.apache.org) Total time: 39 seconds C:\src\apache-forrest-trunk-s\site-author
[jira] Resolved: (FOR-573) Provide locationmap mounting capability
[ http://issues.apache.org/jira/browse/FOR-573?page=all ] Tim Williams resolved FOR-573: -- Resolution: Fixed With the addition of selector based mounting, this one is complete. Provide locationmap mounting capability --- Key: FOR-573 URL: http://issues.apache.org/jira/browse/FOR-573 Project: Forrest Type: Improvement Components: Locationmap Versions: 0.8-dev Reporter: Ross Gardler Assignee: Tim Williams Fix For: 0.8-dev Currently we cannot mount (or import) a locationmap from within another. We need this feature so that we can allow projects and/or plugins to override the default Forrest locationmap in the same way that we can override the default sitemaps. This will then enable us to remve the workaround in map:match pattern=locationmap.xml in main/webapp/sitemap.xmap in which we have the project sitemap completely overriding the forrest locationmap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: updating the public forrest web site
Tim Williams wrote: C:\src\apache-forrest-trunk-s\site-authorforrest -f publish.xml deploy Apache Forrest. Run 'forrest -projecthelp' to list options Buildfile: publish.xml deploy.svn: svn: warning: 'live-sites.html' is already under version control svn: warning: 'live-sites.pdf' is already under version control svn: warning: 'abs-linkmap' is already under version control svn: warning: 'tools\eclipse.html' is already under version control svn: warning: 'tools\eclipse.pdf' is already under version control svn: warning: 'committed-1.png' is already under version control svn: warning: 'abs-menulinks' is already under version control svn: warning: 'docs_0_70\linking.pdf' is already under version control svn: warning: 'docs_0_70\your-project.pdf' is already under version control svn: warning: 'docs_0_70\primer.pdf' is already under version control svn: warning: 'mail-lists.html' is already under version control svn: warning: 'mail-lists.pdf' is already under version control svn: warning: 'dtdx\document-v20.pdf' is already under version control svn: warning: 'dtdx\document-v12.pdf' is already under version control svn: warning: 'dtdx\document-v13.pdf' is already under version control svn: warning: 'skin\print.css' is already under version control svn: warning: 'skin\profile.css' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2searchbox-3searchbox.png' is alread y under version control svn: warning: 'skin\images\rc-t-r-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\images\rc-t-l-5-1header-2tab-unselected-3tab-unselected.png' is already under version control svn: warning: 'skin\images\rc-t-r-5-1header-2searchbox-3searchbox.png' is alread y under version control svn: warning: 'skin\images\rc-t-r-5-1header-2tab-unselected-3tab-unselected.png' is already under version control svn: warning: 'skin\images\rc-b-l-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-b-r-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-t-r-15-1body-2menu-3menu.png' is already under ver sion control svn: warning: 'skin\images\rc-b-r-5-1header-2tab-selected-3tab-selected.png' is already under version control svn: warning: 'skin\screen.css' is already under version control svn: warning: 'skin\basic.css' is already under version control I gather that these warnings are because these are changed files that are being re-added to svn. Forrestbot could be smarter there, but it works. I cannot explain why your machine has the *.png changes, but i have seen such issues at ASF Infrastructure where there are a few different people publishing the site. Anyway, that is not today's problem. svn: 'M pluginDocs\plugins_0_70\org.apache.forrest.plugin.internal.IMSManife st\repositoryCommand\getSCO\HowTo\repositoryURI\www.burrokeet.org\repositoryData ' is not a working copy I have never seen that in my 'forrestbot deploy' and i don't see it today either. Nor this next error. All that is can suggest is that you remove site-author/build/ and site-author/work/ and try again. Result: 1 svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap': authoriz ation failed (https://svn.apache.org) BUILD FAILED C:\src\apache-forrest-trunk-s\tools\forrestbot\core\deploy.xml:157: com.alternat ecomputing.jsvn.command.CommandException: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/263875/forrest/site/abs-linkmap': authoriz ation failed (https://svn.apache.org) Total time: 39 seconds -- Here is what happened for me today. All as expected ... [site-author]$ forrest -f publish.xml deploy Apache Forrest. Run 'forrest -projecthelp' to list options Buildfile: publish.xml deploy.svn: Copying 398 files to /svn/asf/forrest/site-author/work/svn-deploy/forrest-docs svn: warning: 'live-sites.html' is already under version control svn: warning: 'plan/internal-xhtml.html' is already under version control svn: warning: 'plan/internal-xhtml.pdf' is already under version control svn: warning: 'live-sites.pdf' is already under version control svn: warning: 'docs_0_80/faq.pdf' is already under version control svn: warning: 'docs_0_80/faq.html' is already under version control svn: warning: 'docs_0_80/faq.xml' is already under version control deploy: BUILD SUCCESSFUL - Then i did 'svn update' and got Ross' changes to xdocs/tools/eclipse.xml source, and forrestbot did another successful build and deploy. So all is well at my end. -David
[jira] Commented: (FOR-572) run a memory profiler while forrest is operating
[ http://issues.apache.org/jira/browse/FOR-572?page=comments#action_12320521 ] David Crossley commented on FOR-572: Thanks. Applied patch step1_profiling.patch (3 kb) run a memory profiler while forrest is operating Key: FOR-572 URL: http://issues.apache.org/jira/browse/FOR-572 Project: Forrest Type: Task Components: Core operations Versions: 0.8-dev Reporter: David Crossley Priority: Critical Fix For: 0.8-dev Attachments: step1_profiling.patch We need to run a memory profiler while forrest is operating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
