Re: [commons-build] Site build problem
This turned out to be a bug in the site.jsl. A patch has been applied to svn and this will be fixed in version 1.10 of the xdoc plugin. Here is an example site generated using the patched plugin and maven.xdoc.theme=classic maven.ui.banner.background=#fff http://people.apache.org/~psteitz/classic.html The nav entry Commons Resources (Unofficial) is too wide to fit (and maven.ui.navcol.width seems to no longer do anything); but otherwise this looks OK to me. Others may have different opinions; but if this looks good enough I would suggest that we tweak the menus, etc. to work with this setup and migrate away from using custom style sheets. We could get things working right away by just dropping the type='header' from the About Us menu. The big advantage of going this route is that we would then no longer need to maintain commons-site.jsl, nor to copy the stylesheets out to the distributions. Phil Can you open an issue for the problem with maven.ui.navcol.width ? We'll fix it (if possible) for the release 1.10 I think you removed the icons used to show External Links and New Windows. You should remove the legend. maven.xdoc.legend=false cheers, Arnaud
Re: [commons-build] Site build problem
On 9/12/05, Phil Steitz [EMAIL PROTECTED] wrote: On 9/12/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Phil Steitz [EMAIL PROTECTED] They do, but including the commons about us menu before the component's menu is in the commons-site.jsl commons-site.jsl has the following line: jsl:applyTemplates select=$nav/body/[EMAIL PROTECTED]'header']/ but site.jsl (from 1.9.2) has the following x:if select=$nav jsl:applyTemplates select=$nav/body/menu[not(@type) | @type='header'] | $nav/body/search/ /x:if That is a mystery to me. The 1.9.2 version looks like it should work to me, and it does if you remove the if test. Could be a bug in the site.jsl. Maybe someone jellier than me can explain this. This turned out to be a bug in the site.jsl. A patch has been applied to svn and this will be fixed in version 1.10 of the xdoc plugin. Here is an example site generated using the patched plugin and maven.xdoc.theme=classic maven.ui.banner.background=#fff http://people.apache.org/~psteitz/classic.html The nav entry Commons Resources (Unofficial) is too wide to fit (and maven.ui.navcol.width seems to no longer do anything); but otherwise this looks OK to me. Others may have different opinions; but if this looks good enough I would suggest that we tweak the menus, etc. to work with this setup and migrate away from using custom style sheets. We could get things working right away by just dropping the type='header' from the About Us menu. The big advantage of going this route is that we would then no longer need to maintain commons-site.jsl, nor to copy the stylesheets out to the distributions. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: - Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. The menus actually come from the xml entities that are (individually) referenced from the navigation.xml files. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. This is the reason that commons-build was created in the first place. I will do as you suggest above, for the immediate term (create two versions, with notes), this evening. FWIW, I now recall that the reason that main reason that most of us decided to stop extending the commons-build POM was that it made distribution awkward. I will also have a look at how different things look bet 1.8, 1.9 with maven.xdoc.theme=classic. These should not be much different and, if so, I think I agree with Brett that the best solution would be to just toss commons-site.jsl together, replacing the funny out-links using css or something. IIRC, that was the only real complaint. Phil Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
From: Phil Steitz [EMAIL PROTECTED] On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: - Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. The menus actually come from the xml entities that are (individually) referenced from the navigation.xml files. They do, but including the commons about us menu before the component's menu is in the commons-site.jsl commons-site.jsl has the following line: jsl:applyTemplates select=$nav/body/[EMAIL PROTECTED]'header']/ but site.jsl (from 1.9.2) has the following x:if select=$nav jsl:applyTemplates select=$nav/body/menu[not(@type) | @type='header'] | $nav/body/search/ /x:if I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. This is the reason that commons-build was created in the first place. I will do as you suggest above, for the immediate term (create two versions, with notes), this evening. FWIW, I now recall that the reason that main reason that most of us decided to stop extending the commons-build POM was that it made distribution awkward. I will also have a look at how different things look bet 1.8, 1.9 with maven.xdoc.theme=classic. These should not be much different and, if so, I think I agree with Brett that the best solution would be to just toss commons-site.jsl together, replacing the funny out-links using css or something. IIRC, that was the only real complaint. As I said above, I think Brett was wrong on this - it does include the commons menu. As well as the menu, commons-site.jsl also links to the three stylesheets (tigris.css, maven.css and project.css) at jakarta.apache.org/commons/style, if there are no local style sheets for the component - 21 out of 34 commons components use this - the others that have links to their own local copies appear to be just copying them in from commons-build anyway - including commons Math (which also has copies of all three in SVN as well). Having just three copies of the stylesheets for [at the moment, most of] commons seems like a good idea to me. I'm not sure if you're talking about tossing commons-site.jsl just for commons-math or for the whole of commons. Assuming you mean the whole of commons then at a minimum the menu issue would need resolving and 21 components would need their maven.xml updating to copy the stylesheets. Also I think you're both missing the point on insulating changes to the standard site.jsl. Just checking 1.8 and 1.9 work OK doesn't resolve the issue of what happens if the next version of the maven-xdoc-plugin site.jsl does something different. Potentially different components could have a different LF depending on the plugin version used and having got rid of the mechanims to isolate commons from changes we don't want, we could find ourselves having to put it back in. The real issue IMO comes back to needing to ensure that we all use the same plugin version whatever the decision on which jsl file we use. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/12/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Phil Steitz [EMAIL PROTECTED] They do, but including the commons about us menu before the component's menu is in the commons-site.jsl commons-site.jsl has the following line: jsl:applyTemplates select=$nav/body/[EMAIL PROTECTED]'header']/ but site.jsl (from 1.9.2) has the following x:if select=$nav jsl:applyTemplates select=$nav/body/menu[not(@type) | @type='header'] | $nav/body/search/ /x:if That is a mystery to me. The 1.9.2 version looks like it should work to me, and it does if you remove the if test. Could be a bug in the site.jsl. Maybe someone jellier than me can explain this. As well as the menu, commons-site.jsl also links to the three stylesheets (tigris.css, maven.css and project.css) at jakarta.apache.org/commons/style http://jakarta.apache.org/commons/style , if there are no local style sheets for the component - 21 out of 34 commons components use this - the others that have links to their own local copies appear to be just copying them in from commons-build anyway - including commons Math (which also has copies of all three in SVN as well). Having just three copies of the stylesheets for [at the moment, most of] commons seems like a good idea to me. That is a good point. The sample maven.xml.sample in commons-build does the copy as part of the build, but you are correct that commons-site.jslreferences them. I'm not sure if you're talking about tossing commons-site.jsl just for commons-math or for the whole of commons. Assuming you mean the whole of commons then at a minimum the menu issue would need resolving and 21 components would need their maven.xml updating to copy the stylesheets. Many of them have the maven.xml snippet that does the copy now. Also I think you're both missing the point on insulating changes to the standard site.jsl. Just checking 1.8 and 1.9 work OK doesn't resolve the issue of what happens if the next version of the maven-xdoc-plugin site.jsl does something different. Potentially different components could have a different LF depending on the plugin version used and having got rid of the mechanims to isolate commons from changes we don't want, we could find ourselves having to put it back in. Another good point, though I would think it a not too unreasonable expectation that the classic style would not change much from version to version. IIRC, commons-site.jsl was created during the pre-1.0 release days when the style sheets were changing a lot. I suggested using 1.8-1.9 as a measure of how stable the classic L F is. The real issue IMO comes back to needing to ensure that we all use the same plugin version whatever the decision on which jsl file we use. That is one way to solve the problem (at least part of it), but I don't see a simple automated way to ensure this. It might not be a bad idea to maintain a set of commons-wide plugin version dependencies and even add these to commons-build.xml so that running the main site build would update them all. One of the problems with keeping the custom commons-site.jsl is maintaining it as maven and the plugins change. I tried to update if for 1.9+ and ended up breaking pre-1.9 builds. Having a iong mess of jsl to pore through each time xdoc does a release is not a happy state. I am happy to do what I can to try to keep things going and to get us through the current mess, but I am by no means a jelly, jsl, or css expert and unless others with more expertise are willing to take on maintaining this stuff, I think that we need to rethink how the jsl, stylesheets and and menus work. Phil Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. Phil
Re: [commons-build] Site build problem
Hi Phil. Phil Steitz wrote: There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. That's a shame - I would have thought at least one of those solutions would have worked. Probably the most effective thing to do in this case is to put a check into commons-build/maven.xml to make sure the latest plugin is being used. That could be used to select the JSL to use (current or previous), but it might be better to recommend a consistent version (especially if some start requiring the i18n or other features, for example). Here's an example: http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/faq/plugin.jelly?rev=267498view=markup Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Brett Porter [EMAIL PROTECTED] wrote: Hi Phil. Phil Steitz wrote: There does not appear to be a reasonable way to make our customized site.jslwork with both pre- and post- 1.9 versions of the maven xdoc plugin. The best solution is to upgrade to 1.9+ before generating commons sites. I also just fixed a problem in commons-site.jsl that we preventing the date being displayed, so before generating commons sites, you should svn up commons-build. That's a shame - I would have thought at least one of those solutions would have worked. The problem is that we have decoupled the site builds from commons-build - the individual projects reference commons-site.jsl directly. Probably the most effective thing to do in this case is to put a check into commons-build/maven.xml to make sure the latest plugin is being used. That could be used to select the JSL to use (current or previous), but it might be better to recommend a consistent version (especially if some start requiring the i18n or other features, for example). Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Is there any way to get commons-site.jsl to check? Thanks for your help on this and any ideas that you have on how to improve the setup. If you can see an any way to eliminate the dependency on the fmt library from commons-site.jsl without breaking site generation or to sneak it in somehow without breaking xdoc 1.9, that would also be great. Phil
Re: [commons-build] Site build problem
Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). Is there any way to get commons-site.jsl to check? Unfortunately not - fmt is required to parse the file so it will still die before that. Thanks for your help on this and any ideas that you have on how to improve the setup. I've fiddled with a few things, but haven't had much luck: - tried to revert to the non fmt: version from 1.8 but it seems there are 2 incompatibilities in 1.9: the removal of build.date and the requirement of messages / to be processed to handle the generated content. It would have been good for i18n to be an option that was enabled and the old stuff retained otherwise. - tried to do the failing as above, and tried to select the old or new jsl inside the jsl based on the plugin version, but neither worked The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it is meant to add: setting maven.xdoc.theme=classic looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? If they did - isn't the simplest solution to add a plugin dependency to commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2 xdoc version and running. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. If they did - isn't the simplest solution to add a plugin dependency commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2 xdoc version and running. Niall Yes, that would work for the current problem, but I am not sure all would be happy about going back to all extending the commons-build POM. Thoughts? Phil
Re: [commons-build] Site build problem
- Original Message - From: Phil Steitz [EMAIL PROTECTED] On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. OK, my suggestion: 1) Add a dependency for the 1.9.2 maven-xdoc-plugin to the commons-build's project.xml 2) Add a commons-site-xdoc-1.8.jsl to commons-build that reflects commons-site.jsl before you made your change - i.e. doesn't require the 1.9.2 maven-xdoc-plugin. 3) Post an [all] message to this list that explains the issue and telling projects they have a choice of three solutions a) extends commons-build/project.xml or b) add a plugin dependency to their project.xml or c) change their project.properties to point to commons-site-xdoc-1.8.jsl. Then its down to individual projects which way they want to jump. Niall P.S. Put notes in the two jsl files explaining the difference between the two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
On 9/11/05, Phil Steitz [EMAIL PROTECTED] wrote: On 9/11/05, Niall Pemberton [EMAIL PROTECTED] wrote: From: Brett Porter [EMAIL PROTECTED] Phil Steitz wrote: Given the current setup above, unless I am missing something, all of the maven.xml's would have to be modified to check, I guess this is possible. Fair enough - I thought all the projects extended commons-build/project.xml (and hence used it's maven.xml). I did a quick scan and only attributes and chain extend the commons-build/project.xml - but maybe all commons components should? That used to be the setup, and lots of people complained, since it meant that even to just build/jar the components, you had to have commons-build checked out, among other things. Of course, the web sites now depend on the commons-site.jsl, style sheets and nav elements, so you effectively have to have it checked out to do site gens, so it is worth considering going back to extending. We have Subversion now, and so svn:externals, which gives us an alternative to having to check out commons-build separately... -- Martin Cooper If they did - isn't the simplest solution to add a plugin dependency commons-build/project.xml? dependency groupIdmaven/groupId artifactIdmaven-xdoc-plugin/artifactId version1.9.2/version urlhttp://maven.apache.org/reference/plugins/xdoc/url typeplugin/type /dependency I tried this with validator and it worked fine, downloading the 1.9.2xdoc version and running. Niall Yes, that would work for the current problem, but I am not sure all would be happy about going back to all extending the commons-build POM. Thoughts? Phil
Re: [commons-build] Site build problem
We have Subversion now, and so svn:externals, which gives us an alternative to having to check out commons-build separately... This still has 2 problems: - you end up with X checkouts of commons-build where X is the number of projects in commons you have checked out - You also have to do a copy of this directory at release time (this is probably preferable to now where you always get the current version, even for an old tag), you can't rely on the versioning of the external. I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
- Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [commons-build] Site build problem
I opened a new bug for this incompatibility issue. http://jira.codehaus.org/browse/MPXDOC-167 Arnaud -Message d'origine- De : Niall Pemberton [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 septembre 2005 06:14 À : Jakarta Commons Developers List Objet : Re: [commons-build] Site build problem - Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. Niall - 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: [commons-build] Site build problem
Sorry guys, I made the jsl change, which was to make site builds work with versions 1.9+ of the xdoc plugin. I thought I had tested successfully with 1.8, but now see that I must have failed to clear the plugin cache or something. My bad. So...current state is that commons-site.jsl *requires* v. 1.9+ of the xdoc plugin. Use maven plugin:download -DgroupId=maven -DartifactId=maven-xdoc-plugin -Dversion=1.9.2 to download 1.9.2 Unfortunately, without the change, the site build does not work correctly with 1.9+, so my inclination is to leave the change in for now. I will roll back the change, though, if others feel differently. i will also ask on the maven list if there is some way to patch the site.jsl to work with both versions. Phil On 9/9/05, Niall Pemberton [EMAIL PROTECTED] wrote: The problem is the update that was made to commons-site.jsl 9 days ago: http://tinyurl.com/dvab5 If you reverse out that change the problem goes away. Niall - Original Message - From: Don Brown [EMAIL PROTECTED] Sent: Friday, September 09, 2005 10:52 PM It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary Is anyone else seeing this problem? I've tried removing ~/.maven but with no luck. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[commons-build] Site build problem
It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java :425) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1039) ... Could not create taglib or URI: jelly:fmt tag name: message java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) Is anyone else seeing this problem? I've tried removing ~/.maven but with no luck. Don
RE: [commons-build] Site build problem
I had to upgrade one of the maven plugins to fix that, I believe. Which version of the jdepend plugin do you have? I'm at version 1.5. I'm not absolutely sure that's the plugin that I upgraded. -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 5:52 PM To: Jakarta Commons Developers List Subject: [commons-build] Site build problem It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java :425) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1039) ... Could not create taglib or URI: jelly:fmt tag name: message java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) Is anyone else seeing this problem? I've tried removing ~/.maven but with no luck. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build] Site build problem
Didn't help. Besides, I thought Maven would download plugins automatically from the network. By upgrading, I downloaded the 1.5 jar and put it in my maven home /plugins directory. Any other ideas? Don On 9/9/05, James Carman [EMAIL PROTECTED] wrote: I had to upgrade one of the maven plugins to fix that, I believe. Which version of the jdepend plugin do you have? I'm at version 1.5. I'm not absolutely sure that's the plugin that I upgraded. -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 5:52 PM To: Jakarta Commons Developers List Subject: [commons-build] Site build problem It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java :425) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1039) ... Could not create taglib or URI: jelly:fmt tag name: message java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) Is anyone else seeing this problem? I've tried removing ~/.maven but with no luck. Don
RE: [commons-build] Site build problem
Here's my list. The commons-proxy build works just fine with this set of plugins: maven-abbot-plugin-1.1 maven-announcement-plugin-1.3 maven-ant-plugin-1.8.1 maven-antlr-plugin-1.2.1 maven-appserver-plugin-2.0 maven-artifact-plugin-1.4.1 maven-ashkelon-plugin-1.2 maven-aspectj-plugin-3.2 maven-aspectwerkz-plugin-1.2 maven-caller-plugin-1.1 maven-castor-plugin-1.2 maven-changelog-plugin-1.8.1 maven-changes-plugin-1.5.1 maven-checkstyle-plugin-2.5 maven-clean-plugin-1.3 maven-clover-plugin-1.8 maven-console-plugin-1.1 maven-cruisecontrol-plugin-1.6 maven-dashboard-plugin-1.6 maven-developer-activity-plugin-1.5.1 maven-dist-plugin-1.6.1 maven-docbook-plugin-1.2 maven-ear-plugin-1.6 maven-eclipse-plugin-1.9 maven-ejb-plugin-1.5 maven-faq-plugin-1.4 maven-file-activity-plugin-1.5.1 maven-genapp-plugin-2.2 maven-gump-plugin-1.4 maven-hibernate-plugin-1.2 maven-html2xdoc-plugin-1.3.1 maven-idea-plugin-1.5 maven-j2ee-plugin-1.5.1 maven-jalopy-plugin-1.3.1 maven-jar-plugin-1.6.1 maven-java-plugin-1.5 maven-javacc-plugin-1.1 maven-javadoc-plugin-1.7 maven-jboss-plugin-1.5 maven-jbuilder-plugin-1.5 maven-jcoverage-plugin-1.0.9 maven-jdee-plugin-1.1 maven-jdepend-plugin-1.5 maven-jdeveloper-plugin-1.4 maven-jdiff-plugin-1.4 maven-jellydoc-plugin-1.3.1 maven-jetty-plugin-1.1 maven-jira-plugin-1.1.2 maven-jnlp-plugin-1.4.1 maven-junit-doclet-plugin-1.2 maven-junit-report-plugin-1.5 maven-jxr-plugin-1.4.2 maven-latex-plugin-1.4.1 maven-latka-plugin-1.4.1 maven-license-plugin-1.2 maven-linkcheck-plugin-1.3.4 maven-multichanges-plugin-1.1 maven-multiproject-plugin-1.3.1 maven-native-plugin-1.1 maven-nsis-plugin-1.1 maven-pdf-plugin-2.2.1 maven-plugin-plugin-1.5.2 maven-pmd-plugin-1.6 maven-pom-plugin-1.4.1 maven-rar-plugin-1.0 maven-release-plugin-1.4.1 maven-repository-plugin-1.2 maven-scm-plugin-1.4.1 maven-shell-plugin-1.1 maven-simian-plugin-1.4 maven-site-plugin-1.5.2 maven-spy-plugin-0.2.7 maven-struts-plugin-1.3 maven-tasklist-plugin-2.3 maven-test-plugin-1.6.2 maven-tjdo-plugin-1.0.0 maven-uberjar-plugin-1.2 maven-vdoclet-plugin-1.2 maven-war-plugin-1.6.1 maven-webserver-plugin-2.0 maven-wizard-plugin-1.1 maven-xdoc-plugin-1.8 -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 6:08 PM To: James Carman Cc: Jakarta Commons Developers List Subject: Re: [commons-build] Site build problem Didn't help. Besides, I thought Maven would download plugins automatically from the network. By upgrading, I downloaded the 1.5 jar and put it in my maven home /plugins directory. Any other ideas? Don On 9/9/05, James Carman [EMAIL PROTECTED] wrote: I had to upgrade one of the maven plugins to fix that, I believe. Which version of the jdepend plugin do you have? I'm at version 1.5. I'm not absolutely sure that's the plugin that I upgraded. -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 5:52 PM To: Jakarta Commons Developers List Subject: [commons-build] Site build problem It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java :425) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1039) ... Could not create taglib or URI: jelly:fmt tag name: message java.lang.ClassNotFoundException: fmt at org.apache.commons.jelly.parser.XMLParser.createSAXException( XMLParser.java:1234) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1044) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source
Re: [commons-build] Site build problem
Well, synchronizing with your list didn't help, but upgrading to version 1.9.2 of the xdoc plugin did. I had just gotten over a case of Maven-phobia, but I'm afraid I'm regressing :/ Thanks for the help, regardless :) Don On 9/9/05, James Carman [EMAIL PROTECTED] wrote: Here's my list. The commons-proxy build works just fine with this set of plugins: maven-abbot-plugin-1.1 maven-announcement-plugin-1.3 maven-ant-plugin-1.8.1 maven-antlr-plugin-1.2.1 maven-appserver-plugin-2.0 maven-artifact-plugin-1.4.1 maven-ashkelon-plugin-1.2 maven-aspectj-plugin-3.2 maven-aspectwerkz-plugin-1.2 maven-caller-plugin-1.1 maven-castor-plugin-1.2 maven-changelog-plugin-1.8.1 maven-changes-plugin-1.5.1 maven-checkstyle-plugin-2.5 maven-clean-plugin-1.3 maven-clover-plugin-1.8 maven-console-plugin-1.1 maven-cruisecontrol-plugin-1.6 maven-dashboard-plugin-1.6 maven-developer-activity-plugin-1.5.1 maven-dist-plugin-1.6.1 maven-docbook-plugin-1.2 maven-ear-plugin-1.6 maven-eclipse-plugin-1.9 maven-ejb-plugin-1.5 maven-faq-plugin-1.4 maven-file-activity-plugin-1.5.1 maven-genapp-plugin-2.2 maven-gump-plugin-1.4 maven-hibernate-plugin-1.2 maven-html2xdoc-plugin-1.3.1 maven-idea-plugin-1.5 maven-j2ee-plugin-1.5.1 maven-jalopy-plugin-1.3.1 maven-jar-plugin-1.6.1 maven-java-plugin-1.5 maven-javacc-plugin-1.1 maven-javadoc-plugin-1.7 maven-jboss-plugin-1.5 maven-jbuilder-plugin-1.5 maven-jcoverage-plugin-1.0.9 maven-jdee-plugin-1.1 maven-jdepend-plugin-1.5 maven-jdeveloper-plugin-1.4 maven-jdiff-plugin-1.4 maven-jellydoc-plugin-1.3.1 maven-jetty-plugin-1.1 maven-jira-plugin-1.1.2 maven-jnlp-plugin-1.4.1 maven-junit-doclet-plugin-1.2 maven-junit-report-plugin-1.5 maven-jxr-plugin-1.4.2 maven-latex-plugin-1.4.1 maven-latka-plugin-1.4.1 maven-license-plugin-1.2 maven-linkcheck-plugin-1.3.4 maven-multichanges-plugin-1.1 maven-multiproject-plugin-1.3.1 maven-native-plugin-1.1 maven-nsis-plugin-1.1 maven-pdf-plugin-2.2.1 maven-plugin-plugin-1.5.2 maven-pmd-plugin-1.6 maven-pom-plugin-1.4.1 maven-rar-plugin-1.0 maven-release-plugin-1.4.1 maven-repository-plugin-1.2 maven-scm-plugin-1.4.1 maven-shell-plugin-1.1 maven-simian-plugin-1.4 maven-site-plugin-1.5.2 maven-spy-plugin-0.2.7 maven-struts-plugin-1.3 maven-tasklist-plugin-2.3 maven-test-plugin-1.6.2 maven-tjdo-plugin-1.0.0 maven-uberjar-plugin-1.2 maven-vdoclet-plugin-1.2 maven-war-plugin-1.6.1 maven-webserver-plugin-2.0 maven-wizard-plugin-1.1 maven-xdoc-plugin-1.8 -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 6:08 PM To: James Carman Cc: Jakarta Commons Developers List Subject: Re: [commons-build] Site build problem Didn't help. Besides, I thought Maven would download plugins automatically from the network. By upgrading, I downloaded the 1.5 jar and put it in my maven home /plugins directory. Any other ideas? Don On 9/9/05, James Carman [EMAIL PROTECTED] wrote: I had to upgrade one of the maven plugins to fix that, I believe. Which version of the jdepend plugin do you have? I'm at version 1.5. I'm not absolutely sure that's the plugin that I upgraded. -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 5:52 PM To: Jakarta Commons Developers List Subject: [commons-build] Site build problem It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java :425) ... Underlying exception: java.lang.ClassNotFoundException: fmt java.lang.ClassNotFoundException: fmt at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java :1039) ... Could not create taglib or URI: jelly:fmt tag name: message
Re: [commons-build] Site build problem
The problem is the update that was made to commons-site.jsl 9 days ago: http://tinyurl.com/dvab5 If you reverse out that change the problem goes away. Niall - Original Message - From: Don Brown [EMAIL PROTECTED] Sent: Friday, September 09, 2005 10:52 PM It seems this maven problem affects all the commons projects that use the commons-build. I'm seeing it on Linux and Windows, both running Maven 1.0.2. Again, the problem is when running maven site. When it gets to the jdepend report, I see: xdoc:jelly-transform: [echo] Generating /home/mrdon/dev/fileupload/target/docs/jdepend-report.htmlfrom /home/mrdon/dev/fileupload/target/generated-xdocs/jdepend- report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary Is anyone else seeing this problem? I've tried removing ~/.maven but with no luck. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
