Re: [site] No commons build
On 3/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. The problem with this approach is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. IMO this isn't that much of an improvement on having to check out commons-build. Plus as someone else mentioned, it puts additional load on the apache hardware. Seems to me that for the few people that build from source we're removed one issue and added another (need online connection to build) and for everyone we've added an issue when viewing the docs. I just don't see how this can be considered improving the situation. Also -1 to having the docs depend on javascript. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
Also -1 to having the docs depend on javascript. I am also -1 (PMC binding vote) -- James Mitchell EdgeTech, Inc. http://edgetechservices.net/ 678.910.8017 Skype: jmitchtx On Mar 16, 2006, at 9:24 AM, Niall Pemberton wrote: On 3/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. The problem with this approach is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. IMO this isn't that much of an improvement on having to check out commons-build. Plus as someone else mentioned, it puts additional load on the apache hardware. Seems to me that for the few people that build from source we're removed one issue and added another (need online connection to build) and for everyone we've added an issue when viewing the docs. I just don't see how this can be considered improving the situation. Also -1 to having the docs depend on javascript. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
Another problem is the new commons menus doesn't work with distros that include their site with the docs - I just checked commons logging and none of the commons entries work - it needs to be changed to absolute urls, rather than relative. Niall On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. The problem with this approach is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. IMO this isn't that much of an improvement on having to check out commons-build. Plus as someone else mentioned, it puts additional load on the apache hardware. Seems to me that for the few people that build from source we're removed one issue and added another (need online connection to build) and for everyone we've added an issue when viewing the docs. I just don't see how this can be considered improving the situation. Also -1 to having the docs depend on javascript. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the snip/ The problem with this approach is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. IMO this isn't that much of an improvement on having to check out commons-build. Plus as someone else mentioned, it puts additional load on the apache hardware. Seems to me that for the few people that build from source we're removed one issue and added another (need online connection to build) and for everyone we've added an issue when viewing the docs. I just don't see how this can be considered improving the situation. snap/ Agreed, I haven't tried it yet, but hopefully will this weekend and post additional comments, if any. Also -1 to having the docs depend on javascript. snip/ I'm -1 here as well (in case anyone was spending time on javascript based docs). -Rahul Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
OK I fixed this and uploaded a new version. http://svn.apache.org/viewcvs?rev=386376view=rev Niall - Original Message - From: Niall Pemberton [EMAIL PROTECTED] Sent: Thursday, March 16, 2006 3:08 PM Another problem is the new commons menus doesn't work with distros that include their site with the docs - I just checked commons logging and none of the commons entries work - it needs to be changed to absolute urls, rather than relative. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
I have implemented an alternative approach in Validator that uses an svn:external to pull in the commons-build. http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg76982.html http://svn.apache.org/viewcvs.cgi?rev=386450view=rev I set up a new shared-build directory in commons-build and created an svn:external to pull in that directory. Anything that gets dropped in shared-build will be automatically pulled into Validator (or any other component that uses it) via the svn:external. This has the benefit of removing commons-build, but not introducing the requirement to be online to build or view the docs properly. Niall On 3/16/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. The problem with this approach is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. IMO this isn't that much of an improvement on having to check out commons-build. Plus as someone else mentioned, it puts additional load on the apache hardware. Seems to me that for the few people that build from source we're removed one issue and added another (need online connection to build) and for everyone we've added an issue when viewing the docs. I just don't see how this can be considered improving the situation. Also -1 to having the docs depend on javascript. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
Niall Pemberton wrote: Another problem is the new commons menus doesn't work with distros that include their site with the docs - I just checked commons logging and none of the commons entries work - it needs to be changed to absolute urls, rather than relative. I chose relative URLs deliberatley to avoid the external links in the commons menu section. However, you are correct and these have to be absolute. I have adjusted the project.css to remove the external link image from all links in the commons menu div to get around this change. Niall Pemberton wrote: I have implemented an alternative approach in Validator that uses an svn:external to pull in the commons-build. I set up a new shared-build directory in commons-build and created an svn:external to pull in that directory. Anything that gets dropped in shared-build will be automatically pulled into Validator (or any other component that uses it) via the svn:external. This has the benefit of removing commons-build, but not introducing the requirement to be online to build or view the docs properly. This fails in three ways for me: 1) Eclispe doesn't pick up the svn:external and use it. Thus validator won't site build from an svn checkout in the most popular IDE. 2) The dtd is still referenced by a relative path. This causes maven issues and thus complicates our lives. 3) This setup requires a rebuild for every ApacheCon type event. As can be seen from the number of commons sites which still reference ApacheCon 2005, this mechanism just doesn't scale/work. Referencing a single central css file handles this scenario. Niall Pemberton wrote: The problem with this approach [online files] is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. snip What proportion of people view the site offline? Its got to be fairly small. And the only thing they'll see is that the site style changes a little. IMHO thats not a big deal. What proportion of people need to build the site offline? A tiny number. Is it worth the extra hassle to deal with it? (And in fact all they have to do is to remove the dtd and entity references from navigation .xml) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
OK I'm going to stop trying to swim against the flow. Niall On 3/16/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Niall Pemberton wrote: Another problem is the new commons menus doesn't work with distros that include their site with the docs - I just checked commons logging and none of the commons entries work - it needs to be changed to absolute urls, rather than relative. I chose relative URLs deliberatley to avoid the external links in the commons menu section. However, you are correct and these have to be absolute. I have adjusted the project.css to remove the external link image from all links in the commons menu div to get around this change. Niall Pemberton wrote: I have implemented an alternative approach in Validator that uses an svn:external to pull in the commons-build. I set up a new shared-build directory in commons-build and created an svn:external to pull in that directory. Anything that gets dropped in shared-build will be automatically pulled into Validator (or any other component that uses it) via the svn:external. This has the benefit of removing commons-build, but not introducing the requirement to be online to build or view the docs properly. This fails in three ways for me: 1) Eclispe doesn't pick up the svn:external and use it. Thus validator won't site build from an svn checkout in the most popular IDE. 2) The dtd is still referenced by a relative path. This causes maven issues and thus complicates our lives. 3) This setup requires a rebuild for every ApacheCon type event. As can be seen from the number of commons sites which still reference ApacheCon 2005, this mechanism just doesn't scale/work. Referencing a single central css file handles this scenario. Niall Pemberton wrote: The problem with this approach [online files] is that as well as requiring an online connection to build components, it also requires a online connection to view the docs properly. snip What proportion of people view the site offline? Its got to be fairly small. And the only thing they'll see is that the site style changes a little. IMHO thats not a big deal. What proportion of people need to build the site offline? A tiny number. Is it worth the extra hassle to deal with it? (And in fact all they have to do is to remove the dtd and entity references from navigation .xml) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
On Wed, 2006-03-15 at 00:12 +, Stephen Colebourne wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. Commons [HttpClient] converted as well. Oleg I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] No commons build
Commons Jexl done. On 3/16/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2006-03-15 at 00:12 +, Stephen Colebourne wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. Commons [HttpClient] converted as well. Oleg I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris
RE: [site] No commons build
Hi Stephen, Stephen Colebourne wrote on Wednesday, March 15, 2006 1:12 AM: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! Don't forget, that some user's are surfing without JavaScript. This is even more true in corporate environments. E.g. in my company there's a filter installed in the firewall (SurfinGate from FinJan), that strips off suspicious JavaScript. In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
