You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Don Brown <do...@gmail.com> on 2005/09/09 23:52:13 UTC
[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
Posted by Don Brown <do...@gmail.com>.
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 <ja...@carmanconsulting.com> 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:donald.brown@gmail.com]
> 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 <ja...@carmanconsulting.com> 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:donald.brown@gmail.com]
> > 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
Posted by James Carman <ja...@carmanconsulting.com>.
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:donald.brown@gmail.com]
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 <ja...@carmanconsulting.com> 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:donald.brown@gmail.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Don Brown <do...@gmail.com>.
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 <ja...@carmanconsulting.com> 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:donald.brown@gmail.com]
> 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
Posted by James Carman <ja...@carmanconsulting.com>.
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:donald.brown@gmail.com]
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Arnaud HERITIER <ah...@gmail.com>.
>
>
>
> 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
Posted by Phil Steitz <ph...@gmail.com>.
On 9/12/05, Phil Steitz <ph...@gmail.com> wrote:
>
>
> On 9/12/05, Niall Pemberton
> <ni...@blueyonder.co.uk> wrote:
> > From: "Phil Steitz" <ph...@gmail.com>
> >
> > 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/menu[@type='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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Phil Steitz <ph...@gmail.com>.
On 9/12/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>
> From: "Phil Steitz" <ph...@gmail.com>
>
> 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/menu[@type='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 L&F 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [commons-build] Site build problem
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
From: "Phil Steitz" <ph...@gmail.com>
>On 9/11/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>>
>> ----- Original Message -----
>> From: "Brett Porter" <br...@apache.org>
>> 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/menu[@type='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 L&F 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>
> ----- Original Message -----
> From: "Brett Porter" <br...@apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
RE: [commons-build] Site build problem
Posted by Arnaud HERITIER <ah...@gmail.com>.
I opened a new bug for this incompatibility issue.
http://jira.codehaus.org/browse/MPXDOC-167
Arnaud
> -----Message d'origine-----
> De : Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
> Envoyé : lundi 12 septembre 2005 06:14
> À : Jakarta Commons Developers List
> Objet : Re: [commons-build] Site build problem
>
> ----- Original Message -----
> From: "Brett Porter" <br...@apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Brett Porter" <br...@apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Brett Porter <br...@apache.org>.
>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Martin Cooper <mf...@gmail.com>.
On 9/11/05, Phil Steitz <ph...@gmail.com> wrote:
>
> On 9/11/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> >
> > From: "Brett Porter" <br...@apache.org>
> > > 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>
> > <groupId>maven</groupId>
> > <artifactId>maven-xdoc-plugin</artifactId>
> > <version>1.9.2</version>
> > <url>http://maven.apache.org/reference/plugins/xdoc</url>
> > <type>plugin</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
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Phil Steitz" <ph...@gmail.com>
> On 9/11/05, Niall Pemberton <ni...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>
> From: "Brett Porter" <br...@apache.org>
> > 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>
> <groupId>maven</groupId>
> <artifactId>maven-xdoc-plugin</artifactId>
> <version>1.9.2</version>
> <url>http://maven.apache.org/reference/plugins/xdoc</url>
> <type>plugin</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
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
From: "Brett Porter" <br...@apache.org>
> 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>
<groupId>maven</groupId>
<artifactId>maven-xdoc-plugin</artifactId>
<version>1.9.2</version>
<url>http://maven.apache.org/reference/plugins/xdoc</url>
<type>plugin</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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Brett Porter <br...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/05, Brett Porter <br...@apache.org> 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
Posted by Brett Porter <br...@apache.org>.
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=267498&view=markup
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-build] Site build problem
Posted by Phil Steitz <ph...@gmail.com>.
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
Posted by Phil Steitz <ph...@gmail.com>.
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 <ni...@blueyonder.co.uk> 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" <do...@gmail.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [commons-build] Site build problem
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <do...@gmail.com>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org