You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Paulo Silveira <pa...@paulo.com.br> on 2003/03/14 04:16:53 UTC
xdoc generating non relative paths? or ignoring base...
hi all
I am generating maven site, and all navigation links gets to /foo.html.
1beta8 generated ./foo.html, or am not configuring something?
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
> -----Original Message-----
> From: Ben Walding [mailto:ben@walding.com]
> Sent: quinta-feira, 13 de março de 2003 21:07
> To: Turbine Maven Users List
> Subject: Re: jar manifest extension dependency list
>
>
> I have raised MAVEN-334 to cover these issues.
>
> - see jira.werken.com
>
> Vincenz Braun wrote:
>
> >Hello,
> >
> >i do not know whether this is the right place for this issue,
> >but i do not know the component responsible for creating
> >the manifest files in maven.
> >
> >I really appreciate that maven builds jars with version
> information in
> >the manifest. But this is not conforming to the extension versioning
> >specification.
> >
> >1. Why not using the correct attribute name for extensions?
> >
> >Example from the spec:
> >
> >Extension-Name: javax.help
> >Specification-Vendor: Sun Microsystems, Inc
> >Specification-Version: 1.0
> >Implementation-Vendor-Id: com.sun
> >Implementation-Vendor: Sun Microsystems, Inc
> >Implementation-Version: 1.0
> >
> >Maven uses the attribute name Name instead of Extension-Name.
> >
> >2. Why not include dependency information?
> >
> >Example from the spec:
> >
> >Extension-List: javahelp java3d
> >javahelp-Extension-Name: javax.help
> >javahelp-Specification-Version: 1.0
> >javahelp-Implementation-Version: 1.0.3
> >javahelp-Implementation-Vendor-Id: com.sun
> >javahelp-Implementation-URL:
> >http://java.sun.com/products/stdext/javahelp.jar
> >java3d-Extension-Name: javax.3d
> >java3d-Specification-Version: 1.0
> >java3d-Implementation-Version: 1.2.1
> >java3d-Implementation-Vendor-Id: com.sun
> >java3d-Implementation-URL:
> http://java.sun.com/products/stdext/java3d.jar
> >
> >3. Why not
> include download URL locations?
> >
> >See example above.
> >
> >Can someone tell me the component responsible for creating
> the manifest
> >files in maven?
> >
> >Is this a known issue (I did not find it on the user mailing list)?
> >Can this feature be added in future releases?
> >
> >Thanks,
> >Vincenz
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >turbine-maven-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
RE: cannot debug maven, java.lang.ClassNotFoundException: xml ??
Posted by Charles Chan <ch...@yahoo.com>.
Coincidently, I have the same problem today. I posted
a similar question to the dev list:
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104766084121878&w=2
Charles
--- Paulo Silveira <pa...@paulo.com.br> wrote:
> Thanks a lot, it worked.
>
> But maven.bat/sh do not include these jars into the
> classpath when
> running maven. The only jar used in the classpath is
> forehead-xxx.jar
>
> Why do I have do include?
>
> ------------------------
> Paulo Silveira
> http://www.paulo.com.br/
> http://www.guj.com.br/
>
>
> > -----Original Message-----
> > From: Incze Lajos [mailto:incze@mail.matav.hu]
> > Sent: sexta-feira, 14 de mar�o de 2003 16:54
> > To: Turbine Maven Users List
> > Subject: Re: cannot debug maven,
> > java.lang.ClassNotFoundException: xml ??
> >
> >
> > On Fri, Mar 14, 2003 at 09:35:08AM -0300, Paulo
> Silveira wrote:
> > > I am just sending to the lsit because I ve
> already lost 1
> > night trying
> > > to debug Maven in Eclipse.
> > >
> > ...
> > > --> java.lang.ClassNotFoundException: xml
> > >
> > > xml? a class named xml? who is trying to load
> this? why
> > does jelly has
> > > a "xml", lowercase, not packaged, class name?
> > >
> > > If any one could help me.... It seems like it is
> not reading some
> > > configfile, or maybe not.
> >
> > You probably miss the commons-jelly-tags-xml
> dependency. The
> > exception is dropped when jelly tries to load the
> jelly:xml
> > taglib. At least I think so.
> >
> > incze
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> >
> >
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
RE: cannot debug maven, java.lang.ClassNotFoundException: xml ??
Posted by Paulo Silveira <pa...@paulo.com.br>.
Thanks a lot, it worked.
But maven.bat/sh do not include these jars into the classpath when
running maven. The only jar used in the classpath is forehead-xxx.jar
Why do I have do include?
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
> -----Original Message-----
> From: Incze Lajos [mailto:incze@mail.matav.hu]
> Sent: sexta-feira, 14 de março de 2003 16:54
> To: Turbine Maven Users List
> Subject: Re: cannot debug maven,
> java.lang.ClassNotFoundException: xml ??
>
>
> On Fri, Mar 14, 2003 at 09:35:08AM -0300, Paulo Silveira wrote:
> > I am just sending to the lsit because I ve already lost 1
> night trying
> > to debug Maven in Eclipse.
> >
> ...
> > --> java.lang.ClassNotFoundException: xml
> >
> > xml? a class named xml? who is trying to load this? why
> does jelly has
> > a "xml", lowercase, not packaged, class name?
> >
> > If any one could help me.... It seems like it is not reading some
> > configfile, or maybe not.
>
> You probably miss the commons-jelly-tags-xml dependency. The
> exception is dropped when jelly tries to load the jelly:xml
> taglib. At least I think so.
>
> incze
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
Re: cannot debug maven, java.lang.ClassNotFoundException: xml ??
Posted by Incze Lajos <in...@mail.matav.hu>.
On Fri, Mar 14, 2003 at 09:35:08AM -0300, Paulo Silveira wrote:
> I am just sending to the lsit because I ve already lost 1 night trying
> to debug Maven in Eclipse.
>
...
> --> java.lang.ClassNotFoundException: xml
>
> xml? a class named xml? who is trying to load this? why does jelly has a
> "xml", lowercase, not packaged, class name?
>
> If any one could help me.... It seems like it is not reading some
> configfile, or maybe not.
You probably miss the commons-jelly-tags-xml dependency. The exception is
dropped when jelly tries to load the jelly:xml taglib. At least I think so.
incze
RE: xdoc generating non relative paths? or ignoring base...
Posted by Paulo Silveira <pa...@paulo.com.br>.
Your test works fine here, for both cygwin and cmd.exe
so the problem is not here.
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
> -----Original Message-----
> From: Ben Walding [mailto:default0001@walding.com]
> Sent: sexta-feira, 14 de março de 2003 10:03
> To: Turbine Maven Users List
> Subject: Re: xdoc generating non relative paths? or ignoring base...
>
>
> While your method is a bit cleaner, this is how xdocs works,
> and I don't
> think it is appropriate to break it at this juncture.
>
> public void testCalculateLink()
> {
> testCalculateLink("/bob.html", "/absolute//bob.html", "..");
> testCalculateLink("http://crazyhorse.com",
> "/absolute/http://crazyhorse.com", "..");
> testCalculateLink("http://crazyhorse.com",
> "http://crazyhorse.com", "..");
> testCalculateLink("../index.html", "/index.html", "..");
> testCalculateLink("index.html", "/index.html", ".");
> testCalculateLink("../other-module/index.html",
> "../other-module/index.html", ".");
> testCalculateLink("../../other-module/index.html",
> "../other-module/index.html", "..");
> }
>
> public void testCalculateLink(String expected, String link, String
> relativePath)
> {
> String actual = DVSLPathTool.calculateLink(link,
> relativePath);
> String function = "DVSLPathTool.calculateLink(" +
> link + "," +
> relativePath + ")";
> if (!expected.equals(actual)) {
> System.out.println("Function:" + function);
> System.out.println("Actual:" + actual);
> System.out.println("Expected:" + expected);
> }
> assertEquals(function, expected, actual);
> }
>
>
> Rafal Krzewski wrote:
>
> >Ben Walding wrote:
> >
> >
> >>What version of Maven?
> >>
> >>Make sure your navigation links start with / as there is a
> hole in the
> >>tests which means that it can get confused if your links
> don't start
> >>with / or one of the other special tags (site or absolute).
> Your link
> >>should look like <item href="/foo.html" name="Foot"/>. Maven will
> >>generate the appropriate link depending on the page you are viewing.
> >>
> >>
> >
> >I don't quite understand what special tags you are talking
> about. There
> >was some special handling of links that begin with '/site/'
> string, but
> >I removed that with MAVEN-283 patch, because I thought it
> was residual
> >after some quick and and dirty hack.
> >
> >Could someone clarify what is the general policy for links in xdocs?
> >
> >I'll give my undestading here, so please correct me if I'm wrong:
> >
> >1) Any link that starts with schema specification (ie
> http://) is left
> > untouched.
> >
> >2) Any link that starts with a / is left untouched - it's relative to
> > the root of the site's destination server, let the browser handle
> >it.
> >
> >3) If the link does not match the above, it's treated as
> relative to the
> > location of the file that contains it. If the generated html file
> > would reside in the directory analogous to the directory where the
> > source xdoc is, the link is left untouched. If the generated html
> > file would reside in another directory, the link should
> be prepended
> > with the relative path pointing from the html file's destination
> > directory to the directory analogous to the source xdocs location.
> >
> >Example:
> >
> >Assume that the xdocs/navigation.xml contains the following links:
> >
> ><item name="Maven" href="http://jakarta.apache.org/maven"/>
> ><item name="Home" href="/index.html"/>
> ><item name="Home rel" href="index.html"/>
> ><item name="User's guide" href="reference/usres-guide.html"/>
> ><item name="Install" href="start/install.html"/>
> >
> >depending on the directory, the links would rener as:
> >
> >/
> >Maven http://jakarta.apache.org/maven
> >Home /index.html
> >Home rel index.html
> >User's guide reference/usres-guide.html
> >Install start/install.html
> >
> >/start
> >Maven http://jakarta.apache.org/maven
> >Home /index.html
> >Home rel ../index.html
> >User's guide ../reference/usres-guide.html
> >Install install.html
> >
> >/reference
> >Maven http://jakarta.apache.org/maven
> >Home /index.html
> >Home rel ../index.html
> >User's guide usres-guide.html
> >Install ../start/install.html
> >
> >/reference/somedir
> >Maven http://jakarta.apache.org/maven
> >Home /index.html
> >Home rel ../../index.html
> >User's guide ../usres-guide.html
> >Install ../../start/install.html
> >
> >Is this how it's done now? If not, don't you think that it's the
> >correct way of handling relative paths?
> >
> >R.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >turbine-maven-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
Re: xdoc generating non relative paths? or ignoring base...
Posted by Ben Walding <de...@walding.com>.
While your method is a bit cleaner, this is how xdocs works, and I don't
think it is appropriate to break it at this juncture.
public void testCalculateLink()
{
testCalculateLink("/bob.html", "/absolute//bob.html", "..");
testCalculateLink("http://crazyhorse.com",
"/absolute/http://crazyhorse.com", "..");
testCalculateLink("http://crazyhorse.com",
"http://crazyhorse.com", "..");
testCalculateLink("../index.html", "/index.html", "..");
testCalculateLink("index.html", "/index.html", ".");
testCalculateLink("../other-module/index.html",
"../other-module/index.html", ".");
testCalculateLink("../../other-module/index.html",
"../other-module/index.html", "..");
}
public void testCalculateLink(String expected, String link, String
relativePath)
{
String actual = DVSLPathTool.calculateLink(link, relativePath);
String function = "DVSLPathTool.calculateLink(" + link + "," +
relativePath + ")";
if (!expected.equals(actual)) {
System.out.println("Function:" + function);
System.out.println("Actual:" + actual);
System.out.println("Expected:" + expected);
}
assertEquals(function, expected, actual);
}
Rafal Krzewski wrote:
>Ben Walding wrote:
>
>
>>What version of Maven?
>>
>>Make sure your navigation links start with / as there is a hole in the
>>tests which means that it can get confused if your links don't start
>>with / or one of the other special tags (site or absolute). Your link
>>should look like <item href="/foo.html" name="Foot"/>. Maven will
>>generate the appropriate link depending on the page you are viewing.
>>
>>
>
>I don't quite understand what special tags you are talking about. There
>was some special handling of links that begin with '/site/' string, but
>I removed that with MAVEN-283 patch, because I thought it was residual
>after some quick and and dirty hack.
>
>Could someone clarify what is the general policy for links in xdocs?
>
>I'll give my undestading here, so please correct me if I'm wrong:
>
>1) Any link that starts with schema specification (ie http://) is left
> untouched.
>
>2) Any link that starts with a / is left untouched - it's relative to
> the root of the site's destination server, let the browser handle it.
>
>3) If the link does not match the above, it's treated as relative to the
> location of the file that contains it. If the generated html file
> would reside in the directory analogous to the directory where the
> source xdoc is, the link is left untouched. If the generated html
> file would reside in another directory, the link should be prepended
> with the relative path pointing from the html file's destination
> directory to the directory analogous to the source xdocs location.
>
>Example:
>
>Assume that the xdocs/navigation.xml contains the following links:
>
><item name="Maven" href="http://jakarta.apache.org/maven"/>
><item name="Home" href="/index.html"/>
><item name="Home rel" href="index.html"/>
><item name="User's guide" href="reference/usres-guide.html"/>
><item name="Install" href="start/install.html"/>
>
>depending on the directory, the links would rener as:
>
>/
>Maven http://jakarta.apache.org/maven
>Home /index.html
>Home rel index.html
>User's guide reference/usres-guide.html
>Install start/install.html
>
>/start
>Maven http://jakarta.apache.org/maven
>Home /index.html
>Home rel ../index.html
>User's guide ../reference/usres-guide.html
>Install install.html
>
>/reference
>Maven http://jakarta.apache.org/maven
>Home /index.html
>Home rel ../index.html
>User's guide usres-guide.html
>Install ../start/install.html
>
>/reference/somedir
>Maven http://jakarta.apache.org/maven
>Home /index.html
>Home rel ../../index.html
>User's guide ../usres-guide.html
>Install ../../start/install.html
>
>Is this how it's done now? If not, don't you think that it's the correct
>way of handling relative paths?
>
>R.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
>
>
>
>
cannot debug maven, java.lang.ClassNotFoundException: xml ??
Posted by Paulo Silveira <pa...@paulo.com.br>.
I am just sending to the lsit because I ve already lost 1 night trying
to debug Maven in Eclipse.
My config:
-->main class:
com.werken.forehead.Forehead
--> virtual machine arguments:
"-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.Docum
entBuilderFactoryImpl"
"-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFa
ctoryImpl" "-Dmaven.home=E:\java-programs\maven-1.0-beta-8"
"-Dtools.jar=C:\j2sdk1.4.1_01\lib\tools.jar"
"-Dforehead.conf.file=E:\java-programs\maven-1.0-beta-8\bin\forehead.con
f"
"-Djava.endorsed.dirs=C:\j2sdk1.4.1_01\lib\endorsed;E:\java-programs\mav
en-1.0-beta-8\lib\endorsed"
--> classpath
(the one generated by maven eclipse, plus the fix for junit-.jar)
And then I got this (full stack later)
--> java.lang.ClassNotFoundException: xml
xml? a class named xml? who is trying to load this? why does jelly has a
"xml", lowercase, not packaged, class name?
If any one could help me.... It seems like it is not reading some
configfile, or maybe not.
__ __
| \/ |__ Jakarta _ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-beta-9-SNAPSHOT
java.lang.ClassNotFoundException: xml
at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at
org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1039)
at
org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:64
7)
at
org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis
patcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at
org.apache.commons.jelly.parser.XMLParser.parse(XMLParser.java:320)
at
org.apache.maven.jelly.JellyUtils.compileScript(JellyUtils.java:207)
at
org.apache.maven.jelly.JellyUtils.compileScript(JellyUtils.java:174)
at
org.apache.maven.jelly.JellyUtils.runScript(JellyUtils.java:111)
at
org.apache.maven.jelly.JellyUtils.runScript(JellyUtils.java:139)
at
org.apache.maven.plugin.PluginManager.loadPlugin(PluginManager.java:684)
at
org.apache.maven.plugin.PluginManager.prepDynamicTagLib(PluginManager.ja
va:571)
at
org.apache.maven.plugin.PluginManager.prepDynaTagLibs(PluginManager.java
:546)
at
org.apache.maven.plugin.PluginManager.loadPlugin(PluginManager.java:645)
at
org.apache.maven.plugin.PluginManager.prepDynamicTagLib(PluginManager.ja
va:571)
at
org.apache.maven.plugin.PluginManager.prepDynaTagLibs(PluginManager.java
:546)
at
org.apache.maven.plugin.PluginManager.loadPlugin(PluginManager.java:645)
at
org.apache.maven.plugin.PluginManager.prepForGoal(PluginManager.java:486
)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:375
)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:357)
at org.apache.maven.cli.App.doMain(App.java:524)
at org.apache.maven.cli.App.main(App.java:1080)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:543)
at com.werken.forehead.Forehead.main(Forehead.java:573)
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
Re: xdoc generating non relative paths? or ignoring base...
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Ben Walding wrote:
> What version of Maven?
>
> Make sure your navigation links start with / as there is a hole in the
> tests which means that it can get confused if your links don't start
> with / or one of the other special tags (site or absolute). Your link
> should look like <item href="/foo.html" name="Foot"/>. Maven will
> generate the appropriate link depending on the page you are viewing.
I don't quite understand what special tags you are talking about. There
was some special handling of links that begin with '/site/' string, but
I removed that with MAVEN-283 patch, because I thought it was residual
after some quick and and dirty hack.
Could someone clarify what is the general policy for links in xdocs?
I'll give my undestading here, so please correct me if I'm wrong:
1) Any link that starts with schema specification (ie http://) is left
untouched.
2) Any link that starts with a / is left untouched - it's relative to
the root of the site's destination server, let the browser handle it.
3) If the link does not match the above, it's treated as relative to the
location of the file that contains it. If the generated html file
would reside in the directory analogous to the directory where the
source xdoc is, the link is left untouched. If the generated html
file would reside in another directory, the link should be prepended
with the relative path pointing from the html file's destination
directory to the directory analogous to the source xdocs location.
Example:
Assume that the xdocs/navigation.xml contains the following links:
<item name="Maven" href="http://jakarta.apache.org/maven"/>
<item name="Home" href="/index.html"/>
<item name="Home rel" href="index.html"/>
<item name="User's guide" href="reference/usres-guide.html"/>
<item name="Install" href="start/install.html"/>
depending on the directory, the links would rener as:
/
Maven http://jakarta.apache.org/maven
Home /index.html
Home rel index.html
User's guide reference/usres-guide.html
Install start/install.html
/start
Maven http://jakarta.apache.org/maven
Home /index.html
Home rel ../index.html
User's guide ../reference/usres-guide.html
Install install.html
/reference
Maven http://jakarta.apache.org/maven
Home /index.html
Home rel ../index.html
User's guide usres-guide.html
Install ../start/install.html
/reference/somedir
Maven http://jakarta.apache.org/maven
Home /index.html
Home rel ../../index.html
User's guide ../usres-guide.html
Install ../../start/install.html
Is this how it's done now? If not, don't you think that it's the correct
way of handling relative paths?
R.
Re: xdoc generating non relative paths? or ignoring base...
Posted by Ben Walding <de...@walding.com>.
I fixed that just after the b8 release went out in MAVEN-268. It's
caused by conflicting upper and lower case drive letters from cygwin / java.
DVSLPathTool is the one to look at / update.
Alexei Barantsev wrote:
>I've observed the following:
>Maven-b8 on Windows generates site with right links (./foo) if I use CMD
>and with bad links (/foo) if I use cygwin.
>
> > -----Original Message-----
> > From: Paulo Silveira [mailto:paulo@paulo.com.br]
> > Sent: Friday, March 14, 2003 6:51 AM
> > To: 'Turbine Maven Users List'
> > Subject: RE: xdoc generating non relative paths? or ignoring base...
> >
> >
> > I will do it in the weekend
> > just to clarify, I am generating maven's OWN site. and it
> > is generating hrefs linked to /task.html etc... instead of
> > ./task.html. I did not changed the navigation.xml.
> >
> > by the way, maybe javadoc plugin could be smarter, and do
> > not generate javadoc everytime. it could generate a
> > timestamp to see if this one is bigger than the latest
> > modified source file or sth like that
> >
> > I will post better information in a couple of days
> >
> > ------------------------
> > Paulo Silveira
> > http://www.paulo.com.br/
> > http://www.guj.com.br/
> >
> >
> > > -----Original Message-----
> > > From: Ben Walding [mailto:ben@walding.com]
> > > Sent: sexta-feira, 14 de março de 2003 00:36
> > > To: Turbine Maven Users List
> > > Subject: Re: xdoc generating non relative paths? or
> > ignoring base...
> > >
> > >
> > > What version of Maven?
> > >
> > > Make sure your navigation links start with / as there is a
> > > hole in the
> > > tests which means that it can get confused if your links
> > don't start
> > > with / or one of the other special tags (site or absolute).
> > > Your link
> > > should look like <item href="/foo.html" name="Foot"/>.
> > Maven will
> > > generate the appropriate link depending on the page you
> > are viewing.
> > >
> > >
> > > If you are doing that...
> > >
> > > Then are you using cvs head?
> > >
> > > I recently moved most of the navigation handling into
> > > DVSLPathTool and
> > > added a series of test cases. If you can find out how you
> > > are getting
> > > past the test cases that would make life easier for me
> > > (always a plus!).
> > > (Add some System.out.printlns to calculateLink on
> > > src/org/apache/maven/DVSLPathTool.java)
> > >
> > > Cheers,
> > >
> > > Ben
> > >
> > >
> > > Paulo Silveira wrote:
> > >
> > > >hi all
> > > >
> > > >I am generating maven site, and all navigation links gets to
> > > /foo.html.
> > > >1beta8 generated ./foo.html, or am not configuring something?
> > > >
> > > >------------------------
> > > >Paulo Silveira
> > > >http://www.paulo.com.br/
> > > >http://www.guj.com.br/
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Ben Walding [mailto:ben@walding.com]
> > > >>Sent: quinta-feira, 13 de março de 2003 21:07
> > > >>To: Turbine Maven Users List
> > > >>Subject: Re: jar manifest extension dependency list
> > > >>
> > > >>
> > > >>I have raised MAVEN-334 to cover these issues.
> > > >>
> > > >>- see jira.werken.com
> > > >>
> > > >>Vincenz Braun wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hello,
> > > >>>
> > > >>>i do not know whether this is the right place for this
> > > issue, but i
> > > >>>do not know the component responsible for creating the
> > > manifest files
> > > >>>in maven.
> > > >>>
> > > >>>I really appreciate that maven builds jars with version
> > > >>>
> > > >>>
> > > >>information in
> > > >>
> > > >>
> > > >>>the manifest. But this is not conforming to the extension
> > > versioning
> > > >>>specification.
> > > >>>
> > > >>>1. Why not using the correct attribute name for extensions?
> > > >>>
> > > >>>Example from the spec:
> > > >>>
> > > >>>Extension-Name: javax.help
> > > >>>Specification-Vendor: Sun Microsystems, Inc
> > > >>>Specification-Version: 1.0
> > > >>>Implementation-Vendor-Id: com.sun
> > > >>>Implementation-Vendor: Sun Microsystems, Inc
> > > >>>Implementation-Version: 1.0
> > > >>>
> > > >>>Maven uses the attribute name Name instead of Extension-Name.
> > > >>>
> > > >>>2. Why not include dependency information?
> > > >>>
> > > >>>Example from the spec:
> > > >>>
> > > >>>Extension-List: javahelp java3d
> > > >>>javahelp-Extension-Name: javax.help
> > > >>>javahelp-Specification-Version: 1.0
> > > >>>javahelp-Implementation-Version: 1.0.3
> > > >>>javahelp-Implementation-Vendor-Id: com.sun
> > > >>>javahelp-Implementation-URL:
> > > >>>http://java.sun.com/products/stdext/javahelp.jar
> > > >>>java3d-Extension-Name: javax.3d
> > > >>>java3d-Specification-Version: 1.0
> > > >>>java3d-Implementation-Version: 1.2.1
> > > >>>java3d-Implementation-Vendor-Id: com.sun
> > > >>>java3d-Implementation-URL:
> > > >>>
> > > >>>
> > > >>http://java.sun.com/products/stdext/java3d.jar
> > > >>
> > > >>
> > > >>>3. Why not
> > > >>>
> > > >>>
> > > >>include download URL locations?
> > > >>
> > > >>
> > > >>>See example above.
> > > >>>
> > > >>>Can someone tell me the component responsible for creating
> > > >>>
> > > >>>
> > > >>the manifest
> > > >>
> > > >>
> > > >>>files in maven?
> > > >>>
> > > >>>Is this a known issue (I did not find it on the user
> > > mailing list)?
> > > >>>Can this feature be added in future releases?
> > > >>>
> > > >>>Thanks,
> > > >>>Vincenz
> > > >>>
> > > >>>
> > > >>>-----------------------------------------------------------
> > > ----------
> > > >>>To unsubscribe, e-mail:
> > > >>>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >>>For additional commands, e-mail:
> > > >>>
> > > >>>
> > > >>turbine-maven-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>------------------------------------------------------------
> > > ---------
> > > >>To unsubscribe, e-mail:
> > > >>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail:
> > > >>turbine-maven-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >-----------------------------------------------------------
> > ----------
> > > >To unsubscribe, e-mail:
> > > >turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
> > > turbine-maven-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------
> > ---------
> > > To unsubscribe, e-mail:
> > > turbine-maven-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > turbine-maven-user-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> > ------------------------------------------------------------
> > ---------
> > To unsubscribe, e-mail:
> > turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
>
>
>
>
RE: xdoc generating non relative paths? or ignoring base...
Posted by Alexei Barantsev <ba...@kazbek.ispras.ru>.
> -----Original Message-----
> From: Paulo Silveira [mailto:paulo@paulo.com.br]
> Sent: Friday, March 14, 2003 9:14 AM
> To: 'Turbine Maven Users List'
> Subject: RE: xdoc generating non relative paths? or ignoring base...
>
>
> >
> > I've observed the following:
> > Maven-b8 on Windows generates site with right links (./foo)
> > if I use CMD and with bad links (/foo) if I use cygwin.
>
> Well done! This seems to be the problem.
> I ve tried here with the latest HEAD, same problem. In
> cygwin it goes ok, in cmd.exe we have the absolute path problem.
Are you sure? I said absolutely contrary. For me cmd.exe is OK while
cygwin fails.
>
> It seems it has to be with the method in DSVLPathTool that
> invoke private static final String determineSeparator(
> String filename ).
>
> Ben, will you take a further look? Maybe I can provide a
> patch, but it will be more a hack than a patch
>
>
> >
> > > -----Original Message-----
> > > From: Paulo Silveira [mailto:paulo@paulo.com.br]
> > > Sent: Friday, March 14, 2003 6:51 AM
> > > To: 'Turbine Maven Users List'
> > > Subject: RE: xdoc generating non relative paths? or
> > ignoring base...
> > >
> > >
> > > I will do it in the weekend
> > > just to clarify, I am generating maven's OWN site. and it
> > > is generating hrefs linked to /task.html etc... instead of
> > > ./task.html. I did not changed the navigation.xml.
> > >
> > > by the way, maybe javadoc plugin could be smarter, and do
> > > not generate javadoc everytime. it could generate a
> > > timestamp to see if this one is bigger than the latest
> > > modified source file or sth like that
> > >
> > > I will post better information in a couple of days
> > >
> > > ------------------------
> > > Paulo Silveira
> > > http://www.paulo.com.br/
> > > http://www.guj.com.br/
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ben Walding [mailto:ben@walding.com]
> > > > Sent: sexta-feira, 14 de março de 2003 00:36
> > > > To: Turbine Maven Users List
> > > > Subject: Re: xdoc generating non relative paths? or
> > > ignoring base...
> > > >
> > > >
> > > > What version of Maven?
> > > >
> > > > Make sure your navigation links start with / as there is a
> > > > hole in the
> > > > tests which means that it can get confused if your links
> > > don't start
> > > > with / or one of the other special tags (site or
> absolute).
> > > > Your link
> > > > should look like <item href="/foo.html" name="Foot"/>.
> > > Maven will
> > > > generate the appropriate link depending on the page you
> > > are viewing.
> > > >
> > > >
> > > > If you are doing that...
> > > >
> > > > Then are you using cvs head?
> > > >
> > > > I recently moved most of the navigation handling into
> > > > DVSLPathTool and
> > > > added a series of test cases. If you can find out how you
> > > > are getting
> > > > past the test cases that would make life easier for me
> > > > (always a plus!).
> > > > (Add some System.out.printlns to calculateLink on
> > > > src/org/apache/maven/DVSLPathTool.java)
> > > >
> > > > Cheers,
> > > >
> > > > Ben
> > > >
> > > >
> > > > Paulo Silveira wrote:
> > > >
> > > > >hi all
> > > > >
> > > > >I am generating maven site, and all navigation
> links gets to
> > > > /foo.html.
> > > > >1beta8 generated ./foo.html, or am not configuring
> something?
> > > > >
> > > > >------------------------
> > > > >Paulo Silveira
> > > > >http://www.paulo.com.br/
> > > > >http://www.guj.com.br/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Ben Walding [mailto:ben@walding.com]
> > > > >>Sent: quinta-feira, 13 de março de 2003 21:07
> > > > >>To: Turbine Maven Users List
> > > > >>Subject: Re: jar manifest extension dependency list
> > > > >>
> > > > >>
> > > > >>I have raised MAVEN-334 to cover these issues.
> > > > >>
> > > > >>- see jira.werken.com
> > > > >>
> > > > >>Vincenz Braun wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Hello,
> > > > >>>
> > > > >>>i do not know whether this is the right place for this
> > > > issue, but i
> > > > >>>do not know the component responsible for creating the
> > > > manifest files
> > > > >>>in maven.
> > > > >>>
> > > > >>>I really appreciate that maven builds jars with version
> > > > >>>
> > > > >>>
> > > > >>information in
> > > > >>
> > > > >>
> > > > >>>the manifest. But this is not conforming to the extension
> > > > versioning
> > > > >>>specification.
> > > > >>>
> > > > >>>1. Why not using the correct attribute name for
> extensions?
> > > > >>>
> > > > >>>Example from the spec:
> > > > >>>
> > > > >>>Extension-Name: javax.help
> > > > >>>Specification-Vendor: Sun Microsystems, Inc
> > > > >>>Specification-Version: 1.0
> > > > >>>Implementation-Vendor-Id: com.sun
> > > > >>>Implementation-Vendor: Sun Microsystems, Inc
> > > > >>>Implementation-Version: 1.0
> > > > >>>
> > > > >>>Maven uses the attribute name Name instead of
> Extension-Name.
> > > > >>>
> > > > >>>2. Why not include dependency information?
> > > > >>>
> > > > >>>Example from the spec:
> > > > >>>
> > > > >>>Extension-List: javahelp java3d
> > > > >>>javahelp-Extension-Name: javax.help
> > > > >>>javahelp-Specification-Version: 1.0
> > > > >>>javahelp-Implementation-Version: 1.0.3
> > > > >>>javahelp-Implementation-Vendor-Id: com.sun
> > > > >>>javahelp-Implementation-URL:
> > > > >>>http://java.sun.com/products/stdext/javahelp.jar
> > > > >>>java3d-Extension-Name: javax.3d
> > > > >>>java3d-Specification-Version: 1.0
> > > > >>>java3d-Implementation-Version: 1.2.1
> > > > >>>java3d-Implementation-Vendor-Id: com.sun
> > > > >>>java3d-Implementation-URL:
> > > > >>>
> > > > >>>
> > > > >>http://java.sun.com/products/stdext/java3d.jar
> > > > >>
> > > > >>
> > > > >>>3. Why not
> > > > >>>
> > > > >>>
> > > > >>include download URL locations?
> > > > >>
> > > > >>
> > > > >>>See example above.
> > > > >>>
> > > > >>>Can someone tell me the component responsible
> for creating
> > > > >>>
> > > > >>>
> > > > >>the manifest
> > > > >>
> > > > >>
> > > > >>>files in maven?
> > > > >>>
> > > > >>>Is this a known issue (I did not find it on the user
> > > > mailing list)?
> > > > >>>Can this feature be added in future releases?
> > > > >>>
> > > > >>>Thanks,
> > > > >>>Vincenz
> > > > >>>
> > > > >>>
> > > >
> >>>-----------------------------------------------------------
> > > > ----------
> > > > >>>To unsubscribe, e-mail:
> > > > >>>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > > >>>For additional commands, e-mail:
> > > > >>>
> > > > >>>
> > > > >>turbine-maven-user-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> >>------------------------------------------------------------
> > > > ---------
> > > > >>To unsubscribe, e-mail:
> > > > >>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > > >>For additional commands, e-mail:
> > > > >>turbine-maven-user-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >-----------------------------------------------------------
> > > ----------
> > > > >To unsubscribe, e-mail:
> > > > >turbine-maven-user-unsubscribe@jakarta.apache.org
> > > > >For additional commands, e-mail:
> > > > turbine-maven-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > ------------------------------------------------------------
> > > ---------
> > > > To unsubscribe, e-mail:
> > > > turbine-maven-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > turbine-maven-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ------------------------------------------------------------
> > > ---------
> > > To unsubscribe, e-mail:
> > > turbine-maven-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > turbine-maven-user-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> ------------------------------------------------------------
> ---------
> > To unsubscribe, e-mail:
> > turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
RE: xdoc generating non relative paths? or ignoring base...
Posted by Paulo Silveira <pa...@paulo.com.br>.
>
> I've observed the following:
> Maven-b8 on Windows generates site with right links (./foo)
> if I use CMD and with bad links (/foo) if I use cygwin.
Well done! This seems to be the problem.
I ve tried here with the latest HEAD, same problem. In cygwin it goes
ok, in cmd.exe we have the absolute path problem.
It seems it has to be with the method in DSVLPathTool that invoke
private static final String determineSeparator( String filename ).
Ben, will you take a further look? Maybe I can provide a patch, but it
will be more a hack than a patch
>
> > -----Original Message-----
> > From: Paulo Silveira [mailto:paulo@paulo.com.br]
> > Sent: Friday, March 14, 2003 6:51 AM
> > To: 'Turbine Maven Users List'
> > Subject: RE: xdoc generating non relative paths? or
> ignoring base...
> >
> >
> > I will do it in the weekend
> > just to clarify, I am generating maven's OWN site. and it
> > is generating hrefs linked to /task.html etc... instead of
> > ./task.html. I did not changed the navigation.xml.
> >
> > by the way, maybe javadoc plugin could be smarter, and do
> > not generate javadoc everytime. it could generate a
> > timestamp to see if this one is bigger than the latest
> > modified source file or sth like that
> >
> > I will post better information in a couple of days
> >
> > ------------------------
> > Paulo Silveira
> > http://www.paulo.com.br/
> > http://www.guj.com.br/
> >
> >
> > > -----Original Message-----
> > > From: Ben Walding [mailto:ben@walding.com]
> > > Sent: sexta-feira, 14 de março de 2003 00:36
> > > To: Turbine Maven Users List
> > > Subject: Re: xdoc generating non relative paths? or
> > ignoring base...
> > >
> > >
> > > What version of Maven?
> > >
> > > Make sure your navigation links start with / as there is a
> > > hole in the
> > > tests which means that it can get confused if your links
> > don't start
> > > with / or one of the other special tags (site or absolute).
> > > Your link
> > > should look like <item href="/foo.html" name="Foot"/>.
> > Maven will
> > > generate the appropriate link depending on the page you
> > are viewing.
> > >
> > >
> > > If you are doing that...
> > >
> > > Then are you using cvs head?
> > >
> > > I recently moved most of the navigation handling into
> > > DVSLPathTool and
> > > added a series of test cases. If you can find out how you
> > > are getting
> > > past the test cases that would make life easier for me
> > > (always a plus!).
> > > (Add some System.out.printlns to calculateLink on
> > > src/org/apache/maven/DVSLPathTool.java)
> > >
> > > Cheers,
> > >
> > > Ben
> > >
> > >
> > > Paulo Silveira wrote:
> > >
> > > >hi all
> > > >
> > > >I am generating maven site, and all navigation links gets to
> > > /foo.html.
> > > >1beta8 generated ./foo.html, or am not configuring something?
> > > >
> > > >------------------------
> > > >Paulo Silveira
> > > >http://www.paulo.com.br/
> > > >http://www.guj.com.br/
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Ben Walding [mailto:ben@walding.com]
> > > >>Sent: quinta-feira, 13 de março de 2003 21:07
> > > >>To: Turbine Maven Users List
> > > >>Subject: Re: jar manifest extension dependency list
> > > >>
> > > >>
> > > >>I have raised MAVEN-334 to cover these issues.
> > > >>
> > > >>- see jira.werken.com
> > > >>
> > > >>Vincenz Braun wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hello,
> > > >>>
> > > >>>i do not know whether this is the right place for this
> > > issue, but i
> > > >>>do not know the component responsible for creating the
> > > manifest files
> > > >>>in maven.
> > > >>>
> > > >>>I really appreciate that maven builds jars with version
> > > >>>
> > > >>>
> > > >>information in
> > > >>
> > > >>
> > > >>>the manifest. But this is not conforming to the extension
> > > versioning
> > > >>>specification.
> > > >>>
> > > >>>1. Why not using the correct attribute name for extensions?
> > > >>>
> > > >>>Example from the spec:
> > > >>>
> > > >>>Extension-Name: javax.help
> > > >>>Specification-Vendor: Sun Microsystems, Inc
> > > >>>Specification-Version: 1.0
> > > >>>Implementation-Vendor-Id: com.sun
> > > >>>Implementation-Vendor: Sun Microsystems, Inc
> > > >>>Implementation-Version: 1.0
> > > >>>
> > > >>>Maven uses the attribute name Name instead of Extension-Name.
> > > >>>
> > > >>>2. Why not include dependency information?
> > > >>>
> > > >>>Example from the spec:
> > > >>>
> > > >>>Extension-List: javahelp java3d
> > > >>>javahelp-Extension-Name: javax.help
> > > >>>javahelp-Specification-Version: 1.0
> > > >>>javahelp-Implementation-Version: 1.0.3
> > > >>>javahelp-Implementation-Vendor-Id: com.sun
> > > >>>javahelp-Implementation-URL:
> > > >>>http://java.sun.com/products/stdext/javahelp.jar
> > > >>>java3d-Extension-Name: javax.3d
> > > >>>java3d-Specification-Version: 1.0
> > > >>>java3d-Implementation-Version: 1.2.1
> > > >>>java3d-Implementation-Vendor-Id: com.sun
> > > >>>java3d-Implementation-URL:
> > > >>>
> > > >>>
> > > >>http://java.sun.com/products/stdext/java3d.jar
> > > >>
> > > >>
> > > >>>3. Why not
> > > >>>
> > > >>>
> > > >>include download URL locations?
> > > >>
> > > >>
> > > >>>See example above.
> > > >>>
> > > >>>Can someone tell me the component responsible for creating
> > > >>>
> > > >>>
> > > >>the manifest
> > > >>
> > > >>
> > > >>>files in maven?
> > > >>>
> > > >>>Is this a known issue (I did not find it on the user
> > > mailing list)?
> > > >>>Can this feature be added in future releases?
> > > >>>
> > > >>>Thanks,
> > > >>>Vincenz
> > > >>>
> > > >>>
> > > >>>-----------------------------------------------------------
> > > ----------
> > > >>>To unsubscribe, e-mail:
> > > >>>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >>>For additional commands, e-mail:
> > > >>>
> > > >>>
> > > >>turbine-maven-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>------------------------------------------------------------
> > > ---------
> > > >>To unsubscribe, e-mail:
> > > >>turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail:
> > > >>turbine-maven-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >-----------------------------------------------------------
> > ----------
> > > >To unsubscribe, e-mail:
> > > >turbine-maven-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
> > > turbine-maven-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------
> > ---------
> > > To unsubscribe, e-mail:
> > > turbine-maven-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > turbine-maven-user-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> > ------------------------------------------------------------
> > ---------
> > To unsubscribe, e-mail:
> > turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
RE: xdoc generating non relative paths? or ignoring base...
Posted by Alexei Barantsev <ba...@kazbek.ispras.ru>.
I've observed the following:
Maven-b8 on Windows generates site with right links (./foo) if I use CMD
and with bad links (/foo) if I use cygwin.
> -----Original Message-----
> From: Paulo Silveira [mailto:paulo@paulo.com.br]
> Sent: Friday, March 14, 2003 6:51 AM
> To: 'Turbine Maven Users List'
> Subject: RE: xdoc generating non relative paths? or ignoring base...
>
>
> I will do it in the weekend
> just to clarify, I am generating maven's OWN site. and it
> is generating hrefs linked to /task.html etc... instead of
> ./task.html. I did not changed the navigation.xml.
>
> by the way, maybe javadoc plugin could be smarter, and do
> not generate javadoc everytime. it could generate a
> timestamp to see if this one is bigger than the latest
> modified source file or sth like that
>
> I will post better information in a couple of days
>
> ------------------------
> Paulo Silveira
> http://www.paulo.com.br/
> http://www.guj.com.br/
>
>
> > -----Original Message-----
> > From: Ben Walding [mailto:ben@walding.com]
> > Sent: sexta-feira, 14 de março de 2003 00:36
> > To: Turbine Maven Users List
> > Subject: Re: xdoc generating non relative paths? or
> ignoring base...
> >
> >
> > What version of Maven?
> >
> > Make sure your navigation links start with / as there is a
> > hole in the
> > tests which means that it can get confused if your links
> don't start
> > with / or one of the other special tags (site or absolute).
> > Your link
> > should look like <item href="/foo.html" name="Foot"/>.
> Maven will
> > generate the appropriate link depending on the page you
> are viewing.
> >
> >
> > If you are doing that...
> >
> > Then are you using cvs head?
> >
> > I recently moved most of the navigation handling into
> > DVSLPathTool and
> > added a series of test cases. If you can find out how you
> > are getting
> > past the test cases that would make life easier for me
> > (always a plus!).
> > (Add some System.out.printlns to calculateLink on
> > src/org/apache/maven/DVSLPathTool.java)
> >
> > Cheers,
> >
> > Ben
> >
> >
> > Paulo Silveira wrote:
> >
> > >hi all
> > >
> > >I am generating maven site, and all navigation links gets to
> > /foo.html.
> > >1beta8 generated ./foo.html, or am not configuring something?
> > >
> > >------------------------
> > >Paulo Silveira
> > >http://www.paulo.com.br/
> > >http://www.guj.com.br/
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Ben Walding [mailto:ben@walding.com]
> > >>Sent: quinta-feira, 13 de março de 2003 21:07
> > >>To: Turbine Maven Users List
> > >>Subject: Re: jar manifest extension dependency list
> > >>
> > >>
> > >>I have raised MAVEN-334 to cover these issues.
> > >>
> > >>- see jira.werken.com
> > >>
> > >>Vincenz Braun wrote:
> > >>
> > >>
> > >>
> > >>>Hello,
> > >>>
> > >>>i do not know whether this is the right place for this
> > issue, but i
> > >>>do not know the component responsible for creating the
> > manifest files
> > >>>in maven.
> > >>>
> > >>>I really appreciate that maven builds jars with version
> > >>>
> > >>>
> > >>information in
> > >>
> > >>
> > >>>the manifest. But this is not conforming to the extension
> > versioning
> > >>>specification.
> > >>>
> > >>>1. Why not using the correct attribute name for extensions?
> > >>>
> > >>>Example from the spec:
> > >>>
> > >>>Extension-Name: javax.help
> > >>>Specification-Vendor: Sun Microsystems, Inc
> > >>>Specification-Version: 1.0
> > >>>Implementation-Vendor-Id: com.sun
> > >>>Implementation-Vendor: Sun Microsystems, Inc
> > >>>Implementation-Version: 1.0
> > >>>
> > >>>Maven uses the attribute name Name instead of Extension-Name.
> > >>>
> > >>>2. Why not include dependency information?
> > >>>
> > >>>Example from the spec:
> > >>>
> > >>>Extension-List: javahelp java3d
> > >>>javahelp-Extension-Name: javax.help
> > >>>javahelp-Specification-Version: 1.0
> > >>>javahelp-Implementation-Version: 1.0.3
> > >>>javahelp-Implementation-Vendor-Id: com.sun
> > >>>javahelp-Implementation-URL:
> > >>>http://java.sun.com/products/stdext/javahelp.jar
> > >>>java3d-Extension-Name: javax.3d
> > >>>java3d-Specification-Version: 1.0
> > >>>java3d-Implementation-Version: 1.2.1
> > >>>java3d-Implementation-Vendor-Id: com.sun
> > >>>java3d-Implementation-URL:
> > >>>
> > >>>
> > >>http://java.sun.com/products/stdext/java3d.jar
> > >>
> > >>
> > >>>3. Why not
> > >>>
> > >>>
> > >>include download URL locations?
> > >>
> > >>
> > >>>See example above.
> > >>>
> > >>>Can someone tell me the component responsible for creating
> > >>>
> > >>>
> > >>the manifest
> > >>
> > >>
> > >>>files in maven?
> > >>>
> > >>>Is this a known issue (I did not find it on the user
> > mailing list)?
> > >>>Can this feature be added in future releases?
> > >>>
> > >>>Thanks,
> > >>>Vincenz
> > >>>
> > >>>
> > >>>-----------------------------------------------------------
> > ----------
> > >>>To unsubscribe, e-mail:
> > >>>turbine-maven-user-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail:
> > >>>
> > >>>
> > >>turbine-maven-user-help@jakarta.apache.org
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>------------------------------------------------------------
> > ---------
> > >>To unsubscribe, e-mail:
> > >>turbine-maven-user-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail:
> > >>turbine-maven-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >-----------------------------------------------------------
> ----------
> > >To unsubscribe, e-mail:
> > >turbine-maven-user-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> ------------------------------------------------------------
> ---------
> > To unsubscribe, e-mail:
> > turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
RE: xdoc generating non relative paths? or ignoring base...
Posted by Paulo Silveira <pa...@paulo.com.br>.
I will do it in the weekend
just to clarify, I am generating maven's OWN site. and it is generating
hrefs linked to /task.html etc... instead of ./task.html. I did not
changed the navigation.xml.
by the way, maybe javadoc plugin could be smarter, and do not generate
javadoc everytime. it could generate a timestamp to see if this one is
bigger than the latest modified source file or sth like that
I will post better information in a couple of days
------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
> -----Original Message-----
> From: Ben Walding [mailto:ben@walding.com]
> Sent: sexta-feira, 14 de março de 2003 00:36
> To: Turbine Maven Users List
> Subject: Re: xdoc generating non relative paths? or ignoring base...
>
>
> What version of Maven?
>
> Make sure your navigation links start with / as there is a
> hole in the
> tests which means that it can get confused if your links don't start
> with / or one of the other special tags (site or absolute).
> Your link
> should look like <item href="/foo.html" name="Foot"/>. Maven will
> generate the appropriate link depending on the page you are viewing.
>
>
> If you are doing that...
>
> Then are you using cvs head?
>
> I recently moved most of the navigation handling into
> DVSLPathTool and
> added a series of test cases. If you can find out how you
> are getting
> past the test cases that would make life easier for me
> (always a plus!).
> (Add some System.out.printlns to calculateLink on
> src/org/apache/maven/DVSLPathTool.java)
>
> Cheers,
>
> Ben
>
>
> Paulo Silveira wrote:
>
> >hi all
> >
> >I am generating maven site, and all navigation links gets to
> /foo.html.
> >1beta8 generated ./foo.html, or am not configuring something?
> >
> >------------------------
> >Paulo Silveira
> >http://www.paulo.com.br/
> >http://www.guj.com.br/
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Ben Walding [mailto:ben@walding.com]
> >>Sent: quinta-feira, 13 de março de 2003 21:07
> >>To: Turbine Maven Users List
> >>Subject: Re: jar manifest extension dependency list
> >>
> >>
> >>I have raised MAVEN-334 to cover these issues.
> >>
> >>- see jira.werken.com
> >>
> >>Vincenz Braun wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>i do not know whether this is the right place for this
> issue, but i
> >>>do not know the component responsible for creating the
> manifest files
> >>>in maven.
> >>>
> >>>I really appreciate that maven builds jars with version
> >>>
> >>>
> >>information in
> >>
> >>
> >>>the manifest. But this is not conforming to the extension
> versioning
> >>>specification.
> >>>
> >>>1. Why not using the correct attribute name for extensions?
> >>>
> >>>Example from the spec:
> >>>
> >>>Extension-Name: javax.help
> >>>Specification-Vendor: Sun Microsystems, Inc
> >>>Specification-Version: 1.0
> >>>Implementation-Vendor-Id: com.sun
> >>>Implementation-Vendor: Sun Microsystems, Inc
> >>>Implementation-Version: 1.0
> >>>
> >>>Maven uses the attribute name Name instead of Extension-Name.
> >>>
> >>>2. Why not include dependency information?
> >>>
> >>>Example from the spec:
> >>>
> >>>Extension-List: javahelp java3d
> >>>javahelp-Extension-Name: javax.help
> >>>javahelp-Specification-Version: 1.0
> >>>javahelp-Implementation-Version: 1.0.3
> >>>javahelp-Implementation-Vendor-Id: com.sun
> >>>javahelp-Implementation-URL:
> >>>http://java.sun.com/products/stdext/javahelp.jar
> >>>java3d-Extension-Name: javax.3d
> >>>java3d-Specification-Version: 1.0
> >>>java3d-Implementation-Version: 1.2.1
> >>>java3d-Implementation-Vendor-Id: com.sun
> >>>java3d-Implementation-URL:
> >>>
> >>>
> >>http://java.sun.com/products/stdext/java3d.jar
> >>
> >>
> >>>3. Why not
> >>>
> >>>
> >>include download URL locations?
> >>
> >>
> >>>See example above.
> >>>
> >>>Can someone tell me the component responsible for creating
> >>>
> >>>
> >>the manifest
> >>
> >>
> >>>files in maven?
> >>>
> >>>Is this a known issue (I did not find it on the user
> mailing list)?
> >>>Can this feature be added in future releases?
> >>>
> >>>Thanks,
> >>>Vincenz
> >>>
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail:
> >>>turbine-maven-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>turbine-maven-user-help@jakarta.apache.org
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail:
> >>turbine-maven-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> >>turbine-maven-user-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >turbine-maven-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-user-help@jakarta.apache.org
>
>
>
Re: xdoc generating non relative paths? or ignoring base...
Posted by Ben Walding <be...@walding.com>.
What version of Maven?
Make sure your navigation links start with / as there is a hole in the
tests which means that it can get confused if your links don't start
with / or one of the other special tags (site or absolute). Your link
should look like <item href="/foo.html" name="Foot"/>. Maven will
generate the appropriate link depending on the page you are viewing.
If you are doing that...
Then are you using cvs head?
I recently moved most of the navigation handling into DVSLPathTool and
added a series of test cases. If you can find out how you are getting
past the test cases that would make life easier for me (always a plus!).
(Add some System.out.printlns to calculateLink on
src/org/apache/maven/DVSLPathTool.java)
Cheers,
Ben
Paulo Silveira wrote:
>hi all
>
>I am generating maven site, and all navigation links gets to /foo.html.
>1beta8 generated ./foo.html, or am not configuring something?
>
>------------------------
>Paulo Silveira
>http://www.paulo.com.br/
>http://www.guj.com.br/
>
>
>
>
>>-----Original Message-----
>>From: Ben Walding [mailto:ben@walding.com]
>>Sent: quinta-feira, 13 de março de 2003 21:07
>>To: Turbine Maven Users List
>>Subject: Re: jar manifest extension dependency list
>>
>>
>>I have raised MAVEN-334 to cover these issues.
>>
>>- see jira.werken.com
>>
>>Vincenz Braun wrote:
>>
>>
>>
>>>Hello,
>>>
>>>i do not know whether this is the right place for this issue,
>>>but i do not know the component responsible for creating
>>>the manifest files in maven.
>>>
>>>I really appreciate that maven builds jars with version
>>>
>>>
>>information in
>>
>>
>>>the manifest. But this is not conforming to the extension versioning
>>>specification.
>>>
>>>1. Why not using the correct attribute name for extensions?
>>>
>>>Example from the spec:
>>>
>>>Extension-Name: javax.help
>>>Specification-Vendor: Sun Microsystems, Inc
>>>Specification-Version: 1.0
>>>Implementation-Vendor-Id: com.sun
>>>Implementation-Vendor: Sun Microsystems, Inc
>>>Implementation-Version: 1.0
>>>
>>>Maven uses the attribute name Name instead of Extension-Name.
>>>
>>>2. Why not include dependency information?
>>>
>>>Example from the spec:
>>>
>>>Extension-List: javahelp java3d
>>>javahelp-Extension-Name: javax.help
>>>javahelp-Specification-Version: 1.0
>>>javahelp-Implementation-Version: 1.0.3
>>>javahelp-Implementation-Vendor-Id: com.sun
>>>javahelp-Implementation-URL:
>>>http://java.sun.com/products/stdext/javahelp.jar
>>>java3d-Extension-Name: javax.3d
>>>java3d-Specification-Version: 1.0
>>>java3d-Implementation-Version: 1.2.1
>>>java3d-Implementation-Vendor-Id: com.sun
>>>java3d-Implementation-URL:
>>>
>>>
>>http://java.sun.com/products/stdext/java3d.jar
>>
>>
>>>3. Why not
>>>
>>>
>>include download URL locations?
>>
>>
>>>See example above.
>>>
>>>Can someone tell me the component responsible for creating
>>>
>>>
>>the manifest
>>
>>
>>>files in maven?
>>>
>>>Is this a known issue (I did not find it on the user mailing list)?
>>>Can this feature be added in future releases?
>>>
>>>Thanks,
>>>Vincenz
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
>>>turbine-maven-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>
>>>
>>turbine-maven-user-help@jakarta.apache.org
>>
>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail:
>>turbine-maven-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>turbine-maven-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
>
>
>
>