Re: Upgrading to 1.0RC3 - exception thrown when listing goals
Hi all. I'm getting the same exception, but using ClearCase. Has the ClearCase connection string changed from the following: repository connection scm:clearcase: /connection /repository I assume the maven-changelog-plugin still reads this setting when generating the report? Best regards.Mvh. Jan-Helge -- Jan-Helge Bergesen, AXXESSIT ASA (http://www.axxessit.no) Tlf: 55 two2 49 75, ICQ: six5412239, MSN: jahebe_6six[EMAIL PROTECTED] Dion Gillard [EMAIL PROTECTED] 25.05.2004 01:03 Please respond to Maven Users List To: Maven Users List [EMAIL PROTECTED] cc: Subject:Re: Upgrading to 1.0RC3 - exception thrown when listing goals It was the repository connection string. throws Exception is an abomination. On Tue, 25 May 2004 08:58:36 +1000, Brett Porter [EMAIL PROTECTED] wrote: What happened? (Maybe we need to document something?) Also, it would have been good to see the first exception you got. As of RC3, removing the local plugins directory will just save space - it should only use plugins that are actually installed as JARs. - Brett -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Omair-Inam Abdul-Matin Sent: Tuesday, 25 May 2004 7:47 AM To: [EMAIL PROTECTED] Subject: Re: Upgrading to 1.0RC3 - exception thrown when listing goals Never mind, Problem solved. Omair Omair-Inam Abdul-Matin wrote: I installed Maven 1.0RC3. The first time I forgot to remove the local plugins directory and maven threw a nasty exception and quit on me. I then uninstalled it, removed the local plugin directory and reinstalled it. Now when I call maven -g, maven lists the goal but it throws the following exception first: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc3 [MethodExpression] Cannot evaluate expression java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.betwixt.expression.MethodExpression.evaluat e(MethodExpression.java:96) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeContent( AbstractBeanWriter.java:658) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeRestOfEl ement(AbstractBeanWriter.java:539) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:481) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeContent( AbstractBeanWriter.java:643) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeRestOfEl ement(AbstractBeanWriter.java:539) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:513) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:233) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeContent( AbstractBeanWriter.java:630) at org.apache.commons.betwixt.io.AbstractBeanWriter.writeRestOfEl ement(AbstractBeanWriter.java:539) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:513) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:233) at org.apache.commons.betwixt.io.AbstractBeanWriter.write(Abstrac tBeanWriter.java:162) at org.apache.commons.betwixt.io.BeanWriter.write(BeanWriter.java:217) at org.apache.maven.MavenUtils.getProjectString(MavenUtils.java:421) at org.apache.maven.MavenUtils.getInterpolatedPOM(MavenUtils.java:372) at org.apache.maven.MavenUtils.getJellyProject(MavenUtils.java:349) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:144) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSessi on.java:235) at org.apache.maven.MavenSession.initialize(MavenSession.java:175) at org.apache.maven.cli.App.doMain(App.java:472) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused
Réf. : in href in xdoc
Hello Karl Your problem looks like the http://jira.codehaus.org/browse/MPXDOC-92 , is it right ? Julien Extranet [EMAIL PROTECTED] - 24/05/2004 23:45 Veuillez répondre à [EMAIL PROTECTED] Pour : users cc : Objet : in href in xdoc I am trying including the following link in my xdoc which contains an . a href=http://www.sys-con.com/story/?DE=1storyid=37795; I get an exception when I execute xdoc:transform which says: The reference to entity storyid must end with the ';' delimiter. If I change the link to have amp; instead, the link does not work. Does anyone know how xdoc can include multiple parameters in an href attribute? Thanks. Karl - Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven - Confluence integration
Jason van Zyl wrote: So I started yanking out confluence docs and converting them to apt: http://www.xmlmind.com/aptconvert.html After realizing the internal format of confluence is crap I just started using apt itself which I think is a better format anyway (I was convinced by Pete Kazmier) but I still have my confluence to apt stuff. Nice! Does it use the RPC interface (can't remember if it's XMLRPC or SOAP) to pull all the stuff, or do you need to do a manual export and then it processes the dowloaded xml files? I've got lots of stuff if you want to look at it. Does it have a form of maven plugin? Or anything that could be easily adapted as such? If so, what about importint it into the plugins sandbox? I could look at it later this week. We already have full apt - xdoc, to go the other way probably wouldn't be hard at all to create an initial import. Should be even easier than the other way. Since xdocs are xml there are plenty of options ranging from xslt or vsl (not used in maven AFAICT) to jsl and java class traversing dom4j or plain dom documents. But ultimately I think I'm going to make something that uses the apt format and by pass confluence, it's format and radeox all together. Regexes are proving not to cut the mustard. I think the apt format would make an idea wiki and blog format but I'm all for using confluence for now. Pete Kazmier started the work and I finished the job of getting apt's license changed from LGPL to the MIT license. It would probably take someone a week to whip off a simple webapp to edit apt documents online which would be very cool. I don't think I would swithch from Confluence to a webapp that some one whipped off in a week any time soon :-D But sure, diversity is good. I don't know about Confluence internals, but maybe in the future the Atlassian guys will give an option to choose the rendering engine at the time of deployment. This way people could use Radeox, or APT, or their favourite toy rendering library if they care enough to wrap it and toss it into the webapp. Rafal PS. I'm tracking the m2 progress, and I'm really happy with what I'm seeing! I wish I could take a part in that... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
--- Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 25 May 2004 15:40, Ian Neruda wrote: Hi! I try to connect to cvs respository using scm|cvs|ntserver|username|[EMAIL PROTECTED]|d:\cvs_repository\dir1|moduleName seven characters. I have never heard of ntserver as an CVS protocol. Sure you don't mean pserver? I found this at: http://maven.apache.org/reference/project-descriptor.html - Some cvs clients support other protocols, such as ntserver and extssh. Here's an example using CVS NT and ntserver: scm|cvs|ntserver|[EMAIL PROTECTED]|e:\cvs|Deployment Note the use of the vertical bar as delimiter as the repository has a colon (:) in it. - Before that I tried with pserver, but I get the same mistake. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
On Tuesday 25 May 2004 15:58, Ian Neruda wrote: scm|cvs|ntserver|[EMAIL PROTECTED]|e:\cvs|Deployment Note the use of the vertical bar as delimiter as the repository has a colon (:) in it. - Before that I tried with pserver, but I get the same mistake. The complaint comes from the fact that there are two many 'groups' (separated by '|' ). I think your problem would then be the password part. I don't know if passwords are supported in the connect string or not, but if they are it is probably a different delimiting character. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
On Tuesday 25 May 2004 15:40, Ian Neruda wrote: Hi! I try to connect to cvs respository using scm|cvs|ntserver|username|[EMAIL PROTECTED]|d:\cvs_repository\dir1|moduleName seven characters. I have never heard of ntserver as an CVS protocol. Sure you don't mean pserver? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS connection string
Hi! I try to connect to cvs respository using scm|cvs|ntserver|username|[EMAIL PROTECTED]|d:\cvs_repository\dir1|moduleName but I get the following error: java.lang.IllegalArgumentException: repository connection string contains more than six tokens Am I using wrong connection string? I'm using Maven1.0-rc3. Any help appreciated, Ian __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories
Hi Arnaud, Thanks for doing this. I had a look at the patch (version 1.40 from CVS), and I have a couple questions. To my reading, your patch uses a maven.compile.src.set property to track which directories should be traversed when generating javadocs. However, I believe maven.compile.src.set is used in other plugins as a path refid, and the property and path refid name spaces seem to be distinct: I can change the value of the maven.compile.src.set path without changing the value of the maven.compile.src.set property. I think it would be a good idea to have the maven.compile.src.set self-adjusting: any time a goal is run that generates code someplace other than src/java, then that goal should add that directory to maven.compile.src.set. That way any subsequent goal that needs to operate on all code (generated or otherwise) can just iterate across the directories in maven.compile.src.set. I believe this technique is already being used in the antlr and castor plugins: both of these plugins add directories to the maven.compile.src.set path refid. In my original patch, I had created a maven.javadoc.src.set property based on the maven.compile.src.set path refid, and used that to generate the javadoc filesets: this way it would pick up any additional directories that other goals had added. I believe your patch does things a bit differently. In your patch, the user is expected to set a maven.compile.src.set property with all the directories that the javadoc plugin should traverse to generate the docs. (Sorry if my shallow maven knowledge has led me to misunderstand this.) I don't think using a maven.compile.src.set property value (as it is in your patch) provides the same benefits as the maven.compile.src.set path refid. Users are bound to miss something if we make them add all the appropriate paths to the project.properties file: it may not be obvious to the user which directory is holding the generated code, and the directory may change from release to release of the plugin. It would be possible to work around this problem by expecting plugins to append paths to the maven.compile.src.set property, but this would just duplicate existing functionality (as mentioned, antlr and castor are already appending paths to the path refid), and holding multiple paths is really what path refids were intended for, I think, since they take care of figuring out the path separator and so on. Is there some value to using the maven.compile.src.set property rather than the path refid? Denis On Mon, 2004-05-24 at 01:18, Arnaud Heritier wrote: It's done. I wrote a test case for maven.compile.src.set. It works only if maven.compile.src.set is manually setted in the project.properties. In CVS I commented tests for this. Arnaud. -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 23 mai 2004 23:23 À : Maven Users List Objet : Re: javadoc on generated source directories How about coding a failing (at the moment) plugin test case that can be run on demand? On Sat, 22 May 2004 19:59:07 +0200, Arnaud Heritier [EMAIL PROTECTED] wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deploy:pom plugin
I'm looking for some information on the deploy:pom plugin. In looking through the jelly script I noticed an artifact tag, but being new to Maven, it's not explicitly clear to me what properties, or tags I need in my project for the deployment of an artifact to be successful. Can anyone provide some advice on how to get started with this plugin? Currently, I'm just evaluating the functionality available to understand if Maven can solve the problem of deploying a set of applications to a variety of target machines. (I'm looking to automate the generation of the project.xml, maven.xml, and project.properties with a web-interface, so that users can input some basic application information, which invokes maven plugins that extract the SCM source, build the app, then deploy it to one of the many target environments). Regards, Ryan
RE: Classpath Problem
Yes, but i don't think this is the problem.
MY first test was to have an ant script that worked perfectly with all the dependancy
in a lib directory, then I updated the script to use maven but i kept the libs local
not in the repository and it startet having problem
I think this could be related to an xml parser, since in the ant execution it gives me
a warning about jaxp not able to invoce SAX, swtiching now to aelfred that under maven
is not printed
Max
-Original Message-
From: Dion Gillard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 1:07 AM
To: Maven Users List
Subject: Re: Classpath Problem
Does it require tools.jar from the JDK on the classpath?
On Mon, 24 May 2004 16:51:12 +0200, Amato Massimiliano (TLAB)
[EMAIL PROTECTED] wrote:
Hello,
I am trying to write a plugin for workzen. I built an ant script that works
perfectly but when i tried to convert it into a plugin it failed.
It looks like it is a classpath problem but i don't know exactly what to do..
Here's the output of my execution and the plugin.jelly file
?xml version=1.0?
project
xmlns:j=jelly:core
xmlns:jelxml=jelly:xml
xmlns:jelant=jelly:ant
xmlns:maven=jelly:maven
xmlns:m=maven
goal name=test description=Generate Delegator Classes
path id=classpath
path refid=maven.dependency.classpath/
pathelement path=${plugin.getDependencyPath('dom4j')}/
pathelement path=${plugin.getDependencyPath('log4j')}/
pathelement path=${plugin.getDependencyPath('workzen+xit')}/
pathelement path=${plugin.getDependencyPath('workzen+common')}/
/path
taskdef name=xml2bean classname=workzen.xit.ant.Xml2BeanTask
classpath
pathelement
path=${plugin.getDependencyPath('workzen+xit')}/
/classpath
/taskdef
mkdir dir=./work/fred/output1/
xml2bean
Template = /${basedir}/src/conf/pojo/control.vm
InputUrl= /${basedir}/src/conf/pojo/bean.xml
OutputDir = ./work/fred/output1
classpath refid=classpath/
/xml2bean
/goal
/project
And here's the output
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT
0 [main] INFO workzen.xit.Engine - input connector:
workzen.xit.module.xml2bean.connector.Xml2BeanConnector
0 [main] INFO workzen.xit.connector.XmlConnector - input url:
/D:/Projects/Misc/Generator/src/conf/pojo/bean.xml
16 [main] INFO workzen.xit.connector.XmlConnector - output url: null
328 [main] DEBUG workzen.xit.module.xml2bean.util.XmlLoader -
package:com.workzen.xit.module.xml2bean.test
344 [main] DEBUG workzen.xit.module.xml2bean.util.XmlLoader - bean name:TypeBean
359 [main] DEBUG workzen.xit.module.xml2bean.util.XmlLoader - fit size: 15
359 [main] DEBUG workzen.xit.module.xml2bean.util.XmlLoader - field name:pKey
359 [main] DEBUG workzen.xit.module.xml2bean.util.XmlLoader - isprimary:true
testa:
[xml2bean] [ERROR] java.lang.NoClassDefFoundError:
sun/reflect/ConstructorAccessorImpl
BUILD SUCCESSFUL
Total time: 6 seconds
Finished at: Mon May 24 16:43:17 CEST 2004
Any help would be great
Max
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
scm|cvs|ntserver|[EMAIL PROTECTED]|e:\cvs|Deployment Note the use of the vertical bar as delimiter as the repository has a colon (:) in it. - Before that I tried with pserver, but I get the same mistake. The complaint comes from the fact that there are two many 'groups' (separated by '|' ). I think your problem would then be the password part. I don't know if passwords are supported in the connect string or not, but if they are it is probably a different delimiting character. Cheers Niclas I tried with scm|cvs|pserver|username:[EMAIL PROTECTED]|d:\cvs_repository\dir1|moduleName and I get another error: java.io.IOException: CreateProcess: cvs -d:pserver:razvoj:[EMAIL PROTECTED]:d:\cvs _repository\razvoj -q checkout -P SedamIT error=2 com.werken.werkz.UnattainableGoalException: Unable to obtain goal [scm:checkout-project] -- E:\unzip\Maven1.0-rc3\.maven\plugins\maven-scm-plugin-1.3\plugin.jelly:227:9: ant:cvs java.io.IOException: CreateProcess: cvs -d:pserver:username:[EMAIL PROTECTED]:d:\cvs_repository\dir1 -q checkout -P moduleName error=2 I executed generated command from command prompt and it works. Command is: cvs -d:pserver:username:[EMAIL PROTECTED]:d:\cvs_repository\dir1 -q checkout -P moduleName I read panegyrics about Maven, and believed them just to have trobule with simple things like reading data from cvs. I've done this with ant five minutes after extracting its archive. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc on generated source directories - valid point!
Denis McLaughlin wrote: I don't think using a maven.compile.src.set property value (as it is in your patch) provides the same benefits as the maven.compile.src.set path refid. Users are bound to miss something if we make them add all the appropriate paths to the project.properties file: it may not be obvious to the user which directory is holding the generated code, and the directory may change from release to release of the plugin. It would be possible to work around this problem by expecting plugins to append paths to the maven.compile.src.set property, but this would just duplicate existing functionality (as mentioned, antlr and castor are already appending paths to the path refid), and holding multiple paths is really what path refids were intended for, I think, since they take care of figuring out the path separator and so on. Is there some value to using the maven.compile.src.set property rather than the path refid? I totally agree. Path sets seem superior in this regard to text properties. Maven even contains some jelly tags to help with path set manipulation if my memory servers me. Is there any reason for using text properties? If not, how hard would it be to change Arnaud's recent contribution to user path sets instead? Rafal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS connection string
You mustn't give your password scm|cvs|ntserver|[EMAIL PROTECTED]|d:\cvs_repository\dir1|module you must be logged and your password must be stored in your .cvspass file http://maven.apache.org/reference/plugins/changelog/ Arnaud -Message d'origine- De : Ian Neruda [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 09:40 À : [EMAIL PROTECTED] Objet : CVS connection string Hi! I try to connect to cvs respository using scm|cvs|ntserver|username|[EMAIL PROTECTED]|d:\cvs_repository\dir1 |moduleName but I get the following error: java.lang.IllegalArgumentException: repository connection string contains more than six tokens Am I using wrong connection string? I'm using Maven1.0-rc3. Any help appreciated, Ian __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - 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: Réf. : in href in xdoc
Heritier Arnaud wrote: yes I think that your problem is the one defined in MPXDOC-92. Has there been any progres on this bug? It has large impact, because all the viewcvs links generated by the changes statcvs plugins turn to garbage. Linkcheck gives me some 1mB error report :-) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS connection string
You mustn't give your password scm|cvs|ntserver|[EMAIL PROTECTED]|d:\cvs_repository\dir1|module you must be logged and your password must be stored in your .cvspass file http://maven.apache.org/reference/plugins/changelog/ Arnaud Thank you for your help. I generated .cvspass file using: maven -Dpassword=YYY changelog:create-cvspass Maven placed it in user.home. Now when I try to connect to cvs I get another error. It seems that cvs client uses empty password. I found similar problem on mailing list, but I haven't found a solution. [cvs] Using cvs passfile: E:\unzip\Maven1.0-rc3\.cvspass [cvs] cvs checkout: Empty password used - try 'cvs login' with a real password [cvs] [cvs] cvs [checkout aborted]: authorization failed: server host rejected access to d:/cvs_repository/dir1 for user username BUILD FAILED File.. E:\unzip\Maven1.0-rc3\.maven\plugins\maven-scm-plugin-1.3\plugin.jelly Element... ant:cvs Line.. 227 Column 9 cvs exited with error code 1 Command line was [Executing 'cvs' with arguments: '-d:pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir' '-q' 'checkout' '-P' 'ModuleName' The ' characters around the executable and arguments are not part of the command. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xdoc problem, char in href attribute
I am trying including the following link in my xdoc which contains an . a href=http://www.sys-con.com/story/?DE=1storyid=37795; I get an exception when I execute xdoc:transform which says: The reference to entity storyid must end with the ';' delimiter. If I change the link to have amp; instead, the link does not work. Does anyone know how xdoc can include multiple parameters in an href attribute? Thanks. Karl - Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger
Re: xdoc problem, char in href attribute
Hello, Karl! You wrote to Maven Users List [EMAIL PROTECTED] on Tue, 25 May 2004 04:28:41 -0700 (PDT): KB I am trying including the following link in my xdoc which contains KB an . KB a href=http://www.sys-con.com/story/?DE=1storyid=37795; KB I get an exception when I execute xdoc:transform which says: KB The reference to entity storyid must end with the ';' delimiter. KB If I change the link to have amp; instead, the link does not KB work. Does anyone know how xdoc can include multiple parameters in KB an href attribute? KB Thanks. KB Karl Hi! Try to change amp; to #38; With best regards, Eugene Kirin. E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best practice for webapp development in WSAD/Eclipse
All, I was after some feedback on how people structured their WEB (war) applications when using WSAD/Eclipse and maven for development. My directory is structured as follows: /WebProject /src /java /test /java /WebContent /WEB-INF /classes /lib /target (maven generated) As with jar projects, I defined all dependencies in the pom and these are reflected in the .classpath file A simple example: ?xml version=1.0 encoding=UTF-8? classpath classpathentry kind=src path=src/java/ classpathentry kind=src path=src/test/java/ classpathentry kind=var path=SERVERJDK_50_PLUGINDIR/jre/lib/rt.jar sourcepath=SERVERJDK_50_PLUGINDIR/src.jar/ classpathentry kind=var path=MAVEN_REPO/j2ee/jars/j2ee-1.3.jar/ classpathentry kind=var path=MAVEN_REPO/junit/jars/junit-3.8.1.jar/ classpathentry kind=var path=MAVEN_REPO/log4j/jars/log4j-1.2.8.jar/ classpathentry kind=output path=WebContent/WEB-INF/classes/ /classpath This compiles fine. The classes are written to my WebContent/WEB-INF/classes directory. BUT - If I run this application using a WebSphere Test Environment (WTE) server, it will fail because it can't find the log4j classes. The WTE uses the WebContent directory as an exploded war. WTE expects utility jars to be available to the WAS classloader, usually from the WEB-INF/lib directory. If I put the jars in the lib directory, I'm effectively maintaining the dependencies twice (in the pom and in WEB-INF/lib). Of course, when building using maven, the exploded war is created in /target, including dependency jars added to /WEB-INF/lib. That all works fine, especially on a continuous integration server. If I could get WSAD to use the /target/webapp directory in the WTE, that would solve the problem, but I can't. Therefore, using maven in a development environment seems to require deploy the generated ear for each test iteration. This loses much of the power of the WTE. So what do other people do? I've extended war:war to add dependencies defined in the pom to the WebContent/WEB-INF/lib directory. But this requires maven war:war to be run before using WTE for the first time. That doesn't feel right. The whole thing doesn't seem to fit well for war projects (great for jars). I'm still experimenting but I thought I'd ask for help!!! I hope this makes sense :-) Al. Digital Union UK [EMAIL PROTECTED] www.digitalunion.com t: +44 (0) 1483 889482 m:+44 (0) 7713 631367 f: +44 (0) 1483 889450 The information in this email and in any attachment(s) is confidential. If you are not the named addressee(s) or if you receive this email in error then any distribution, copying or use of this communication or the information in it is strictly prohibited. While attachments are virus checked, Digital Union UK Limited does not accept any liability in respect of any virus which is not detected. div style=width:450px; border-top: 1px solid black; border-bottom: 1px solid black; font-family: Arial; font-size: 8pt pThis email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.nbsp; If you have received this email in error please notify your system administrator. br/br/While attachments are virus checked, Digital Union UK Limited does not accept any liability in respect of any virus which is not detected./p /div
RE: javadoc on generated source directories
Hello Denis, There's no value added and it was an error of me. Why ? 1 - Because I didn't understand the interest to use the reference rather than the property 2 - Because I didn't succeed to create a test case with maven:addPath and I thought that it can be due to the refid. I will send you a corrected release of the plugin (I can't commit at work). Can you see if it works for you ? Arnaud -Message d'origine- De : Denis McLaughlin [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 05:54 À : Maven Users List Objet : RE: javadoc on generated source directories Hi Arnaud, Thanks for doing this. I had a look at the patch (version 1.40 from CVS), and I have a couple questions. To my reading, your patch uses a maven.compile.src.set property to track which directories should be traversed when generating javadocs. However, I believe maven.compile.src.set is used in other plugins as a path refid, and the property and path refid name spaces seem to be distinct: I can change the value of the maven.compile.src.set path without changing the value of the maven.compile.src.set property. I think it would be a good idea to have the maven.compile.src.set self-adjusting: any time a goal is run that generates code someplace other than src/java, then that goal should add that directory to maven.compile.src.set. That way any subsequent goal that needs to operate on all code (generated or otherwise) can just iterate across the directories in maven.compile.src.set. I believe this technique is already being used in the antlr and castor plugins: both of these plugins add directories to the maven.compile.src.set path refid. In my original patch, I had created a maven.javadoc.src.set property based on the maven.compile.src.set path refid, and used that to generate the javadoc filesets: this way it would pick up any additional directories that other goals had added. I believe your patch does things a bit differently. In your patch, the user is expected to set a maven.compile.src.set property with all the directories that the javadoc plugin should traverse to generate the docs. (Sorry if my shallow maven knowledge has led me to misunderstand this.) I don't think using a maven.compile.src.set property value (as it is in your patch) provides the same benefits as the maven.compile.src.set path refid. Users are bound to miss something if we make them add all the appropriate paths to the project.properties file: it may not be obvious to the user which directory is holding the generated code, and the directory may change from release to release of the plugin. It would be possible to work around this problem by expecting plugins to append paths to the maven.compile.src.set property, but this would just duplicate existing functionality (as mentioned, antlr and castor are already appending paths to the path refid), and holding multiple paths is really what path refids were intended for, I think, since they take care of figuring out the path separator and so on. Is there some value to using the maven.compile.src.set property rather than the path refid? Denis On Mon, 2004-05-24 at 01:18, Arnaud Heritier wrote: It's done. I wrote a test case for maven.compile.src.set. It works only if maven.compile.src.set is manually setted in the project.properties. In CVS I commented tests for this. Arnaud. -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 23 mai 2004 23:23 À : Maven Users List Objet : Re: javadoc on generated source directories How about coding a failing (at the moment) plugin test case that can be run on demand? On Sat, 22 May 2004 19:59:07 +0200, Arnaud Heritier [EMAIL PROTECTED] wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud - 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] - 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: javadoc on generated source directories - valid point!
No reason, only a lack of understanding. If we come to an agreement with Denis, you and others, the change will be done tonight (in france). Arnaud. -Message d'origine- De : Rafal Krzewski [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 11:05 À : Maven Users List Objet : Re: javadoc on generated source directories - valid point! Denis McLaughlin wrote: I don't think using a maven.compile.src.set property value (as it is in your patch) provides the same benefits as the maven.compile.src.set path refid. Users are bound to miss something if we make them add all the appropriate paths to the project.properties file: it may not be obvious to the user which directory is holding the generated code, and the directory may change from release to release of the plugin. It would be possible to work around this problem by expecting plugins to append paths to the maven.compile.src.set property, but this would just duplicate existing functionality (as mentioned, antlr and castor are already appending paths to the path refid), and holding multiple paths is really what path refids were intended for, I think, since they take care of figuring out the path separator and so on. Is there some value to using the maven.compile.src.set property rather than the path refid? I totally agree. Path sets seem superior in this regard to text properties. Maven even contains some jelly tags to help with path set manipulation if my memory servers me. Is there any reason for using text properties? If not, how hard would it be to change Arnaud's recent contribution to user path sets instead? Rafal. - 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: Réf. : in href in xdoc
No i'm sorry but I didn't find the time to work on it. I put it on the top of my tasks list. Dion began to work on a dom4j upgrade in Jelly but I'm not sure that it will resolve this problem. Arnaud. -Message d'origine- De : Rafal Krzewski [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 11:53 À : Maven Users List Objet : Re: Réf. : in href in xdoc Heritier Arnaud wrote: yes I think that your problem is the one defined in MPXDOC-92. Has there been any progres on this bug? It has large impact, because all the viewcvs links generated by the changes statcvs plugins turn to garbage. Linkcheck gives me some 1mB error report :-) R. - 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: CVS connection string
you must be logged. before to launch maven : cvs -D :pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir login Arnaud -Message d'origine- De : Ian Neruda [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 13:18 À : Maven Users List Objet : RE: CVS connection string You mustn't give your password scm|cvs|ntserver|[EMAIL PROTECTED]|d:\cvs_repository\dir1|module you must be logged and your password must be stored in your .cvspass file http://maven.apache.org/reference/plugins/changelog/ Arnaud Thank you for your help. I generated .cvspass file using: maven -Dpassword=YYY changelog:create-cvspass Maven placed it in user.home. Now when I try to connect to cvs I get another error. It seems that cvs client uses empty password. I found similar problem on mailing list, but I haven't found a solution. [cvs] Using cvs passfile: E:\unzip\Maven1.0-rc3\.cvspass [cvs] cvs checkout: Empty password used - try 'cvs login' with a real password [cvs] [cvs] cvs [checkout aborted]: authorization failed: server host rejected access to d:/cvs_repository/dir1 for user username BUILD FAILED File.. E:\unzip\Maven1.0-rc3\.maven\plugins\maven-scm-plugin-1.3\plugin.jelly Element... ant:cvs Line.. 227 Column 9 cvs exited with error code 1 Command line was [Executing 'cvs' with arguments: '-d:pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir' '-q' 'checkout' '-P' 'ModuleName' The ' characters around the executable and arguments are not part of the command. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - 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: xdoc problem, char in href attribute
We talk about this in the ML a few hours ago. subject : in href in xdoc Sorry but it's a known bug : MPXDOC-92 Vote for it !!! Arnaud -Message d'origine- De : Karl Baum [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 13:29 À : Maven Users List Objet : xdoc problem, char in href attribute I am trying including the following link in my xdoc which contains an . a href=http://www.sys-con.com/story/?DE=1storyid=37795; I get an exception when I execute xdoc:transform which says: The reference to entity storyid must end with the ';' delimiter. If I change the link to have amp; instead, the link does not work. Does anyone know how xdoc can include multiple parameters in an href attribute? Thanks. Karl - Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven - Confluence integration
On Tue, 2004-05-25 at 03:30, Rafal Krzewski wrote: Jason van Zyl wrote: PS. I'm tracking the m2 progress, and I'm really happy with what I'm seeing! I wish I could take a part in that... It is clipping along at a rapid pace, if you want to try and build with it we can arrange something. Before the alpha is released I'll probably ask various folks to do some pre-alpha testing. There are about 14 plugins so far that are being used for testing, but the core will do the trick as far as building jars. Just let me know and I'll throw you the password for the bundles created by the CI process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven - Confluence integration
Jason van Zyl wrote: It is clipping along at a rapid pace, if you want to try and build with it we can arrange something. Before the alpha is released I'll probably ask various folks to do some pre-alpha testing. There are about 14 plugins so far that are being used for testing, but the core will do the trick as far as building jars. Just let me know and I'll throw you the password for the bundles created by the CI process. Too busy ATM :-(. But when you are in the pre alpha testing phase, I'm willing to participate. Put me on the list. Rafal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS connection string
--- Heritier Arnaud [EMAIL PROTECTED] wrote: you must be logged. before to launch maven : cvs -D :pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir login Arnaud, thank you very much. I had to set cvsroot first and execute login after that. set cvsroot=:pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir cvs login Ian __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
I am not sure if anyone else is having this problem I am trying to use the maven-latka plugin and using the Jmeter Convert functionality and it doesn't bring over any of the parameter values. So the newly created latka suite does not run. I would then need to add all the parameters to the latka suite file. Is anyone else having this problem or have a solution? I am using Maven-Latka-Plugin-1.4 . Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unit Test naming conventions test:test
Is the POM the only place where unit test names are referred to... So if I have this... unitTest resources resource directorysrc/test/directory includes include**/*.properties/include include**/*.xml/include include**/*.xsd/include /includes /resource /resources includes include**/Test*.java/include include**/*Bug.*/include /includes /unitTest ...then logically my Unit Tests should be prefixed with 'Test'. The problem is they're not being picked up when I run test:test. I have another project where the above naming convention does work and I can't see where else the filenames are referred to. I'm sure it's obvious...but anyone know? Thanks. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.688 / Virus Database: 449 - Release Date: 18/05/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SNAPSHOT and multiproject
Hi,
I have two question, first, how can I make this code working (in a maven.xml) :
ant:echo${pom.currentVersion}/ant:echo
j:set var=pom.currentVersionSNAPSHOT/j:set
ant:echo${pom.currentVersion}/ant:echo
Display is :
[echo] 3.0.0
[echo] 3.0.0
But I want
[echo] 3.0.0
[echo] SNAPSHOT
Second question, I have a multiproject versionned as 3.0.0, this is a J2EE
project (client, ear, service, web...). my client depend on service project :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
When I build a snapshot (using *:install-snapshot goals), Maven use 3.0.0 for
the dependency version (version${pom.currentVersion}/version), I want maven
replace 3.0.0 per SNAPSHOT. Is there a way to do this without using the
workaround on first question.
May I am clear ?
Thx,
-emmanuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SNAPSHOT and multiproject
SNAPSHOT have nothing in common whith pom.currentVersion.
If you want you can have a 3.0.0-SNAPSHOT version, the artifact with this
version will be considere as SNAPSHOT version too.
Nicolas,
[EMAIL PROTECTED]
25/05/2004 16:34
Veuillez répondre à Maven Users List
Pour : [EMAIL PROTECTED]
cc :
Objet : SNAPSHOT and multiproject
Hi,
I have two question, first, how can I make this code working (in a
maven.xml) :
ant:echo${pom.currentVersion}/ant:echo
j:set var=pom.currentVersionSNAPSHOT/j:set
ant:echo${pom.currentVersion}/ant:echo
Display is :
[echo] 3.0.0
[echo] 3.0.0
But I want
[echo] 3.0.0
[echo] SNAPSHOT
Second question, I have a multiproject versionned as 3.0.0, this is a J2EE
project (client, ear, service, web...). my client depend on service
project :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
When I build a snapshot (using *:install-snapshot goals), Maven use 3.0.0
for
the dependency version (version${pom.currentVersion}/version), I want
maven
replace 3.0.0 per SNAPSHOT. Is there a way to do this without using the
workaround on first question.
May I am clear ?
Thx,
-emmanuel
-
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]
maven-changelog-plugin:report : org.netbeans.lib.cvsclient.connection.AuthenticationException: Wrong Password.
I've found quite a few postings on the WEB for this problem, but am a bit confused as to whether or not it is fix. I do not an anonymous CVS account, so must use password authentication. I have already logged in and checked that the .cvsfile exists with the correct CVSROOT details and scrambled password. But still get this problem. From some of the postings on the WEB it looks like I can put a password into my Repository connection, but there is a bit of confusion on the format. Is the best way out of this to just allow anon access to CVS. I'm running RC3 on Linux. Thanks Pat maven-changelog-plugin:report: [echo] Generating the changelog report Didn't find password for CVSROOT ':pserver:[EMAIL PROTECTED]:/repos '. org.netbeans.lib.cvsclient.connection.AuthenticationException: Wrong Password. ChangeLog found: 0 entries BUILD SUCCESSFUL Total time: 7 seconds Finished at: Tue May 25 15:13:44 BST 2004
RE: SNAPSHOT and multiproject
Nicolas,
I know what you said and, for some reasons, we don't want to put some
X.X.X-SNAPSHOT version, only X.X.X
So, in our master projects we set the pom.currentVersion at 3.0.0. All
subprojects use this version number.
In all our subprojects, we use ${pom.currentVersion} to references thems :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
The version used by pom.currentVersion is logicaly 3.0.0 but when I build a
snapshot, logicaly maven should replace 3.0.0 by SNAPSHOT (or a timestamp)
If project 2 depend on Project 2, result is :
Project 1 : Maven build and install the murexservice-SNAPSHOT.jar
Project 2 : Maven try to download murexservice-3.0.0.jar, Fail because there is
no murexservice-3.0.0.jar on repo, only the murexservice-SNAPSHOT.jar
BTW: That is for this reason I want to override the pom.currentVersion at bootstrap
Thx,
-emmanuel
Selon [EMAIL PROTECTED]:
SNAPSHOT have nothing in common whith pom.currentVersion.
If you want you can have a 3.0.0-SNAPSHOT version, the artifact with this
version will be considere as SNAPSHOT version too.
Nicolas,
[EMAIL PROTECTED]
25/05/2004 16:34
Veuillez répondre à Maven Users List
Pour : [EMAIL PROTECTED]
cc :
Objet : SNAPSHOT and multiproject
Hi,
I have two question, first, how can I make this code working (in a
maven.xml) :
ant:echo${pom.currentVersion}/ant:echo
j:set var=pom.currentVersionSNAPSHOT/j:set
ant:echo${pom.currentVersion}/ant:echo
Display is :
[echo] 3.0.0
[echo] 3.0.0
But I want
[echo] 3.0.0
[echo] SNAPSHOT
Second question, I have a multiproject versionned as 3.0.0, this is a J2EE
project (client, ear, service, web...). my client depend on service
project :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
When I build a snapshot (using *:install-snapshot goals), Maven use 3.0.0
for
the dependency version (version${pom.currentVersion}/version), I want
maven
replace 3.0.0 per SNAPSHOT. Is there a way to do this without using the
workaround on first question.
May I am clear ?
Thx,
-emmanuel
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SNAPSHOT and multiproject
Nicolas,
I know what you said and, for some reasons, we don't want to put some
X.X.X-SNAPSHOT version, only X.X.X
So, in our master projects we set the pom.currentVersion at 3.0.0. All
subprojects use this version number.
In all our subprojects, we use ${pom.currentVersion} to references thems :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
The version used by pom.currentVersion is logicaly 3.0.0 but when I build a
snapshot, logicaly maven should replace 3.0.0 by SNAPSHOT (or a timestamp)
If project 2 depend on Project 2, result is :
Project 1 : Maven build and install the murexservice-SNAPSHOT.jar
Project 2 : Maven try to download murexservice-3.0.0.jar, Fail because there is
no murexservice-3.0.0.jar on repo, only the murexservice-SNAPSHOT.jar
BTW: That is for this reason I want to override the pom.currentVersion at bootstrap
Thx,
-emmanuel
Selon [EMAIL PROTECTED]:
SNAPSHOT have nothing in common whith pom.currentVersion.
If you want you can have a 3.0.0-SNAPSHOT version, the artifact with this
version will be considere as SNAPSHOT version too.
Nicolas,
[EMAIL PROTECTED]
25/05/2004 16:34
Veuillez répondre à Maven Users List
Pour : [EMAIL PROTECTED]
cc :
Objet : SNAPSHOT and multiproject
Hi,
I have two question, first, how can I make this code working (in a
maven.xml) :
ant:echo${pom.currentVersion}/ant:echo
j:set var=pom.currentVersionSNAPSHOT/j:set
ant:echo${pom.currentVersion}/ant:echo
Display is :
[echo] 3.0.0
[echo] 3.0.0
But I want
[echo] 3.0.0
[echo] SNAPSHOT
Second question, I have a multiproject versionned as 3.0.0, this is a J2EE
project (client, ear, service, web...). my client depend on service
project :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
When I build a snapshot (using *:install-snapshot goals), Maven use 3.0.0
for
the dependency version (version${pom.currentVersion}/version), I want
maven
replace 3.0.0 per SNAPSHOT. Is there a way to do this without using the
workaround on first question.
May I am clear ?
Thx,
-emmanuel
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
XDOC URLs and
I have some links in my xdocs that require two parameters. If I just use in the url the build fails. If I use amp; that's what I get in the URL and the URL doesn't work. What am I doing wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven XDoclet plug-in examples?
I wrote the wiki example for EJB generation using maven
(http://wiki.codehaus.org/maven/CreatingEjbApplications) and have used the ant task to
execute xdoclet with much success. my example can be used to generate as many ejbs as
you'd like without creating more projects. Let me know if you have questions or
comments. I'd be glad to help out, since i've been through this integration
frustration.
Ryan
-Original Message-
From: Mark Slater [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 6:36 PM
To: [EMAIL PROTECTED]
Subject: Maven XDoclet plug-in examples?
I'm a little disappointed by the quality of the Maven/XDoclet
integration
documentation out there. There seem to be a lot of good
starts, but nothing in
the way of a complete solution. I've found the three Wiki
pages, Maven Magic,
and a few other pages, and most of them make it look easy
enough, but when I
try to duplicate their successes, it doesn't work so well for me.
I'm using Maven 1.0rc2 (moving to rc3, but I'm not sure it's
going to make a
difference in this), and XDoclet 1.2.1. While I can get a
maven.xml script to
invoke XDoclet like an Ant task, it doesn't seem to do all
the steps the
tutorials expect it to (generating the application.xml file,
for example). So
I tried to use the maven-xdoclet-plugin, and I get the
following message:
[echo] Running ejb:install for Testing EJB Module
Tag library requested that is not present: 'maven' in plugin:
'maven-xdoclet-
plugin-1.2.1'
I found some discussions that suggested this was a namespace
problem, but
changing the namespaces in the plugin.jelly didn't help. All
I know is that
I'm not getting any generated code.
And finally, the build fails with this message:
xdoclet:ejbdoclet:
[echo] Compiling to {my_path}/root/../TestingEjb/target/classes
BUILD FAILED
File..
{my_home}/.maven/plugins/maven-multiproject-plugin-1.3/plugin.jelly
Element... maven:reactor
Line.. 216
Column 9
Unable to obtain goal [multiproject:install-callback] --
{my_home}/.maven/
plugins/maven-java-plugin-1.4/plugin.jelly:53:48: ant:javac srcdir
{my_path}/TestingEjb/target/xdoclet/ejbdoclet does not exist!
Now, I've seen some people suggest that the XDoclet plugin
is... lacking (in
terms of documentation, I'd certainly agree). Perhaps I
shouldn't be using it
and should stick to the ant task style of running XDoclet?
Are there any
projects that I can examine where maven is building a bunch
of EJBs for
deployment on JBoss? I got the J2EE sample project off the
Wiki, but that
seems to require an EJB client project for each bean, and I
don't see a good
reason for it.
Perhaps I'm posting to the wrong group and need to talk on
the XDoclet user's
list?
Any help would be appreciated!
Thanks,
Mark
-
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]
subversion repo connection string: (again I know)
There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Réf. : XDOC URLs and
hello is it the http://jira.codehaus.org/browse/MPXDOC-92 ?? if yes you are the third person today to ask about it Julien Extranet [EMAIL PROTECTED] - 25/05/2004 17:56 Veuillez répondre à [EMAIL PROTECTED] Pour : users cc : Objet : XDOC URLs and I have some links in my xdocs that require two parameters. If I just use in the url the build fails. If I use amp; that's what I get in the URL and the URL doesn't work. What am I doing wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: subversion repo connection string: (again I know)
Do you have setup the maven.changelog.factory property? - Original Message - From: Omair-Inam Abdul-Matin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:09 PM Subject: subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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: Maven XDoclet plug-in examples?
I disagree. Scan the mailing lists to see how many problems people have getting the
maven-xdoclet plugin up and running. In any non-trivial setup, it's much more
efficient to use the ant task. the maven-xdoclet plugin is just plain clucky and the
documentation is sub par. even trying to modify the plugin is impossible since it
contains literally thousands of lines of plugin.jelly code to weed through.
no thanks, I'll stick to my 100+ line maven.xml which is perfectly clear.
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 11:17 AM
To: Maven Users List
Subject: Re: Maven XDoclet plug-in examples?
Why you don't use the xdoclet plugin?
It simplify the maven.xml
Emmanuel
- Original Message -
From: Ryan Sonnek [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 5:57 PM
Subject: RE: Maven XDoclet plug-in examples?
I wrote the wiki example for EJB generation using maven
(http://wiki.codehaus.org/maven/CreatingEjbApplications) and
have used the
ant task to execute xdoclet with much success. my example
can be used to
generate as many ejbs as you'd like without creating more
projects. Let me
know if you have questions or comments. I'd be glad to help
out, since i've
been through this integration frustration.
Ryan
-Original Message-
From: Mark Slater [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 6:36 PM
To: [EMAIL PROTECTED]
Subject: Maven XDoclet plug-in examples?
I'm a little disappointed by the quality of the Maven/XDoclet
integration
documentation out there. There seem to be a lot of good
starts, but nothing in
the way of a complete solution. I've found the three Wiki
pages, Maven Magic,
and a few other pages, and most of them make it look easy
enough, but when I
try to duplicate their successes, it doesn't work so well for me.
I'm using Maven 1.0rc2 (moving to rc3, but I'm not sure it's
going to make a
difference in this), and XDoclet 1.2.1. While I can get a
maven.xml script to
invoke XDoclet like an Ant task, it doesn't seem to do all
the steps the
tutorials expect it to (generating the application.xml file,
for example). So
I tried to use the maven-xdoclet-plugin, and I get the
following message:
[echo] Running ejb:install for Testing EJB Module
Tag library requested that is not present: 'maven' in plugin:
'maven-xdoclet-
plugin-1.2.1'
I found some discussions that suggested this was a namespace
problem, but
changing the namespaces in the plugin.jelly didn't help. All
I know is that
I'm not getting any generated code.
And finally, the build fails with this message:
xdoclet:ejbdoclet:
[echo] Compiling to {my_path}/root/../TestingEjb/target/classes
BUILD FAILED
File..
{my_home}/.maven/plugins/maven-multiproject-plugin-1.3/plugin.jelly
Element... maven:reactor
Line.. 216
Column 9
Unable to obtain goal [multiproject:install-callback] --
{my_home}/.maven/
plugins/maven-java-plugin-1.4/plugin.jelly:53:48: ant:javac srcdir
{my_path}/TestingEjb/target/xdoclet/ejbdoclet does not exist!
Now, I've seen some people suggest that the XDoclet plugin
is... lacking (in
terms of documentation, I'd certainly agree). Perhaps I
shouldn't be using it
and should stick to the ant task style of running XDoclet?
Are there any
projects that I can examine where maven is building a bunch
of EJBs for
deployment on JBoss? I got the J2EE sample project off the
Wiki, but that
seems to require an EJB client project for each bean, and I
don't see a good
reason for it.
Perhaps I'm posting to the wrong group and need to talk on
the XDoclet user's
list?
Any help would be appreciated!
Thanks,
Mark
-
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]
-
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: subversion repo connection string: (again I know)
The relevant snippet from my project.properties file is given below: # --- # # C H A N G E L O G P R O P E R T I E S # # --- maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory Omair Emmanuel Venisse wrote: Do you have setup the maven.changelog.factory property? - Original Message - From: Omair-Inam Abdul-Matin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:09 PM Subject: subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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: subversion repo connection string: (again I know)
didn't the scm:svn:pserver:[pserver [EMAIL PROTECTED]:/path/to/svn:my-project-name/trunk works ? Nicolas, Omair-Inam Abdul-Matin [EMAIL PROTECTED] Envoyé par : news [EMAIL PROTECTED] 25/05/2004 18:09 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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: subversion repo connection string: (again I know)
OK, it's a bug in the Repository class that check only the cvs format. Can you add an issue in Jira? Thanks Emmanuel - Original Message - From: Omair-Inam Abdul-Matin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:18 PM Subject: Re: subversion repo connection string: (again I know) The relevant snippet from my project.properties file is given below: # --- # # C H A N G E L O G P R O P E R T I E S # # --- maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory Omair Emmanuel Venisse wrote: Do you have setup the maven.changelog.factory property? - Original Message - From: Omair-Inam Abdul-Matin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:09 PM Subject: subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: subversion repo connection string: (again I know)
Yes, that change worked. I still get a proper changelog (since it doesn't use the repo string) and the url for repository access (Project Info-Source Repository). Until proper SVN support is added to the SCM plugin I guess this workaround will have to do. Omair [EMAIL PROTECTED] wrote: didn't the scm:svn:pserver:[pserver [EMAIL PROTECTED]:/path/to/svn:my-project-name/trunk works ? Nicolas, Omair-Inam Abdul-Matin [EMAIL PROTECTED] Envoyé par : news [EMAIL PROTECTED] 25/05/2004 18:09 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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: subversion repo connection string: (again I know)
No svn doesn't use cvs connection string style. - Original Message - From: [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:21 PM Subject: RE: subversion repo connection string: (again I know) didn't the scm:svn:pserver:[pserver [EMAIL PROTECTED]:/path/to/svn:my-project-name/trunk works ? Nicolas, Omair-Inam Abdul-Matin [EMAIL PROTECTED] Envoyé par : news [EMAIL PROTECTED] 25/05/2004 18:09 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: subversion repo connection string: (again I know)
Let me clarify. What I meant by worked was that my build process didn't fail... As Emmanuel has correctly pointed out SVN does not use the same format for a connection string as CVS. Quoting the SVN red book: - Repository URLs Subversion repositories can be accessed through many different methodson local disk, or through various network protocols. A repository location, however, is always a URL. Table 2-1 describes how different URL schemas map to the available access methods. Table 2.1. Repository Access URLs Schema Access Method file:///direct repository access (on local disk) http:// access via WebDAV protocol to Subversion-aware Apache server https://same as http://, but with SSL encryption. svn:// access via custom protocol to an svnserve server svn+ssh:// same as svn://, but through an SSH tunnel. For the most part, Subversion's URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL. Remember that the file: access method is valid only for locations on the same server as the clientin fact, in accordance with convention, the server name portion of the URL is required to be either absent or localhost: $ svn checkout file:///path/to/repos $ svn checkout file://localhost/path/to/repos Also, users of the file: scheme on Windows platforms will need to use an unofficially standard syntax for accessing repositories that are on the same machine, but on a different drive than the client's current working drive. Either of the two following URL path syntaxes will work where X is the drive on which the repository resides: C:\ svn checkout file:///X:/path/to/repos C:\ svn checkout file:///X|/path/to/repos In the second syntax, you need to quote the URL so that the vertical bar character is not interpreted as a pipe. Note that a URL uses ordinary slashes even though the native (non-URL) form of a path on Windows uses backslashes. - For now, I'm happy with a working website :) Omair Emmanuel Venisse wrote: No svn doesn't use cvs connection string style. - Original Message - From: [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:21 PM Subject: RE: subversion repo connection string: (again I know) didn't the scm:svn:pserver:[pserver [EMAIL PROTECTED]:/path/to/svn:my-project-name/trunk works ? Nicolas, Omair-Inam Abdul-Matin [EMAIL PROTECTED] Envoy par : news [EMAIL PROTECTED] 25/05/2004 18:09 Veuillez rpondre Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : subversion repo connection string: (again I know) There was a thread regarding Subversion and a proper connection string for it some time ago. I'm still not sure about the form of the final connection string that pleases Maven. When I try to build my project I get the following error BUILD FAILED File.. C:\Documents and Settings\oiinamul\.maven\plugins\maven-xdoc-plugin-1 .7.1\plugin.jelly Element... velocity:merge Line.. 491 Column 13 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains less than six tokens Total time: 1 minutes 45 seconds Finished at: Tue May 25 12:06:25 EDT 2004 Alas... maven still insists on 6 tokens it seems. So if I have the following, how do I turn it into 6 acceptable tokens: scm:svn:http://my-server-name/svn/my-project-name/trunk I've tried scm:svn:http://my-server-name:svn:project-name/trunk didn't work... Omair - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice for webapp development in WSAD/Eclipse
Hi Al, Basically you are right - they only twist I can add using an ANT wrapper to invoke Maven to setup the exploded web archive. And the ANT Wrapper can be easily executed by the IDE Cheers, Siegfried Goeschl -Original Message- From: Al Robertson [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 13:50 To: Maven Users List Subject: Best practice for webapp development in WSAD/Eclipse All, I was after some feedback on how people structured their WEB (war) applications when using WSAD/Eclipse and maven for development. My directory is structured as follows: /WebProject /src /java /test /java /WebContent /WEB-INF /classes /lib /target (maven generated) As with jar projects, I defined all dependencies in the pom and these are reflected in the .classpath file A simple example: ?xml version=1.0 encoding=UTF-8? classpath classpathentry kind=src path=src/java/ classpathentry kind=src path=src/test/java/ classpathentry kind=var path=SERVERJDK_50_PLUGINDIR/jre/lib/rt.jar sourcepath=SERVERJDK_50_PLUGINDIR/src.jar/ classpathentry kind=var path=MAVEN_REPO/j2ee/jars/j2ee-1.3.jar/ classpathentry kind=var path=MAVEN_REPO/junit/jars/junit-3.8.1.jar/ classpathentry kind=var path=MAVEN_REPO/log4j/jars/log4j-1.2.8.jar/ classpathentry kind=output path=WebContent/WEB-INF/classes/ /classpath This compiles fine. The classes are written to my WebContent/WEB-INF/classes directory. BUT - If I run this application using a WebSphere Test Environment (WTE) server, it will fail because it can't find the log4j classes. The WTE uses the WebContent directory as an exploded war. WTE expects utility jars to be available to the WAS classloader, usually from the WEB-INF/lib directory. If I put the jars in the lib directory, I'm effectively maintaining the dependencies twice (in the pom and in WEB-INF/lib). Of course, when building using maven, the exploded war is created in /target, including dependency jars added to /WEB-INF/lib. That all works fine, especially on a continuous integration server. If I could get WSAD to use the /target/webapp directory in the WTE, that would solve the problem, but I can't. Therefore, using maven in a development environment seems to require deploy the generated ear for each test iteration. This loses much of the power of the WTE. So what do other people do? I've extended war:war to add dependencies defined in the pom to the WebContent/WEB-INF/lib directory. But this requires maven war:war to be run before using WTE for the first time. That doesn't feel right. The whole thing doesn't seem to fit well for war projects (great for jars). I'm still experimenting but I thought I'd ask for help!!! I hope this makes sense :-) Al. Digital Union UK [EMAIL PROTECTED] www.digitalunion.com t: +44 (0) 1483 889482 m:+44 (0) 7713 631367 f: +44 (0) 1483 889450 The information in this email and in any attachment(s) is confidential. If you are not the named addressee(s) or if you receive this email in error then any distribution, copying or use of this communication or the information in it is strictly prohibited. While attachments are virus checked, Digital Union UK Limited does not accept any liability in respect of any virus which is not detected. div style=width:450px; border-top: 1px solid black; border-bottom: 1px solid black; font-family: Arial; font-size: 8pt pThis email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.nbsp; If you have received this email in error please notify your system administrator. br/br/While attachments are virus checked, Digital Union UK Limited does not accept any liability in respect of any virus which is not detected./p /div - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Packaging up a build
I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Packaging up a build
Hi Joel, Check out the dist plugin (run 'maven -g') E.g. 'maven dist:build-src' creates a source distribution Cheers, Siegfried Goeschl -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 19:25 To: Maven Users List Subject: Packaging up a build I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - 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]
RC3 Property Inheritance Problem
I'm trying to generate 1.4 friendly compiled classes. I'm getting failures on the assert keyword. Here's a rundown of my multiproject structure: root/ project.xml (extends root/service/project.xml) project.ent common/ maven/ project.properties project.xml (Parent) entities/ versions.ent dependencies.ent developers.ent service/ maven.xml project.properties project.xml (extends root/common/maven/project.xml) ejb/ project.ent project.properties project.xml (extends root/project.xml) I have the maven.compile.source and maven.compile.target properties set in root/service/project.properties. Yet when I run maven multiproject:install from my root directory I get a warning and error regarding the assert keyword. If I put these properties in a root/project.properties file it works fine. Can anyone tell me if this is a bug or if I'm doing something wrong? -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC3 Property Inheritance Problem
Just to follow up with some more info that I discovered... I created a root/maven.xml to echo the maven.compile.* properties during the build. Somewhere along the way my property values are being lost: build: [echo] maven.compile.source=1.4 [echo] maven.compile.target=1.4 multiproject:install: multiproject:projects-init: [echo] Gathering project list Starting the reactor... snip xdoclet:ejbdoclet: java:prepare-filesystem: java:compile: [echo] maven.compile.source=1.3 [echo] maven.compile.target=1.1 So is the problem in the property inheritance, the java plugin, or the multiproject plugin? Your help is greatly appreciated. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaging up a build
This is certainly helpful, thank you. Any chance that there would be support for war or ear file buiding? Does this only support compilation and jar? Thanks, -joel Göschl,Siegfried wrote: Hi Joel, Check out the dist plugin (run 'maven -g') E.g. 'maven dist:build-src' creates a source distribution Cheers, Siegfried Goeschl -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 19:25 To: Maven Users List Subject: Packaging up a build I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Réf. : XDOC URLs and
Yep, that's the problem. I'm glad to know it's not something I'm doing wrong. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 11:10 AM To: [EMAIL PROTECTED] Subject: Réf. : XDOC URLs and hello is it the http://jira.codehaus.org/browse/MPXDOC-92 ?? if yes you are the third person today to ask about it Julien Extranet [EMAIL PROTECTED] - 25/05/2004 17:56 Veuillez répondre à [EMAIL PROTECTED] Pour : users cc : Objet : XDOC URLs and I have some links in my xdocs that require two parameters. If I just use in the url the build fails. If I use amp; that's what I get in the URL and the URL doesn't work. What am I doing wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - 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: XDOC URLs and
We talk about this several times today. Can you see on the ML archives : http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=12963 Arnaud -Message d'origine- De : STRAYER, JON (SBCSI) [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 17:57 À : 'Maven Users List' Objet : XDOC URLs and I have some links in my xdocs that require two parameters. If I just use in the url the build fails. If I use amp; that's what I get in the URL and the URL doesn't work. What am I doing wrong? - 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]
running tests in a particular order
Is there a way in Maven to override the test:test goal and specify my own tests, resources and goals inside? Basically what I need to do is to tell Maven that I want to clean a database and setup specific data prior to 3 different types of tests. -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Packaging up a build
You can do it with : http://maven.apache.org/reference/plugins/war/ and http://maven.apache.org/reference/plugins/ear/ Arnaud -Message d'origine- De : Joel Shellman [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 20:04 À : Maven Users List Objet : Re: Packaging up a build This is certainly helpful, thank you. Any chance that there would be support for war or ear file buiding? Does this only support compilation and jar? Thanks, -joel Göschl,Siegfried wrote: Hi Joel, Check out the dist plugin (run 'maven -g') E.g. 'maven dist:build-src' creates a source distribution Cheers, Siegfried Goeschl -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 19:25 To: Maven Users List Subject: Packaging up a build I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - 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: SNAPSHOT and multiproject
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : mardi 25 mai 2004 16:35
À : [EMAIL PROTECTED]
Objet : SNAPSHOT and multiproject
Hi,
I have two question, first, how can I make this code working
(in a maven.xml) :
ant:echo${pom.currentVersion}/ant:echo
j:set var=pom.currentVersionSNAPSHOT/j:set
ant:echo${pom.currentVersion}/ant:echo
Display is :
[echo] 3.0.0
[echo] 3.0.0
But I want
[echo] 3.0.0
[echo] SNAPSHOT
Hello Emmanuel,
I don't think that you can do that.
pom.currentVersion is directly retreived from the project description and I
don't think that it is modifiable.
Second question, I have a multiproject versionned as 3.0.0,
this is a J2EE
project (client, ear, service, web...). my client depend on
service project :
dependency
groupIdmsl-murexservice/groupId
artifactIdmurexservice/artifactId
version${pom.currentVersion}/version
typejar/type
/dependency
When I build a snapshot (using *:install-snapshot goals),
Maven use 3.0.0 for
the dependency version
(version${pom.currentVersion}/version), I want maven
replace 3.0.0 per SNAPSHOT. Is there a way to do this without
using the
workaround on first question.
May I am clear ?
Can't you define in a parent project the currentVersion to 3.0.0 and use SNAPSHOT in
subprojects ?
Arnaud
Thx,
-emmanuel
-
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: CVS connection string
It's another solution ;-) Arnaud -Message d'origine- De : Ian Neruda [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 15:34 À : Maven Users List Objet : RE: CVS connection string --- Heritier Arnaud [EMAIL PROTECTED] wrote: you must be logged. before to launch maven : cvs -D :pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir login Arnaud, thank you very much. I had to set cvsroot first and execute login after that. set cvsroot=:pserver:[EMAIL PROTECTED]:d:\cvs_repository\dir cvs login Ian __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - 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: CVS connection string
Return Receipt Your RE: CVS connection string document : was DSEARLE/RSA/NZ received by: at: 26/05/2004 09:13:46 a.m. ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. **
RE: Réf. : in href in xdoc
Return Receipt Your RE: Réf. : in href in xdoc document : was DSEARLE/RSA/NZ received by: at: 26/05/2004 09:13:57 a.m. ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. **
RE: javadoc on generated source directories
Return Receipt Your RE: javadoc on generated source directories document : was DSEARLE/RSA/NZ received by: at: 26/05/2004 09:16:50 a.m. ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. **
RE: javadoc on generated source directories - valid point!
Return Receipt Your RE: javadoc on generated source directories - valid point! document : was DSEARLE/RSA/NZ received by: at: 26/05/2004 09:17:03 a.m. ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. **
Re: Packaging up a build
I'm sorry I wasn't clear. I meant that after running dist:build-src you have an entire tree with an ant script that will build the ear or war. Again, I'm trying to come up with something that I can zip up and send to someone that can do a self contained build. -joel Arnaud Heritier wrote: You can do it with : http://maven.apache.org/reference/plugins/war/ and http://maven.apache.org/reference/plugins/ear/ Arnaud -Message d'origine- De : Joel Shellman [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 20:04 À : Maven Users List Objet : Re: Packaging up a build This is certainly helpful, thank you. Any chance that there would be support for war or ear file buiding? Does this only support compilation and jar? Thanks, -joel Göschl,Siegfried wrote: Hi Joel, Check out the dist plugin (run 'maven -g') E.g. 'maven dist:build-src' creates a source distribution Cheers, Siegfried Goeschl -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 19:25 To: Maven Users List Subject: Packaging up a build I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is pom.siteDirecotry inheritable?
Hi I would like to reuse partent project's pom.siteDirectory in my subproject
like
siteDirectory${pom.siteDirectory}/mysubprojectname /siteDirectory
is it supported?
-Dan
RE: Is pom.siteDirecotry inheritable?
sounds like a recursive call. ${pom.siteDirectory} should point to the current
project's site directory, which references itself again, etc, etc. if you want to
reuse it, define another variable in the parent project mysitedirectory and use it
in both the parent and child:
parent - ${mysitedirectory}
child - ${mysitedirectory}/mysubprojectname
Ryan
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 4:43 PM
To: Maven Users List
Subject: Is pom.siteDirecotry inheritable?
Hi I would like to reuse partent project's pom.siteDirectory
in my subproject
like
siteDirectory${pom.siteDirectory}/mysubprojectname
/siteDirectory
is it supported?
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is pom.siteDirecotry inheritable?
I added a xml element to my parent project and try to reuse it
int my sub project via ${pom.myparentproperty} and ${myparentproperty}
both methods return empty string..
Any more suggestions?
-Dan
- Original Message -
From: Ryan Sonnek [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 2:45 PM
Subject: RE: Is pom.siteDirecotry inheritable?
sounds like a recursive call. ${pom.siteDirectory} should point to the
current project's site directory, which references itself again, etc, etc.
if you want to reuse it, define another variable in the parent project
mysitedirectory and use it in both the parent and child:
parent - ${mysitedirectory}
child - ${mysitedirectory}/mysubprojectname
Ryan
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 4:43 PM
To: Maven Users List
Subject: Is pom.siteDirecotry inheritable?
Hi I would like to reuse partent project's pom.siteDirectory
in my subproject
like
siteDirectory${pom.siteDirectory}/mysubprojectname
/siteDirectory
is it supported?
-Dan
-
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: Is pom.siteDirecotry inheritable?
why are you extending the pom? just set the property in project.properties, and use
the property in your project.xml for both the parent and child projects.
#project.properties snippit
myproperty=/usr/home/someplace
!--parent project.xml snippit --
siteDirectory${myproperty}/siteDirectory
!-- child project.xml snippit --
siteDirectory${myproperty}/projectname/siteDirectory
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 5:30 PM
To: Maven Users List
Subject: Re: Is pom.siteDirecotry inheritable?
I added a xml element to my parent project and try to reuse it
int my sub project via ${pom.myparentproperty} and ${myparentproperty}
both methods return empty string..
Any more suggestions?
-Dan
- Original Message -
From: Ryan Sonnek [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 2:45 PM
Subject: RE: Is pom.siteDirecotry inheritable?
sounds like a recursive call. ${pom.siteDirectory} should
point to the
current project's site directory, which references itself
again, etc, etc.
if you want to reuse it, define another variable in the
parent project
mysitedirectory and use it in both the parent and child:
parent - ${mysitedirectory}
child - ${mysitedirectory}/mysubprojectname
Ryan
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 4:43 PM
To: Maven Users List
Subject: Is pom.siteDirecotry inheritable?
Hi I would like to reuse partent project's pom.siteDirectory
in my subproject
like
siteDirectory${pom.siteDirectory}/mysubprojectname
/siteDirectory
is it supported?
-Dan
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is pom.siteDirecotry inheritable?
Oh mine, it works.
I thought I could define an extra properties in parent's pom.
But put it in partent project.properties is the way to go.
Thank you.
-Dan
- Original Message -
From: Ryan Sonnek [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 3:37 PM
Subject: RE: Is pom.siteDirecotry inheritable?
why are you extending the pom? just set the property in project.properties,
and use the property in your project.xml for both the parent and child
projects.
#project.properties snippit
myproperty=/usr/home/someplace
!--parent project.xml snippit --
siteDirectory${myproperty}/siteDirectory
!-- child project.xml snippit --
siteDirectory${myproperty}/projectname/siteDirectory
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 5:30 PM
To: Maven Users List
Subject: Re: Is pom.siteDirecotry inheritable?
I added a xml element to my parent project and try to reuse it
int my sub project via ${pom.myparentproperty} and ${myparentproperty}
both methods return empty string..
Any more suggestions?
-Dan
- Original Message -
From: Ryan Sonnek [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 2:45 PM
Subject: RE: Is pom.siteDirecotry inheritable?
sounds like a recursive call. ${pom.siteDirectory} should
point to the
current project's site directory, which references itself
again, etc, etc.
if you want to reuse it, define another variable in the
parent project
mysitedirectory and use it in both the parent and child:
parent - ${mysitedirectory}
child - ${mysitedirectory}/mysubprojectname
Ryan
-Original Message-
From: Dan Tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 4:43 PM
To: Maven Users List
Subject: Is pom.siteDirecotry inheritable?
Hi I would like to reuse partent project's pom.siteDirectory
in my subproject
like
siteDirectory${pom.siteDirectory}/mysubprojectname
/siteDirectory
is it supported?
-Dan
-
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]
-
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: SNAPSHOT and multiproject
Heritier Arnaud wrote:
Hello Emmanuel,
I don't think that you can do that.
pom.currentVersion is directly retreived from the project description and I
don't think that it is modifiable.
Arnaud,
it is possible to modify it through a direct call to the currentVersion
setter :
ant:echo${pom.currentVersion}/ant:echo
${pom.setCurrentVersion(SNAPSHOT)}
ant:echo${pom.currentVersion}/ant:echo
===
[echo] 1.0
[echo] SNAPSHOT
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RC3 Property Inheritance Problem
Do any of the plugins you use (eg the xdoclet one) override the values? - Brett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 May 2004 3:56 AM To: Maven Users List Subject: Re: RC3 Property Inheritance Problem Just to follow up with some more info that I discovered... I created a root/maven.xml to echo the maven.compile.* properties during the build. Somewhere along the way my property values are being lost: build: [echo] maven.compile.source=1.4 [echo] maven.compile.target=1.4 multiproject:install: multiproject:projects-init: [echo] Gathering project list Starting the reactor... snip xdoclet:ejbdoclet: java:prepare-filesystem: java:compile: [echo] maven.compile.source=1.3 [echo] maven.compile.target=1.1 So is the problem in the property inheritance, the java plugin, or the multiproject plugin? Your help is greatly appreciated. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SNAPSHOT and multiproject
Gilles Dodinet wrote:
it is possible to modify it through a direct call to the currentVersion
setter :
ant:echo${pom.currentVersion}/ant:echo
${pom.setCurrentVersion(SNAPSHOT)}
ant:echo${pom.currentVersion}/ant:echo
Eeek! It may be possible, which does not mean that it is right. Seems
like a good start to turning your build system into a WMoPC (Writhing
Mass of Primal Chaos, for the non-ADOM types :-))
Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unit Test naming conventions test:test
Have you set unitTestSourceDirectory? You must have this: build unitTestSourceDirectorysrc/test/unitTestSourceDirectory unitTest ... /unitTest /build Of course, replace src/test if this is not actually where you keep your test sources. -Original Message- From: Ian Black [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 8:52 AM To: Maven Users List Subject: Unit Test naming conventions test:test Is the POM the only place where unit test names are referred to... So if I have this... unitTest resources resource directorysrc/test/directory includes include**/*.properties/include include**/*.xml/include include**/*.xsd/include /includes /resource /resources includes include**/Test*.java/include include**/*Bug.*/include /includes /unitTest ...then logically my Unit Tests should be prefixed with 'Test'. The problem is they're not being picked up when I run test:test. I have another project where the above naming convention does work and I can't see where else the filenames are referred to. I'm sure it's obvious...but anyone know? Thanks. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.688 / Virus Database: 449 - Release Date: 18/05/2004 - 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: Réf. : in href in xdoc
Return Receipt Your RE: Réf. : in href in xdoc document : was Mark Katheklakis/HO/Allianz-AU received by: at: 26/05/2004 10:36:45 AM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories - valid point!
Return Receipt Your RE: javadoc on generated source directories - valid point! document : was Mark Katheklakis/HO/Allianz-AU received by: at: 26/05/2004 10:37:39 AM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories
Return Receipt Your RE: javadoc on generated source directories document : was Mark Katheklakis/HO/Allianz-AU received by: at: 26/05/2004 10:37:48 AM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Packaging up a build
Just create an ant build.xml file in the same directory as your maven project.xml file. Put whatever you need in build.xml and the file will get zipped up with everything else when you use the maven dist goal. -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 4:27 PM To: Maven Users List Subject: Re: Packaging up a build I'm sorry I wasn't clear. I meant that after running dist:build-src you have an entire tree with an ant script that will build the ear or war. Again, I'm trying to come up with something that I can zip up and send to someone that can do a self contained build. -joel Arnaud Heritier wrote: You can do it with : http://maven.apache.org/reference/plugins/war/ and http://maven.apache.org/reference/plugins/ear/ Arnaud -Message d'origine- De : Joel Shellman [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mai 2004 20:04 À : Maven Users List Objet : Re: Packaging up a build This is certainly helpful, thank you. Any chance that there would be support for war or ear file buiding? Does this only support compilation and jar? Thanks, -joel Göschl,Siegfried wrote: Hi Joel, Check out the dist plugin (run 'maven -g') E.g. 'maven dist:build-src' creates a source distribution Cheers, Siegfried Goeschl -Original Message- From: Joel Shellman [mailto:[EMAIL PROTECTED] Sent: Dienstag, 25. Mai 2004 19:25 To: Maven Users List Subject: Packaging up a build I'm looking to switch our development to using Maven. A coworker has told me that he needs a way to zip up our source and send it to someone else so they can build it. The concern is this would be difficult if we were using maven (he says requiring them to install maven is unacceptable). Are there any tools or functions out there that would make it easier to do this? I guess what we would need is an export to ant script sort of function that also included all the dependent libraries. Thank you, Joel Shellman - 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: Réf. : XDOC URLs and
Whilst waiting for the fix, I worked around the bug with the following 'dodgy hack'... In maven.xml, add a xdoc:jelly-transform postGoal to replace the amp; output with amp; For example... postGoal name=xdoc:jelly-transform ant:echoReplacing ampamp; with amp;/ant:echo ant:replace dir=target/docs token=ampamp; value=amp;/ /postGoal Cheers Mark [EMAIL PROTECTED] on 05/26/2004 02:09:38 AM Please respond to Maven Users List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Réf. : XDOC URLs and hello is it the http://jira.codehaus.org/browse/MPXDOC-92 ?? if yes you are the third person today to ask about it Julien Extranet [EMAIL PROTECTED] - 25/05/2004 17:56 Veuillez répondre à [EMAIL PROTECTED] Pour : users cc : Objet : XDOC URLs and I have some links in my xdocs that require two parameters. If I just use in the url the build fails. If I use amp; that's what I get in the URL and the URL doesn't work. What am I doing wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email and any attachments is intended solely for the addressee. It is confidential, may contain personal information and may be subject to legal professional privilege. Unauthorised use is strictly prohibited and may be unlawful. If you have received this by mistake, confidentiality and any legal privilege are not waived or lost and we ask that you contact the author and delete and destroy this and any other copies. In relation to any legal use you may make of the contents of this email, you must ensure that you comply with the Privacy Act (Cth) 1988 and you should note that the contents may be subject to copyright and therefore may not be reproduced, communicated or adapted without the express consent of the owner of the copyright. Allianz will not be liable in connection with any data corruption, interruption, delay, computer virus or unauthorised access or amendment to the contents of this email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS connection string
ntserver is a valid protocol for cvsnt. On Tue, 25 May 2004 15:45:40 +0800, Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 25 May 2004 15:40, Ian Neruda wrote: Hi! I try to connect to cvs respository using scm|cvs|ntserver|username|[EMAIL PROTECTED]|d:\cvs_repository\dir1|moduleName seven characters. I have never heard of ntserver as an CVS protocol. Sure you don't mean pserver? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - 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: CVS connection string
Have you got an example?? On Tue, 25 May 2004 09:42:03 -0400, Lee Rodgers [EMAIL PROTECTED] wrote: I am not sure if anyone else is having this problem I am trying to use the maven-latka plugin and using the Jmeter Convert functionality and it doesn't bring over any of the parameter values. So the newly created latka suite does not run. I would then need to add all the parameters to the latka suite file. Is anyone else having this problem or have a solution? I am using Maven-Latka-Plugin-1.4 . Lee - 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: running tests in a particular order
Hmmm, aren't tests supposed to be able to be run in any order regardless? Have you tried using something like dbunit? http://dbunit.sf.net On Tue, 25 May 2004 13:47:44 -0700, Warner Onstine [EMAIL PROTECTED] wrote: Is there a way in Maven to override the test:test goal and specify my own tests, resources and goals inside? Basically what I need to do is to tell Maven that I want to clean a database and setup specific data prior to 3 different types of tests. -warner - 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: running tests in a particular order
We're using dbunit for some of the tests, but we need to clean and reset the database before each set of tests. Currently we are doing this through Ant tasks and I am converting these over to Maven goals. I've contemplated moving this part into the Unit test setup and teardown, but the other tests are StrutsTestCases and JWebUnit tests so they need a clean database to work with. -warner On May 25, 2004, at 6:39 PM, Dion Gillard wrote: Hmmm, aren't tests supposed to be able to be run in any order regardless? Have you tried using something like dbunit? http://dbunit.sf.net On Tue, 25 May 2004 13:47:44 -0700, Warner Onstine [EMAIL PROTECTED] wrote: Is there a way in Maven to override the test:test goal and specify my own tests, resources and goals inside? Basically what I need to do is to tell Maven that I want to clean a database and setup specific data prior to 3 different types of tests. -warner - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tests in a particular order
We have a base class that our StrutsTestCases inherit from that uses dbunit :-) On Tue, 25 May 2004 19:53:48 -0700, Warner Onstine [EMAIL PROTECTED] wrote: We're using dbunit for some of the tests, but we need to clean and reset the database before each set of tests. Currently we are doing this through Ant tasks and I am converting these over to Maven goals. I've contemplated moving this part into the Unit test setup and teardown, but the other tests are StrutsTestCases and JWebUnit tests so they need a clean database to work with. -warner On May 25, 2004, at 6:39 PM, Dion Gillard wrote: Hmmm, aren't tests supposed to be able to be run in any order regardless? Have you tried using something like dbunit? http://dbunit.sf.net On Tue, 25 May 2004 13:47:44 -0700, Warner Onstine [EMAIL PROTECTED] wrote: Is there a way in Maven to override the test:test goal and specify my own tests, resources and goals inside? Basically what I need to do is to tell Maven that I want to clean a database and setup specific data prior to 3 different types of tests. -warner - 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] - 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: javadoc on generated source directories
Hi Arnaud, Per my off-list email, your latest version of the patch looks fine. Thanks! Denis On Sat, 2004-05-22 at 13:59, Arnaud Heritier wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud -Message d'origine- De : Arnaud Heritier [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 15:41 À : 'Maven Users List'; [EMAIL PROTECTED] Objet : RE: javadoc on generated source directories -Message d'origine- De : Denis McLaughlin [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 06:02 À : Maven Users List Objet : RE: javadoc on generated source directories Alrighty, I found an existing issue on Jira regarding the use of maven.compile.src.set with Javadoc: http://jira.codehaus.org/browse/MPJAVADOC-5 yes So I've attached my 1.3 patch to that issue, and added a comment. thanks For what it's worth, I'd be happy to generate a patch against 1.4 or 1.5 (the relevant sections being the same in both, I believe), but I have some questions about the newer plugins. If someone can answer these, I'll poop out a patch against 1.5. I will try to answer ;-) I think moving the fileset generation from the maven-javadoc-plugin:report tag to the check-needed tag is so that the contents of the fileset can be checked: if there's nothing in there, needed is set to false and javadoc will never even be called. Also, the fileset is passed out of the check-needed tag via the sourceSet refid. All right. To support multiple source directories, I can change the check-needed tag so that it iterates across maven.compile.src.set, setting needed to be true if there are files in any of the filesets, and false otherwise. Seems to be good. The problem is to not duplicate entries between pom.build.sourceDirectory and maven.compile.src.set However, I don't think there's any way to preserve the functionality of passing the fileset out via sourceSet: can filesets be added to one another, so that the set of all files in all directories of maven.compile.src.set can be put into one fileset? If not, it means iterating across the directories of maven.compile.src.set twice: once to set the needed value, and again when the filesets are needed in the javadoc tag. Not pretty, but it should work. You can't have in ant a fileset with several directories. We can begin to test if it works. We will optimize it after. Can someone let me know if this sounds vaguely correct? If I have a basic understanding of this, I'll generate a patch against the 1.5 javadoc and put it up on jira. This sounds correct. I'll test your patch as soon as possible. Arnaud Denis On Wed, 2004-05-19 at 05:58, Arnaud Heritier wrote: I'm working on a release 1.5.1 for the javadoc which will be supplied in RC3. If you have a patch, post it on Jira and it will be applied. Arnaud -Message d'origine- De : Martin Skopp [mailto:[EMAIL PROTECTED] Envoyé : mercredi 19 mai 2004 09:18 À : Maven Users List Objet : Re: javadoc on generated source directories On Tue, 2004-05-18 at 07:33, Denis McLaughlin wrote: I had sent the email below asking for some information about modifying the maven javadoc plugin to properly support the maven.compile.src.set. I've generated a patch that seems to do the right thing: it's attached below. Comments quite welcome. Raise a JIRA issue, I wanna vote for it :-) Lets hope that it will be included in RC3, cu -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
