Re: [RT] Serving Apache Forrest site from live Forrest
Nicola Ken Barozzi wrote: One thing I like about Forrest is that it's not only a static site generation engine, but it's capable of serving the site live. Changes are instantaneous, bandwith is perserved, and dynamic content can be employed. IMHO every Apache project that produces something it can use for itself *should* actually use it, like HTTPD does. This gives the team something to work collectively on, and a base that keeps the project adherent to actual needs. IOW, I would like to see the Forrest website served of a live Forrest instance. To do this, even before talking about logistics and permissions, we have to be sure that it's not going to cause problems, even in high load, and be able to administer it. Before we can seriously start to consider using it live, we should at least have the following: 1 - knowledge of the memory it's going to need and use 2 - have no known memory leakage (to be tested) 3 - have caching turned on 4 - know what to do when upgrading the version 5 - decide where it's going to get the site from 6 - other? After that, it would be beneficial to be able to serve multiple sites on a single Forrest instance, so that we can have other projects join and have their site served. This last point (seving multiple sites from one Forrest instance) is important even without moving Forrest to a live server (I'm +1 on this). Right now we have various styleguides in Forrest and if I need to run them at once I have to start Forrest/jetty with different ports. Opened a feature request for this, to not clutter this thread: http://issues.cocoondev.org/browse/FOR-490 Cheers Johannes Thoughts, comments, opinions? -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch User Interface Tuning von Joachim Machate Michael Burmester www.user-interface-tuning.de
[JIRA] Created: (FOR-490) serve multiple sites on a single Forrest instance
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-490 Here is an overview of the issue: - Key: FOR-490 Summary: serve multiple sites on a single Forrest instance Type: New Feature Status: Unassigned Priority: Major Project: Forrest Components: Core operations Fix Fors: 0.8 Versions: 0.8 Assignee: Reporter: Johannes Schaefer Created: Tue, 3 May 2005 2:06 AM Updated: Tue, 3 May 2005 2:06 AM Description: Nicola Ken Barozzi wrote: After that, it would be beneficial to be able to serve multiple sites on a single Forrest instance, so that we can have other projects join and have their site served. This last point (seving multiple sites from one Forrest instance) is important even without moving Forrest to a live server (I'm +1 on this). Right now we have various styleguides in Forrest and if I need to run them at once I have to start Forrest/jetty with different ports. (From Thread [RT] Serving Apache Forrest site from live Forrest on dev-list. Will add link later.) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Why are navigational element are not static when scrolling long pages?
Ferdinand Soethe wrote: My point: Making use of the only purpose we came up with for the current mechanism (being able to have menus longer than the page) will create an extremely user-unfriedly page because opening a menu item at the bottom of such a menu - requires the user to scroll the page (not really menu-like and a drag to do) - and will scroll the tab bar out of sight if he does So to get an idea of the content of a complete site (by browsing menus and tabs) requires constant change between clicking and scrolling action. Conclusion: I see this as a very strong reason to change the default in pelt so that header and menu remain in place when you scroll content (and make the current setting an option). Such a change will have to be taken to a vote since it will affect a great many users when they upgrade. However, adding a configuration option allowing it to be turned on would not need a vote. But a vote would be meaningless unless someone finds a solution that is cross browser compatible. I'd suggest finding the solution, adding it as a configuration option and then, if you still want to, take it to a vote to make it the default. In a second step enhance the menueing system so support column breaks or perhaps even break automatically when the number of items doesn't fit on the screen. Again, if you find a way of doing this in a cross-browser compatible way I'd be all for it. Sounds tough to me though. Ross
Re: Inkonsistency in implementation of default file and site.xml and what to do about it
Ferdinand Soethe wrote: Sorry, this needs to be long (and dirty) in a freshly seeded site change site.xml to site label=Demo Site xmlns=http://apache.org/forrest/linkmap/1.0; tab= menu1 label=Menu 1 page1 label=Page 1 href=page1.html/ page2 label=Page 2 href=page2.html/ /menu1 /site Place these files in the xdocs dir index.xml page1.xml page2.xml site.xml tabs.xml Now do a forrest. In build site you will get the following files which is perfect because the first file in site will become the start page of our statically rendered site. linkmap.html linkmap.pdf page1.html page1.pdf page2.html page2.pdf Now do a forrest run Unfortunately that is where the trouble begins. Calling just localhost: Forrest will load index.html or - if you remove it - give you an ugly error message. Same site two different results. Shouldn't be, should it? Now looking at ways to fix this I'll consider Ross's suggestions one by one: From cli.xconf: !--+ | Specifies the filename to be appended to URIs that | refer to a directory (i.e. end with a forward slash). +-- default-filenameindex.html/default-filename This changes the default-name for all directory-only URIs, so changing it to page1.html will technically solve our problem. But then who wants to change that for all the pages just to be able to have a non-standard start-up page. And what about the confusion when the buyer of a CD-documentation will find a start-me.html in every subdirectory. Good point, but this need not be changed unless you want to change the default in every page. One of your use cases was that a non-English site might not want to use index.html, if this were the case then that would be the case for *every* directory wouldn't it? Also from sitemap.xmap: map:match pattern= map:redirect-to uri=index.html / /map:match map:match type=regexp pattern=^.+/$ map:redirect-to uri=index.html/ /map:match This is more promising since pattern= will only apply to http://myserver and not to http://myserver/mydir (I think). Correct Problem is the second pattern for stepping back up directories by entering a '..'-URI. It would have to be replaced by two different patterns for first level subdirs (use same setting as pattern=) and other levels (keep index.html). That's not what the second pattern means. If you request subdir/../xyz.html the request that Cocoon sees is xyz.html. That is the .. is resolved before the match is attempted. The pattern ^.+/$ is a regular expression (see type=regexp). It means: '^' - beginning of line '.' - any single character (except a newline) '+' - one or more '/' - a '/' character '$' - end of line so we match any pattern that has one or more characters of any type *and* which ends in a '/' character. So, to achieve what you need simply create a project sitemap with: map:match pattern= map:redirect-to uri=start-here.html / /map:match This will result in the site index page becoming start-here.html but all subdirectories defaulting to index.html. (My) Conclusion: None of this is nice or easy to do or explain. Is it easier now I have explained it more completely? So until somebody writes a patch that will derive the name of the first project page from the first file url in site.xml (or an attribute 'startpage' in the site-element). I very much doubt that patch will appear since we cannot assume that site.xml will be present. It is possible to do it with a fallback to using index.html but since it cusomisation is simple why do we need it? I suggest to pretend that it is rigid and keep the note in site.xml as it is. I am -1 on such documentation. If we document that something is not possible it means that people who need that feature do not pursue it. As you see above, the Open Source way is to discuss an issue to find a solution. Generally the community will come up with a good solution and this issue is a great example of how that works. If you read back over your original thread you will find that your questions have prompted us to discover a solution (yet to be tested, but I am sure you will do that). In addition, some readers of this thread may have learnt a little more about how Forrest works (I certainly didn't know how to do this until you asked the question). Furthermore, a problem in the way the skins work has been highlighted since they use a hard coded version of the index.html string (this can easily be changed if my suggestion above actually works). It is possible that if the dopcumentation had explicitly stated that it *has* to be index.html this discussion, and the resulting improvement of Forrest, may never have happened. Forrest was designed from the ground up to be configurable. There is nearly always a way to configure it to work how you need it. It's just that we may not know how yet. Ross
Re: loggin error in last part of static site generation
Ferdinand Soethe wrote: in a freshly seeded site?! * [68/1][0/0] 0.281s 22.6Kb samples/linking.pdf * [69/0][0/0] 0.1s 3.2Kb samples/index.pdf Logging Error: Writing event to closed stream. Total time: 0 minutes 24 seconds, Site size: 403.728 Site pages: 59 -- Static site was successfully generated at: P:\Forrests\Tests\site\build\site -- http://issues.cocoondev.org/browse/FOR-465 Ross
Re: Is OOo license compatible with ASL?
David Crossley wrote: Ross, would you please take this up on [EMAIL PROTECTED] This is the first time that i have heard discussion of this SISSL license. Sure, I'll report back when we have an answer. In the meantime, if anyone is interested in the (alpha) MSOffice plugin I can make it available through Burrokeet. Ross
Re: Where to change comments to configuration files
Ferdinand Soethe wrote: Ross Gardler wrote: RG Best to change it in all occurances of the file as people could look at RG any of the official Apache docs for guidance. Added info to files in fresh-site and site author. I'd rather not do this in the future but instead prefer for us to agree that we will maintain the 'nice' documented version of files in fresh site since doing everything twice seems such a waste of time. With search and replace across multiple files it's easy, as long as we ensure that the text in each file is identical (which it will be if we use search and replace tools). However, I do agree that there is an overhead here. RG As I mentioned on the user list - be sure to add info abot how to change RG this behaviour too. This is not a limitation that is rigid. in design. Have not added this to the comment for now because there seems to be no easy answer to the point where it is in fact rigid. I'll attach more info on that to the relevant thread. I'm -1 on the current comment as it gives the impression that it *can't* be changed. This is bad. If someone needs to change it and they read that comment then they will not bother to search the docs/ask on the mailing lists. In my opinion it's better to have something undocumented (and therefore prompt questions) than to have it incorrectly documented. Ross
Re: Why are navigational element are not static when scrolling long pages?
Ferdinand Soethe wrote: My point: Making use of the only purpose we came up with for the current mechanism (being able to have menus longer than the page) will create an extremely user-unfriedly page because opening a menu item at the bottom of such a menu - requires the user to scroll the page (not really menu-like and a drag to do) - and will scroll the tab bar out of sight if he does So to get an idea of the content of a complete site (by browsing menus and tabs) requires constant change between clicking and scrolling action. Conclusion: I see this as a very strong reason to change the default in pelt so that header and menu remain in place when you scroll content (and make the current setting an option). Such a change will have to be taken to a vote since it will affect a great many users when they upgrade. However, adding a configuration option allowing it to be turned on would not need a vote. But a vote would be meaningless unless someone finds a solution that is cross browser compatible. I'd suggest finding the solution, adding it as a configuration option and then, if you still want to, take it to a vote to make it the default. In a second step enhance the menueing system so support column breaks or perhaps even break automatically when the number of items doesn't fit on the screen. Again, if you find a way of doing this in a cross-browser compatible way I'd be all for it. Sounds hard to me though. Ross
Re: Does Forrest delete build/site before adding new files?
Ferdinand Soethe wrote: After doing some radical changes in xdocs I noticed that there was still an old index.html in build/site that was not updated because it was no longer part of the site. It should definitely have been removed. It doesn't by default for performance reasons. During development it is usually not important if the odd file is left hanging and cleaning a directory with a few thousand files in it can take quite some time. If you want to do a clean build then do 'forrest clean site' Ross
Re: Why are navigational element are not static when scrolling long pages?
Ross Gardler wrote: RG I'd suggest finding the solution, adding it as a configuration option RG and then, if you still want to, take it to a vote to make it the default. Sounds good to me since such a change would only make sense if we get it to work properly. Implementing it as an option will give us a chance to test and show it and win people over. (Or - more likely - I'll find out that the sceptics where right about this.) -- Ferdinand Soethe
Comment on index.html (Re: Where to change comments to configuration files)
Ross Gardler wrote: (about this comment FS !-- Note: No matter what you configure here, Forrest will always try to load FSindex.html when you request http://yourHost/ FS -- ) RG I'm -1 on the current comment as it gives the impression that it *can't* RG be changed. This is bad. If someone needs to change it and they read RG that comment then they will not bother to search the docs/ask on the RG mailing lists. RG In my opinion it's better to have something undocumented (and therefore RG prompt questions) than to have it incorrectly documented. I disagree here. It might have been ok to just leave it before we knew about the inconsistencies it will create if you don't use index.html. But knowing that and only having learned about this by accident feels a bit like leaving a big hole in the street uncovered and smashing the streetlight. Taking the comment out, people will just fall into the trap and perhaps not even know until the put their site on a server. I feel that inquisitive minds will stumple about the comment and come back asking for the reasons behind this or ways around this anyway. They'll benefit but won't be stopped. But those who want to use Forrest without knowing the details will get a clear message. In fact, thinking about it, I'd probably extend that comment to tell you that you have to have an index.html in the root for things to work properly. Apart from that: Putting sufficient info to explain the whole situation into that comment will take perhaps 20 lines. That is a bit much for my taste. If it is not, I'll happily add that. Or I could either add a line to refer people to this thread or write up a short faq that sums up the facts about changing index.html and refer to that. wdyt -- Ferdinand Soethe
Re: loggin error in last part of static site generation
Ross Gardler wrote: RG http://issues.cocoondev.org/browse/FOR-465 Ooops. Sorry. Time to start reading issues again ... -- Ferdinand Soethe
[JIRA] Commented: (FOR-490) serve multiple sites on a single Forrest instance
The following comment has been added to this issue: Author: Johannes Schaefer Created: Tue, 3 May 2005 3:28 AM Body: Here's the link to the Mail: http://marc.theaimsgroup.com/?l=forrest-devm=111510406905741w=2 - View this comment: http://issues.cocoondev.org//browse/FOR-490?page=comments#action_12335 - View the issue: http://issues.cocoondev.org//browse/FOR-490 Here is an overview of the issue: - Key: FOR-490 Summary: serve multiple sites on a single Forrest instance Type: New Feature Status: Unassigned Priority: Major Project: Forrest Components: Core operations Fix Fors: 0.8 Versions: 0.8 Assignee: Reporter: Johannes Schaefer Created: Tue, 3 May 2005 2:06 AM Updated: Tue, 3 May 2005 3:28 AM Description: Nicola Ken Barozzi wrote: After that, it would be beneficial to be able to serve multiple sites on a single Forrest instance, so that we can have other projects join and have their site served. This last point (seving multiple sites from one Forrest instance) is important even without moving Forrest to a live server (I'm +1 on this). Right now we have various styleguides in Forrest and if I need to run them at once I have to start Forrest/jetty with different ports. (From Thread [RT] Serving Apache Forrest site from live Forrest on dev-list. Will add link later.) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Daisy plugin
On 26 Apr 2005, at 23:29, Ross Gardler wrote: The big advantage of Daisy over other CMS systems is that it compeltely separates the front end from the repository. The access control is done in the repository. However at present, for simplicity, the plugin uses the daisy-wiki interface to retrieve pages. A future version will add the ability to connect directly to the reposiitory via one of the API's (choose from Java, HTTP or Javascript). This will give us much more flexability with respect to the handling of access control and the structure of the documents. Make sure to take a look at http://cocoondev.org/daisydocs-1_3/repository/interfaces/21.html, especially the /publisher/documentPage method. With a request parameter includeNavigation=true|false, you can decide to include the navigation tree (or not). Authentication on the HTTP/XML back-end is required and should be done using BASIC authentication - which is rather trivial using httpclient, but I'm not sure how that could be achieved easily from a plain Cocoon pipeline (which is what the current plugin does IIUC). The easiest way to connect to the repo from a Java environment is the Java API, of course, which is trivial to wrap in a flow script. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Comment on index.html (Re: Where to change comments to configuration files)
Ferdinand Soethe wrote: Ross Gardler wrote: (about this comment FS !-- Note: No matter what you configure here, Forrest will always try to load FSindex.html when you request http://yourHost/ FS -- ) RG I'm -1 on the current comment as it gives the impression that it *can't* RG be changed. This is bad. If someone needs to change it and they read RG that comment then they will not bother to search the docs/ask on the RG mailing lists. RG In my opinion it's better to have something undocumented (and therefore RG prompt questions) than to have it incorrectly documented. I disagree here. It might have been ok to just leave it before we knew about the inconsistencies it will create if you don't use index.html. As far as I am aware the only inconsistency is that the index page credits will no longer work. Thorsten has already said this is fixed in views and I have said it is easy to fix in skins if my existing suggestions are tested and prove to be correct. Taking the comment out, people will just fall into the trap and perhaps not even know until the put their site on a server. I'm not -1 on the comment, only -1 on the current wording. My issue is that it gives the false impression that it is not a configurable feature. I feel that inquisitive minds will stumple about the comment and come back asking for the reasons behind this or ways around this anyway. In my experience users don't ask questions if something is written in the docs. Potential devs might, but users don't. In fact, thinking about it, I'd probably extend that comment to tell you that you have to have an index.html in the root for things to work properly. But that simply is not correct. It *is* configurable as I have written on a number of occasions now. Apart from that: Putting sufficient info to explain the whole situation into that comment will take perhaps 20 lines. That is a bit much for my taste. If it is not, I'll happily add that. So put a link to a document that provides those twenty lines. Or I could either add a line to refer people to this thread or write up a short faq that sums up the facts about changing index.html and refer to that. FAQ's are good. Ross
Re: Does Forrest delete build/site before adding new files?
Ross Gardler wrote: RG It doesn't by default for performance reasons. During development it is RG usually not important if the odd file is left hanging and cleaning a RG directory with a few thousand files in it can take quite some time. RG If you want to do a clean build then do 'forrest clean site' Thanks, added that to the FAQs. -- Ferdinand Soethe
Re: Comment on index.html (Re: Where to change comments to configuration files)
Ross Gardler wrote: RG But that simply is not correct. It *is* configurable as I have written RG on a number of occasions now. Sorry, I shouldn't respond to messages one by one. That way I missed your solution in 'Re: Inkonsistency in implementation of default file and site.xml and what to do about it' when I wrote my reply. Will adjust documentation accordingly. -- Ferdinand Soethe
Re: Comment on index.html (Re: Where to change comments to configuration files)
On Tue, 2005-05-03 at 09:49 +0100, Ross Gardler wrote: Ferdinand Soethe wrote: ... I disagree here. It might have been ok to just leave it before we knew about the inconsistencies it will create if you don't use index.html. As far as I am aware the only inconsistency is that the index page credits will no longer work. Thorsten has already said this is fixed in views and I have said it is easy to fix in skins if my existing suggestions are tested and prove to be correct. Yeah it is *very easy*: 1 have a look at pelts site2xhtml.xsl and search for $filename = 'index.html' 2 at into the fresh site skinconf something like credit filename=some.html/ (and extend the dtd!) 3 change all results from 1 to $filename=$config/credits/@filename That's it. ;-) HTH -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[HEADSUP] viewHelper is now viewHelper.xhtml
Hello devs, I am implementing another format for the viewHelper. That forced me to rename the current implementation to viewHelper.xhtml. *You have to* rename the forrest.properties of your projects that are using the view/viewHelper!!! BTW we need to discuss the contracts that we have right now. For now it is possible to implement more then one format within a contract, but IMO that do not make much sense. I recommend that a contract is implementing just 1 format. WDYT? salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: svn commit: r167890 - /forrest/trunk/site-author/content/xdocs/docs/faq.xml
[EMAIL PROTECTED] wrote: +faq id=defaultFileName + question How can I change the default file name that Forrest will look for when I request a +URL like codehttp://myserver/code or codehttp://myserver/mydir//code? /question + answer +pChange the setting ![CDATA[default-filenameindex.html/default-filename]] in + cli.xconf./p + /answer +/faq This only affects sites when generated from the command line interface (i.e. not when doing 'forrest run' or running as a webapp). To change it in non command line you need to override the sitemap redirects. I haven't read all your changes in detail, but it looks like you improved a fair number of the FAQ entries. Cool! Ross
Re: Comment on index.html (Re: Where to change comments to configuration files)
Ferdinand Soethe wrote: Ross Gardler wrote: RG But that simply is not correct. It *is* configurable as I have written RG on a number of occasions now. Sorry, I shouldn't respond to messages one by one. That way I missed your solution in 'Re: Inkonsistency in implementation of default file and site.xml and what to do about it' when I wrote my reply. One of the reasons for keeping everything in one thread. This particular issue spanned three different threads because of subject changes. It's sometimes very difficult to know when to change the subject. I always try not too unless I have totally changed the direction the thread is taking. Will adjust documentation accordingly. I saw that - it's great to see someone actually documenting what is discussed here. Thanks!!! Ross
Re: [HEADSUP] viewHelper is now viewHelper.xhtml
Hi Thorsten, What are the main differences between this and the earlier implementations? Thanks, Diwaker On 5/3/05, Thorsten Scherler [EMAIL PROTECTED] wrote: Hello devs, I am implementing another format for the viewHelper. That forced me to rename the current implementation to viewHelper.xhtml. *You have to* rename the forrest.properties of your projects that are using the view/viewHelper!!! BTW we need to discuss the contracts that we have right now. For now it is possible to implement more then one format within a contract, but IMO that do not make much sense. I recommend that a contract is implementing just 1 format. WDYT? salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd) -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Reverting changes
Recently I asked how I should revert a change in SVN, but no-one here was sure how to do it smoothly. I promised to ask on a more appropriate list, however, this recently appeared on the cocoon dev list: Antonio Gallardo wrote: Hi: I want revert changes in src/java/org/apache/cocoon/util/NetUtils.java from HEAD to 53864. How to do this? svn merge -r HEAD:53864 src/java/org/apache/cocoon/util/NetUtils.java src/java/org/apache/cocoon/util/NetUtils.java Vadim Also useful (from the same thread): http://svnbook.red-bean.com/en/1.0/ch04s04.html#svn-ch-4-sect-4.2 (although Antonio mentions that the docs are a little unclear) so now we have our answer ;-) Ross
[EMAIL PROTECTED]: Project forrest-forrestbar (in module forrest) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project forrest-forrestbar has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - forrest-forrestbar : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/gump_work/build_forrest_forrest-forrestbar.html Work Name: build_forrest_forrest-forrestbar (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=03052005 forrestbar [Working Directory: /usr/local/gump/public/workspace/forrest/tools/forrestbar] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar - Buildfile: build.xml BUILD FAILED java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) Total time: 0 seconds java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) org/xml/sax/ext/Attributes2 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/rss.xml - Atom: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 22001803052005, brutus:brutus-public:22001803052005 Gump E-mail Identifier (unique within run) #18. -- Apache Gump http://gump.apache.org/ [Instance: brutus]
