RE: Solution?
Yes, you could do this with ant filters, or a maven script that substituted them using either velocity, XSLT or JSL. - Brett > -Original Message- > From: Francois Beauregard [mailto:[EMAIL PROTECTED] > Sent: Thursday, 4 December 2003 4:07 PM > To: [EMAIL PROTECTED] > Subject: Solution? > > > Here is the situation I have and would like to know if there > is a simple solution currently with Maven. > > We have a web application that we build using Maven and this > application uses Hibernate. Every developer use their own > schema in an Oracle DB. The connection properties are set in > a build.properties file that is different on every developers > workstation. We already have goals that are parameterized > with these properties that runs sql scripts against the > database. Fine till now. > > What I would like to do is have our hibernate.properties > stored in cvs as hibernate.properties.template and in my > goals be able to use velocity to replace placeholders with > the values of the connection properties. > > Thanks, > François > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Solution?
Here is the situation I have and would like to know if there is a simple solution currently with Maven. We have a web application that we build using Maven and this application uses Hibernate. Every developer use their own schema in an Oracle DB. The connection properties are set in a build.properties file that is different on every developers workstation. We already have goals that are parameterized with these properties that runs sql scripts against the database. Fine till now. What I would like to do is have our hibernate.properties stored in cvs as hibernate.properties.template and in my goals be able to use velocity to replace placeholders with the values of the connection properties. Thanks, François - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with checkstyle plugin not recognizing config file
Copy the new plugin into %MAVEN_HOME%/plugins. Remove the old one. Remove ~/.maven/plugins (if it exists - I don't remember if that was introduced at b9 or b10). I -highly- recommend getting Maven RC1. Not only does it have the new plugin, but it has a simple plugin download/installation method. - Brett > -Original Message- > From: Chad Woolley [mailto:[EMAIL PROTECTED] > Sent: Thursday, 4 December 2003 2:43 PM > Cc: [EMAIL PROTECTED] > Subject: problems with checkstyle plugin not recognizing config file > > > Hi, > > I have read this: > http://maven.apache.org/reference/plugins/checkstyle/migrating .html However, I can't get the checkstyle plugin to recognize my config file. When I make a change (changing line length to 90, for example), the new rule is not reflected in the report. I think this may be because I am using beta 9, which doesn't seem to use the version 2.x plugin. I downloaded the 2.0 plugin, but I don't know how to force maven to use the new plugin. What am I doing wrong? Thanks, Chad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problems with checkstyle plugin not recognizing config file
Hi, I have read this: http://maven.apache.org/reference/plugins/checkstyle/migrating.html However, I can't get the checkstyle plugin to recognize my config file. When I make a change (changing line length to 90, for example), the new rule is not reflected in the report. I think this may be because I am using beta 9, which doesn't seem to use the version 2.x plugin. I downloaded the 2.0 plugin, but I don't know how to force maven to use the new plugin. What am I doing wrong? Thanks, Chad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No hrefs getting included from navigation.xml
Jason van Zyl wrote: Try following the same pattern we use: http://cvs.apache.org/viewcvs.cgi/maven/xdocs/navigation.xml?rev=1.33&content-type=text/vnd.viewcvs-markup And register an issue in JIRA here: http://jira.codehaus.org/secure/BrowseProject.jspa?id=10355 The plugin should be smart enough to work without the leading slash. Jason, Thanks for the input, but no amount of leading slashes or dots would work. However, rolling back to Maven 1.0 beta 9 fixed everything. This is definitely a bug in RC1. Here's the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?id=12877 Thanks for your help, Chad FYI - I originally upgraded to RC1 because my checkstyle broke on one of my machines. RC1 didn't fix it, so I'll stick with beta 9 for a while longer :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No hrefs getting included from navigation.xml
While the plugin shouldn't be producing empty hrefs, the leading slash is mandatory. Without a leading slash, xdoc will create relative links rather than an absolute link to the root of the documentation structure. As usual, this can't be changed as there is existing documentation relying on this behaviour (you've probably discovered an "edge" case for the logic) Jason van Zyl wrote: On Wed, 2003-12-03 at 17:20, Chad Woolley wrote: Hi, My site:generate goal no longer puts the href in for the links, the generated href is blank. In navigation.xml, this: ...generates this: Overview News Can anyone help with this? How can I debug it? I deployed before I noticed and now my site is hosed :0 Try following the same pattern we use: http://cvs.apache.org/viewcvs.cgi/maven/xdocs/navigation.xml?rev=1.33&content-type=text/vnd.viewcvs-markup And register an issue in JIRA here: http://jira.codehaus.org/secure/BrowseProject.jspa?id=10355 The plugin should be smart enough to work without the leading slash. I just noticed this problem after I upgraded to 1.0 RC 1 (not sure if the new release is the problem). Thanks, Chad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle jar dependencies to jars with licensing issues ?
Basically you put them in [project]/lib or similar then use jar overrides http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Dependencies Jörg Schaible wrote: Hi, what is the standard way to handle dependencies to jars that are no longer available at ibiblio due to licensing issues? I have currently an out-dated example referencing xmprpc-1.0 and saaj-1.1 that seem to be available once in the repository. Additionally if you would like to depend on libraries from the new J2EE 1.4 - would you just add them to your classpath or let Maven handle them using dependencies? I googled and searched the archives, but I did not come up with anything usefull. Any hints welcome ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No hrefs getting included from navigation.xml
On Wed, 2003-12-03 at 17:20, Chad Woolley wrote: > Hi, > > My site:generate goal no longer puts the href in for the links, the > generated href is blank. > > In navigation.xml, this: > > > > > > > ...generates this: > > > > Overview > > > > > News > > > > > Can anyone help with this? How can I debug it? I deployed before I > noticed and now my site is hosed :0 Try following the same pattern we use: http://cvs.apache.org/viewcvs.cgi/maven/xdocs/navigation.xml?rev=1.33&content-type=text/vnd.viewcvs-markup And register an issue in JIRA here: http://jira.codehaus.org/secure/BrowseProject.jspa?id=10355 The plugin should be smart enough to work without the leading slash. > I just noticed this problem after I upgraded to 1.0 RC 1 (not sure if > the new release is the problem). > > Thanks, > Chad > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
No hrefs getting included from navigation.xml
Hi, My site:generate goal no longer puts the href in for the links, the generated href is blank. In navigation.xml, this: ...generates this: Overview News Can anyone help with this? How can I debug it? I deployed before I noticed and now my site is hosed :0 I just noticed this problem after I upgraded to 1.0 RC 1 (not sure if the new release is the problem). Thanks, Chad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCoverage plugin problem
What's you jcoverage plugin version? Emmanuel - Original Message - From: "Scott Brickner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 9:08 PM Subject: JCoverage plugin problem > I just added the jcoverage report to my project and it's not running > right. Has anyone seen this before? The actual text referenced in the > exception is "\357\277\275". > > The output of the JCoverage task is below... > > jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ > jcoverage is licensed under the GNU General Public License > jcoverage comes with ABSOLUTELY NO WARRANTY > Generate report for > /home/scottb/projects/verona/target/jcoverage/coverage.xml file. > OutputDir = /home/scottb/projects/verona/target/docs/jcoverage > java.lang.NumberFormatException: For input string: "ï" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:48 ) > at > java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1207) > at java.lang.Double.valueOf(Double.java:202) > at java.lang.Double.(Double.java:277) > at > org.apache.maven.jcoveragereport.CoverageReport.generatePercentResult(Covera geReport.java:493) > at > org.apache.maven.jcoveragereport.CoverageReport.generateSourceFile(CoverageR eport.java:425) > at > org.apache.maven.jcoveragereport.CoverageReport.generateSourceFiles(Coverage Report.java:391) > at > org.apache.maven.jcoveragereport.CoverageReport.generate(CoverageReport.java :96) > at > org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(CoverageRep ortGenerator.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) > at > org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at > org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:87) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at > org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at org.apache.commons.jelly.tags.core.CatchTag.doTag(CatchTag.java:90) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) > at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) > at > org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag. java:107) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) > at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) > at > org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag. java:107) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at > org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) > at com.werken.werkz.Goal.fire(Goal.jav
Re: How to handle jar dependencies to jars with licensing issues ?
Or create a new repository for your company and set maven.repo.remote to contain your repository after ibiblio (or before ?). Paul Jörg Schaible wrote: what is the standard way to handle dependencies to jars that are no longer available at ibiblio due to licensing issues? I have currently an out-dated example referencing xmprpc-1.0 and saaj-1.1 that seem to be available once in the repository. Additionally if you would like to depend on libraries from the new J2EE 1.4 - would you just add them to your classpath or let Maven handle them using dependencies? I googled and searched the archives, but I did not come up with anything usefull. Any hints welcome ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JCoverage plugin problem
I just added the jcoverage report to my project and it's not running right. Has anyone seen this before? The actual text referenced in the exception is "\357\277\275". The output of the JCoverage task is below... jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY Generate report for /home/scottb/projects/verona/target/jcoverage/coverage.xml file. OutputDir = /home/scottb/projects/verona/target/docs/jcoverage java.lang.NumberFormatException: For input string: "ï" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1207) at java.lang.Double.valueOf(Double.java:202) at java.lang.Double.(Double.java:277) at org.apache.maven.jcoveragereport.CoverageReport.generatePercentResult(CoverageReport.java:493) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFile(CoverageReport.java:425) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFiles(CoverageReport.java:391) at org.apache.maven.jcoveragereport.CoverageReport.generate(CoverageReport.java:96) at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(CoverageReportGenerator.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:87) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.CatchTag.doTag(CatchTag.java:90) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.j
RE: How to pass arguments to JVM
Your commandline for javadoc is too long, you need to use a file to intermediate. Simply set the property maven.javadoc.useexternalfile to true in your project.properties, and that should clear it up. Nick > -Original Message- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: 03 December 2003 16:53 > To: Maven Users List > Subject: Re: How to pass arguments to JVM > > > Thank you ! > > > I get another error when using maven javadoc : > > BUILD FAILED > File.. file:/C:/Documents and > Settings/ndeloof/.maven/plugins/maven-javadoc- > plugin-1.3/ > Element... ant:javadoc > Line.. 106 > Column 60 > Javadoc failed: java.io.IOException: CreateProcess: > C:\j2sdk1.4.2\bin\javadoc.ex > > (...) > > Caused by: java.io.IOException: CreateProcess: > C:\j2sdk1.4.2\bin\javadoc.exe -us > e -stylesheetfile "C:\Documents and > Settings\ndeloof\.maven\plugins\maven-javado > c-plugin-1.3\plugin-resources\stylesheet.css" -d > C:\eclipse\workspace\pacila-web > app\target\docs\apidocs -windowtitle "pacila-webapp 1.0-dev > API" -doctitle "paci > la-webapp 1.0-dev API" -bottom "Copyright © 2003 Telecom > Media & Network Fr > ance. All Rights Reserved." -classpath "C:\Documents and > Settings\ndeloof\.maven > \repository\log4j\jars\log4j-1.2.8.jar;C:\Documents and > Settings\ndeloof\.maven\ > repository\struts\jars\struts-1.1.jar;C:\Documents and > Settings\ndeloof\.maven\r > epository\commons-beanutils\jars\commons-beanutils-1.6.jar;C:\ > Documents and Sett > ings\ndeloof\.maven\repository\commons-collections\jars\common > s-collections-2.1. > jar;C:\Documents and > Settings\ndeloof\.maven\repository\commons-digester\jars\co > mmons-digester-1.5.jar;C:\Documents and > Settings\ndeloof\.maven\repository\commo > ns-fileupload\jars\commons-fileupload-1.0.jar;C:\Documents > and Settings\ndeloof\ > .maven\repositor? > at java.lang.Win32Process.create(Native Method) > at java.lang.Win32Process.(Win32Process.java:66) > at java.lang.Runtime.execInternal(Native Method) > at java.lang.Runtime.exec(Runtime.java:566) > ... > > > What to do ? > > Nico > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pass arguments to JVM
Thank you ! I get another error when using maven javadoc : BUILD FAILED File.. file:/C:/Documents and Settings/ndeloof/.maven/plugins/maven-javadoc- plugin-1.3/ Element... ant:javadoc Line.. 106 Column 60 Javadoc failed: java.io.IOException: CreateProcess: C:\j2sdk1.4.2\bin\javadoc.ex (...) Caused by: java.io.IOException: CreateProcess: C:\j2sdk1.4.2\bin\javadoc.exe -us e -stylesheetfile "C:\Documents and Settings\ndeloof\.maven\plugins\maven-javado c-plugin-1.3\plugin-resources\stylesheet.css" -d C:\eclipse\workspace\pacila-web app\target\docs\apidocs -windowtitle "pacila-webapp 1.0-dev API" -doctitle "paci la-webapp 1.0-dev API" -bottom "Copyright © 2003 Telecom Media & Network Fr ance. All Rights Reserved." -classpath "C:\Documents and Settings\ndeloof\.maven \repository\log4j\jars\log4j-1.2.8.jar;C:\Documents and Settings\ndeloof\.maven\ repository\struts\jars\struts-1.1.jar;C:\Documents and Settings\ndeloof\.maven\r epository\commons-beanutils\jars\commons-beanutils-1.6.jar;C:\Documents and Sett ings\ndeloof\.maven\repository\commons-collections\jars\commons-collections-2.1. jar;C:\Documents and Settings\ndeloof\.maven\repository\commons-digester\jars\co mmons-digester-1.5.jar;C:\Documents and Settings\ndeloof\.maven\repository\commo ns-fileupload\jars\commons-fileupload-1.0.jar;C:\Documents and Settings\ndeloof\ .maven\repositor? at java.lang.Win32Process.create(Native Method) at java.lang.Win32Process.(Win32Process.java:66) at java.lang.Runtime.execInternal(Native Method) at java.lang.Runtime.exec(Runtime.java:566) ... What to do ? Nico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to pass arguments to JVM
You need to set the environment variable MAVEN_OPTS. So do: set MAVEN_OPTS=-Xmx256m maven site Or adapt appropriately if you're not Windows based. Nick > -Original Message- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: 03 December 2003 16:11 > To: Maven Users List > Subject: How to pass arguments to JVM > > > Hi, > > I want to generate doc for a huge application. Javadoc fails > because of out of memory. How to set jvm max memory arg > (-Xmx) when using maven ? > > I tried "maven -Xmx256 site", but it fails. > > Nico. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to pass arguments to JVM
Hi, I want to generate doc for a huge application. Javadoc fails because of out of memory. How to set jvm max memory arg (-Xmx) when using maven ? I tried "maven -Xmx256 site", but it fails. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
aspectj is putting my entire project into .jar
Hello.
I have been digging through the mail-archive and I haven't found
anyone else with this problem yet. When I run "maven aspectj"
it creates a jar "target/myproject-1.0.jar". Thing is, it has
EVERYTHING in it. As in, everything under "src". And, if I run
it again, it will rebuild the jar with everything under "src"
AND "target". Its insane. I almost ran out of disk space because
I had run it a few times and it kept putting itself inside of
itself.
Here is the build section of my project.xml
[EMAIL PROTECTED]
src/main/java
src/test/java
src/main/aspects
src/main/resources
*.properties
*.dtd
*.xml
I also have: maven.compile.aspects = true.
Any ideas on why it would create such a jar? It is jar-ring up everything
under ${basedir}. I know I have to have something wrong in one of my
properties, I just can't find it.
Thanks a lot.
Charlie
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle jar dependencies to jars with licensing issues ?
On Wed, 2003-12-03 at 09:54, Jörg Schaible wrote: > Hi, > > what is the standard way to handle dependencies to jars that are no longer available > at ibiblio due to licensing issues? I have currently an out-dated example > referencing xmprpc-1.0 and saaj-1.1 that seem to be available once in the repository. Just manually put them in your local repository. > Additionally if you would like to depend on libraries from the new J2EE 1.4 - would > you just add them to your classpath or let Maven handle them using dependencies? > > I googled and searched the archives, but I did not come up with anything usefull. > Any hints welcome ... > > Regards, > Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get XSLT working within MAVEN
On Wed, 2003-12-03 at 03:00, "GÃschl,Siegfried" wrote: > I also had various problems but got it working ... checkout the JavaNCSS and > SDOCBOOK plugin ion http://maven-plugins.sourceforge.net. Aha! I just started using the JavaNCSS plugin, too. Okay, I see how the plugin is doing it. I was trying to use the Xslt Ant task, but couldn't get around various classpath problems. (For those of you playing along at home, JavaNCSS uses .) If I ever redo that part of my project, I'll probably switch to something like this. > I think someone should write a XSLT plugin using DynaTags, i.e. allowing you to pass > the parameter dynamically Hmm. Is there room in the fire for *one* more iron? :-) Thanks for your comments -- Craig S. Cottingham [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to handle jar dependencies to jars with licensing issues ?
Hi, what is the standard way to handle dependencies to jars that are no longer available at ibiblio due to licensing issues? I have currently an out-dated example referencing xmprpc-1.0 and saaj-1.1 that seem to be available once in the repository. Additionally if you would like to depend on libraries from the new J2EE 1.4 - would you just add them to your classpath or let Maven handle them using dependencies? I googled and searched the archives, but I did not come up with anything usefull. Any hints welcome ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts dependent artefacts
This is a neat approach. Maybe I could store the "entities" in the repository so that they are available to multiple projects. Thanks -Original Message- From: khote [mailto:[EMAIL PROTECTED] Sent: 03 December 2003 10:18 To: Maven Users List Subject: Re: Struts dependent artefacts in my project root, I create a subdirectory called "entities" to store these commonly included things. In a subproject at the top of the project.xml ]> &xdoclet-common; &jboss-common; The only problem with this that I haven't resolved yet is that you must run the subproject from the parent, for example: cd /blah/parentprojectdirectory maven -p subproject/project.xml java:compile if you go into subproject and maven java:compile it will complain about not finding the files. - Original Message - From: "Geddes, Mark (ANTS)" <[EMAIL PROTECTED]> To: "'Maven Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 2:13 AM Subject: RE: Struts dependent artefacts > Yes, but there is only one level of inheritance. I am declaring these > dependencies in my project's top-level project.xml, and I have multiple > sub-projects (ejbs, war, ear) which extend the top-level project. > The problem is that I have several other J2EE projects with the same > structure, and I am having to repeat this _logic_. I'm looking for an > approach based on _composition_ rather than _inheritance_. > Thanks anyway, > > Mark > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 03 December 2003 09:28 > To: [EMAIL PROTECTED] > Subject: RE: Struts dependent artefacts > > > You can inherit the dependecies from another project with the > tag. > Look at: http://maven.apache.org/reference/project-descriptor.html > > -Original Message- > From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 3. Dezember 2003 10:13 > To: '[EMAIL PROTECTED]' > Subject: Struts dependent artefacts > > > Hi, > Apologies if this has been asked before - I searched the archives but > didn't > find the answer I was looking for. I am in the process of migrating > several > projects from an in-house build system to the excellent Maven. We tend > to > package everything as EAR archives, and we make extensive use of Struts. > The > in-house system leans heavily on the ideas from 'Java Development with > Ant' > (Hatcher, Loughran), specifically we store versions of Struts in version > specific directories. So a 'struts-1.1' directory will contain all the > jars > and tlds for that version. The Ant script will copy all the runtime > required > jars and tlds from the directory into the appropriate build area. The > version is controlled through a property, so migrating between versions > has > been seamless. > I am now using Maven's dependency mechanism, and have come up with > something > like this for Struts-1.1: > > > struts > struts > 1.1 > > true > > > > struts > struts-logic > 1.1 > tld > > true > > > > struts > struts-bean > 1.1 > tld > > true > > > > struts > struts-html > 1.1 > tld > > true > > > > struts > struts-nested > 1.1 > tld > > true > > > > struts > struts-template > 1.1 > tld > > true > > > > struts > struts-tiles > 1.1 > tld > > true > > > > commons-beanutils > commons-beanutils > 1.6 > > true > > > > commons-digester > commons-digester > 1.5 > > true > > > > commons-collections > commons-collections > 2.1 > > true > > > > commons-fileupload > commons-fileupload > 1.0 > > true > > > > commons-logging > commons-logging > 1.0.3 > > true > > > > commons-lang > commons-lang > 1.0.1 > > true > > > > commons-validator > commons-validator > 1.0.2 > > true > > > > oro > oro > 2.0.6 > > true > > > > This is fine. The problem is that I have to duplicate this for each > project. > Is there a simple way to re-use this _logic_ across multiple projects, > or am > I heading up the wrong path? > Any ideas gratefully received. > > Mark > > > > *** > This communication (including any attachments) contains confidential > information. If you are not the intended recipient and you have > received this communication in error, you should destroy it without > copying, disclosing or otherwise using its contents. Please notify the > sender immediately of the error. > > Internet communications are not necessarily secure and may be > intercepted or changed after they are sent. Abbey National Treasury > Services plc does not accept liability for any loss you may suffer as a > result of interception or any liability for such changes. If you wish > to confirm the origin or content of this communication, please contact > the sender by using an alternative means of communication. > > This communication does not create or modify any contract and, unless > otherwise stated, is not intended to be contractually binding. > > Abbey National Treasury Servic
Re: Struts dependent artefacts
in my project root, I create a subdirectory called "entities" to store these commonly included things. In a subproject at the top of the project.xml ]> &xdoclet-common; &jboss-common; The only problem with this that I haven't resolved yet is that you must run the subproject from the parent, for example: cd /blah/parentprojectdirectory maven -p subproject/project.xml java:compile if you go into subproject and maven java:compile it will complain about not finding the files. - Original Message - From: "Geddes, Mark (ANTS)" <[EMAIL PROTECTED]> To: "'Maven Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 2:13 AM Subject: RE: Struts dependent artefacts > Yes, but there is only one level of inheritance. I am declaring these > dependencies in my project's top-level project.xml, and I have multiple > sub-projects (ejbs, war, ear) which extend the top-level project. > The problem is that I have several other J2EE projects with the same > structure, and I am having to repeat this _logic_. I'm looking for an > approach based on _composition_ rather than _inheritance_. > Thanks anyway, > > Mark > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 03 December 2003 09:28 > To: [EMAIL PROTECTED] > Subject: RE: Struts dependent artefacts > > > You can inherit the dependecies from another project with the > tag. > Look at: http://maven.apache.org/reference/project-descriptor.html > > -Original Message- > From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 3. Dezember 2003 10:13 > To: '[EMAIL PROTECTED]' > Subject: Struts dependent artefacts > > > Hi, > Apologies if this has been asked before - I searched the archives but > didn't > find the answer I was looking for. I am in the process of migrating > several > projects from an in-house build system to the excellent Maven. We tend > to > package everything as EAR archives, and we make extensive use of Struts. > The > in-house system leans heavily on the ideas from 'Java Development with > Ant' > (Hatcher, Loughran), specifically we store versions of Struts in version > specific directories. So a 'struts-1.1' directory will contain all the > jars > and tlds for that version. The Ant script will copy all the runtime > required > jars and tlds from the directory into the appropriate build area. The > version is controlled through a property, so migrating between versions > has > been seamless. > I am now using Maven's dependency mechanism, and have come up with > something > like this for Struts-1.1: > > > struts > struts > 1.1 > > true > > > > struts > struts-logic > 1.1 > tld > > true > > > > struts > struts-bean > 1.1 > tld > > true > > > > struts > struts-html > 1.1 > tld > > true > > > > struts > struts-nested > 1.1 > tld > > true > > > > struts > struts-template > 1.1 > tld > > true > > > > struts > struts-tiles > 1.1 > tld > > true > > > > commons-beanutils > commons-beanutils > 1.6 > > true > > > > commons-digester > commons-digester > 1.5 > > true > > > > commons-collections > commons-collections > 2.1 > > true > > > > commons-fileupload > commons-fileupload > 1.0 > > true > > > > commons-logging > commons-logging > 1.0.3 > > true > > > > commons-lang > commons-lang > 1.0.1 > > true > > > > commons-validator > commons-validator > 1.0.2 > > true > > > > oro > oro > 2.0.6 > > true > > > > This is fine. The problem is that I have to duplicate this for each > project. > Is there a simple way to re-use this _logic_ across multiple projects, > or am > I heading up the wrong path? > Any ideas gratefully received. > > Mark > > > > *** > This communication (including any attachments) contains confidential > information. If you are not the intended recipient and you have > received this communication in error, you should destroy it without > copying, disclosing or otherwise using its contents. Please notify the > sender immediately of the error. > > Internet communications are not necessarily secure and may be > intercepted or changed after they are sent. Abbey National Treasury > Services plc does not accept liability for any loss you may suffer as a > result of interception or any liability for such changes. If you wish > to confirm the origin or content of this communication, please contact > the sender by using an alternative means of communication. > > This communication does not create or modify any contract and, unless > otherwise stated, is not intended to be contractually binding. > > Abbey National Treasury Services plc. Registered Office: Abbey National > House, 2 Triton Square, Regents Place, London NW1 3AN. Registered in > England under Company Registration Number: 2338548. Regulated by the > Financial Services Authority (FSA). > ***
RE: Struts dependent artefacts
Yes, but there is only one level of inheritance. I am declaring these dependencies in my project's top-level project.xml, and I have multiple sub-projects (ejbs, war, ear) which extend the top-level project. The problem is that I have several other J2EE projects with the same structure, and I am having to repeat this _logic_. I'm looking for an approach based on _composition_ rather than _inheritance_. Thanks anyway, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 03 December 2003 09:28 To: [EMAIL PROTECTED] Subject: RE: Struts dependent artefacts You can inherit the dependecies from another project with the tag. Look at: http://maven.apache.org/reference/project-descriptor.html -Original Message- From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 3. Dezember 2003 10:13 To: '[EMAIL PROTECTED]' Subject: Struts dependent artefacts Hi, Apologies if this has been asked before - I searched the archives but didn't find the answer I was looking for. I am in the process of migrating several projects from an in-house build system to the excellent Maven. We tend to package everything as EAR archives, and we make extensive use of Struts. The in-house system leans heavily on the ideas from 'Java Development with Ant' (Hatcher, Loughran), specifically we store versions of Struts in version specific directories. So a 'struts-1.1' directory will contain all the jars and tlds for that version. The Ant script will copy all the runtime required jars and tlds from the directory into the appropriate build area. The version is controlled through a property, so migrating between versions has been seamless. I am now using Maven's dependency mechanism, and have come up with something like this for Struts-1.1: struts struts 1.1 true struts struts-logic 1.1 tld true struts struts-bean 1.1 tld true struts struts-html 1.1 tld true struts struts-nested 1.1 tld true struts struts-template 1.1 tld true struts struts-tiles 1.1 tld true commons-beanutils commons-beanutils 1.6 true commons-digester commons-digester 1.5 true commons-collections commons-collections 2.1 true commons-fileupload commons-fileupload 1.0 true commons-logging commons-logging 1.0.3 true commons-lang commons-lang 1.0.1 true commons-validator commons-validator 1.0.2
How to declare compile-time / run-time dependencies
Hi, My project has some dependencies that are needed for test classes (compile/build-time) but not at runtime : junit, cactus, easymock ... How to set my project.xml so that they aren't visible in generated doc as dependencies, so that users can have a list of runtime-dependencies (what they need if they want to use my tools) ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts dependent artefacts
You can inherit the dependecies from another project with the tag. Look at: http://maven.apache.org/reference/project-descriptor.html -Original Message- From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 3. Dezember 2003 10:13 To: '[EMAIL PROTECTED]' Subject: Struts dependent artefacts Hi, Apologies if this has been asked before - I searched the archives but didn't find the answer I was looking for. I am in the process of migrating several projects from an in-house build system to the excellent Maven. We tend to package everything as EAR archives, and we make extensive use of Struts. The in-house system leans heavily on the ideas from 'Java Development with Ant' (Hatcher, Loughran), specifically we store versions of Struts in version specific directories. So a 'struts-1.1' directory will contain all the jars and tlds for that version. The Ant script will copy all the runtime required jars and tlds from the directory into the appropriate build area. The version is controlled through a property, so migrating between versions has been seamless. I am now using Maven's dependency mechanism, and have come up with something like this for Struts-1.1: struts struts 1.1 true struts struts-logic 1.1 tld true struts struts-bean 1.1 tld true struts struts-html 1.1 tld true struts struts-nested 1.1 tld true struts struts-template 1.1 tld true struts struts-tiles 1.1 tld true commons-beanutils commons-beanutils 1.6 true commons-digester commons-digester 1.5 true commons-collections commons-collections 2.1 true commons-fileupload commons-fileupload 1.0 true commons-logging commons-logging 1.0.3 true commons-lang commons-lang 1.0.1 true commons-validator commons-validator 1.0.2 true oro oro 2.0.6 true This is fine. The problem is that I have to duplicate this for each project. Is there a simple way to re-use this _logic_ across multiple projects, or am I heading up the wrong path? Any ideas gratefully received. Mark *
Struts dependent artefacts
Hi, Apologies if this has been asked before - I searched the archives but didn't find the answer I was looking for. I am in the process of migrating several projects from an in-house build system to the excellent Maven. We tend to package everything as EAR archives, and we make extensive use of Struts. The in-house system leans heavily on the ideas from 'Java Development with Ant' (Hatcher, Loughran), specifically we store versions of Struts in version specific directories. So a 'struts-1.1' directory will contain all the jars and tlds for that version. The Ant script will copy all the runtime required jars and tlds from the directory into the appropriate build area. The version is controlled through a property, so migrating between versions has been seamless. I am now using Maven's dependency mechanism, and have come up with something like this for Struts-1.1: struts struts 1.1 true struts struts-logic 1.1 tld true struts struts-bean 1.1 tld true struts struts-html 1.1 tld true struts struts-nested 1.1 tld true struts struts-template 1.1 tld true struts struts-tiles 1.1 tld true commons-beanutils commons-beanutils 1.6 true commons-digester commons-digester 1.5 true commons-collections commons-collections 2.1 true commons-fileupload commons-fileupload 1.0 true commons-logging commons-logging 1.0.3 true commons-lang commons-lang 1.0.1 true commons-validator commons-validator 1.0.2 true oro oro 2.0.6 true This is fine. The problem is that I have to duplicate this for each project. Is there a simple way to re-use this _logic_ across multiple projects, or am I heading up the wrong path? Any ideas gratefully received. Mark *** This communication (including any attachments) contains confidential information. If you are not the intended recipient and you have received this communication in error, you should destroy it without copying, disclosing or otherwise using its contents. Please notify the sender immediately of the err
Re: Torque Plugin in Eclipse
Me too, in fact the (my) torque plugin generate error in source code
/**
* Stores the object in the database. If the object is new,
* it inserts it; otherwise an update is performed.
*
* @throws $saveException
*/
public void save() throws $saveException
{
save(AnomaliePeer.getMapBuilder()
.getDatabaseMap().getName());
}
I only have to modify $saveException to Exception.
I am using the same schema.xml then the one that is working correctly in
torque-gen 3.1
I try to go for the cvs, but it seem to be instanble because plugin move from
one folder to another.
Apache Foudantion is doing a great job, I would like to help, but this is
difficult some time.
Le Mardi 2 Décembre 2003 19:50, Vikas Phonsa a écrit :
> Yeah Charles I'm able to do all that, its just the torque plugin that I'm
> not able to use.
>
> Anyways we can't expect the torque programmers to make everything work for
> us, they have already done a great job by making torque and maven and
> everything else on Apache.
>
> I'll find some way.
>
> And by the way I was able to run Torque ant script and perform all the
> functions that it does inside my IDE. But not with the maven torque plugin.
> Just running the tasks in build-torque.xml
>
> Thanks
>
> Vikas
>
>
>
> -Original Message-
> From: Charles-Alexandre Sabourdin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2003 9:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Torque Plugin in Eclipse
>
> I means that I can import my maven project into exclipse usin create new
> project (i do not use default) look for teh root of my project an there i
> have an eclipse project with all the jars I need to compile.
> And It does compile into target.
>
> but I only use a simple project.
>
> so what I means is that tha project is created using all the valu from
> project.xml.
>
> Le Mardi 2 Décembre 2003 18:01, Vikas Phonsa a écrit :
> > Hi Charles,
> > What do u mean when u say that the project is correctly created ?
> >
> > Thanks
> > Vikas
> >
> > -Original Message-
> > From: Charles-Alexandre Sabourdin [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 02, 2003 5:37 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Torque Plugin in Eclipse
> >
> > I tried, with no succes with the external tools
> > but the project is correctly created
> >
> > Le Lundi 1 Décembre 2003 20:01, Vikas Phonsa a écrit :
> > > Hi,
> > >
> > > Has anybody tried using the Torque Plugin configured as an External
> > > tool from within Eclipse.
> > >
> > > I would like to know how to use that in Eclipse, what the directory
> > > structure should be, where to place build.xml and other files, where
> > > the generated sql and java code would go and other configuration steps.
> > >
> > > Thanks
> > >
> > > Vikas
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
--
Charles-Alexandre
SABOURDIN
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for NTLM proxy authentication?
Hi Eng, If you don't want to wait for Wagon try this... http://www.geocities.com/rozmanov/ntlm/ Works great for me... -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 03 de diciembre de 2003 4:44 Para: Maven Users List Asunto: Re: Support for NTLM proxy authentication? That's good news. What is Wagon and when is it going to be incorporated into Maven? Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Jason van Zyl <[EMAIL PROTECTED] To: Maven Users List <[EMAIL PROTECTED]> .org>cc: Subject: Re: Support for NTLM proxy authentication? 03/12/2003 11:19 AM Please respond to "Maven Users List" On Tue, 2003-12-02 at 22:05, [EMAIL PROTECTED] wrote: > NTLM is a proprietary protocol designed by Microsoft. Currently, I know > that Jakarta Commons-HttpClient project is able to support NTLM > authentication. CVSGrab, for example, is using HttpClient to make HTTP > connection, and hence it also implicitly support NTLM. > > I don't know how many proxy servers out there in the world is configured > with NTLM authentication. I do hope enough people can support me to make > the NTLM feature possible in Maven. Otherwise, people like me who is > behind such proxy server would not be able to enjoy the benefits of Maven. Wagon, the new artifact project within Maven (the top-level Apache project), uses httpclient so you'll probably get it for free when we start using Wagon inside Maven (the tool you're using) itself. > > Regards, > Eng Hoe > App Dev-DCS > SGX-IT Division > > DID: (65) 62368963 > FAX: (65) 64388840 > email: [EMAIL PROTECTED] > > > > Jason van Zyl > <[EMAIL PROTECTED] To: Maven Users List <[EMAIL PROTECTED]> > .org>cc: > Subject: Re: Support for NTLM proxy authentication? > 03/12/2003 > 10:47 AM > Please respond > to "Maven > Users List" > > > > > > > On Tue, 2003-12-02 at 21:38, [EMAIL PROTECTED] wrote: > > Our proxy server is using NTLM authentication. Currently, Maven does not > > seems to support this kind of authentication protocol (correct me if I am > > wrong). Hence, I am not able to download files from the remote > repository, > > which is quite essential in order to use Maven. Is there any plan to add > > support for NTLM authentication for future release? > > If I knew what NTLM authentication was and several users requested it > then possibly but no one else has raised the issue. > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > Confidentiality Caution > === > Privileged/Confidential Information may be contained in this message. If > you are not the addressee indicated in this message (or responsible for > delivery of the message to such person), you may not copy or deliver this > message to anyone. In such case, you should destroy this message and kindly > notify the sender by reply email. Opinions, conclusions and other > information in this message that is not of an official nature shall be > deemed as neither given nor endorsed by SGX unless indicated by an > authorised representative independent of this message. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify
