scm:checkout not using supplied password
Hi, I'm having trouble with the scm:checkout goal (M1.1, using the 1.6.1 scm plugin, Windows XP) From what I can see my scm url is fine (scm:cvs:pserver:jshute:[EMAIL PROTECTED]:/home/source:MyModule), but when it does the checkout it's refusing to use the password I've supplied in the URL. Instead it always outputs a warning about blank password. The only way I can get it to work is to manually do a cvs login and then enter the password. Then if I do the maven scm:checkout again it works fine. This would suggest that the checkout is deferring to the CVS install on my box, rather than any inbuilt java CVS library. Is there any way to control this? I've seen references to some maven.scm.provider.cvs.implementation property, but it's not clear what that would be set to, or whether it's applicable to Maven 1. Anybody know how to get round this? I need to get my build set up so it's totally scripted with no command line input required- so the cvs login approach is no good, as for the cvs impl I have there's no way of supplying the password other than typing it in when prompted thanks James - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin release schedules
Fantastic news - thanks very much James -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 9:28 PM To: Maven Users List Subject: Re: Plugin release schedules Hi James, I pinged the dev list about the IDEA plugin last week, to see if anyone had something more they wanted to add before a release. I'm planning to release 2.1 within the next couple of weeks. Shute, James wrote: Apologies if this question is answered in an FAQ somewhere but I can't for the life of me find it... Where should I look to see what the release schedule is for M2 plugins etc? I'm particularly interested in getting the 2.1 version of the Idea plugin as it'll have issue MIDEA-62 fixed. Given I'm in a corporate environment I'd really rather not go down the build from HEAD route if at all possible, so would like to use the official version if I can. thanks James - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2 : Controlling WEB-INF/lib contents in war
The target layout I'm after is: ear | |-lib | |-a.jar | |-b.jar | |-webapp | |-WEB-INF |-web.xml |-lib |-c.jar I can't use warSourceExcludes as AFAIK excludes take precedence over includes, so I can't exclude *.jar but then include c.jar For it to work using warSourceIncludes I'd need to be able to specify: - **/*.xml - **/*.css - **/*.jpg (etc) - **/c.jar but warSourceIncludes only lets you specify a single value as sadly it doesn't take a list of includes. I have tried a comma separated list but that doesn't work either. Even if it did the include list is pretty ugly and error prone. thanks -Original Message- From: Antonio Petrelli [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 3:55 PM To: Maven Users List Subject: Re: M2 : Controlling WEB-INF/lib contents in war 2007/4/17, Kathryn Huxtable [EMAIL PROTECTED]: He meant scope. -K No, no! I meant profile, but I misunderstood his needs. James, why using warSourceIncludes for your 2 special cases is not feasible? Do you mean that in the EAR there could be a previous version of a JAR than that in the WAR? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
M2 : Controlling WEB-INF/lib contents in war
I'm having a go at migrating my app to M2 and have hit a bit of a roadblock. For my war module I don't want the dependencies to go into WEB-INF/lib, with the exception of 2 of them, which do have to live in there (for reasons to do with Weblogic's class-loading) Now under M1 this was easy - just set the war.bundle property appropriately when defining the dependencies. I've read this article: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.ht ml That lets me stop all jars going into that dir, but I can't find any way to specify things so those 2 special cases do get included. An alternative approach I've tried is in the pom for the war to specify the dependencies again, but with a scope of provided, which does stop them being bundled in. However this is a bit of a hack as if I change the versions / add dependencies in future I've got to remember to change them there too, which isn't great. If there was some way to specify the overriding dependency so it picked up the version already defined that would be an improvement - is that possible? Any suggestions / advice very much appreciated thanks James - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2 : Controlling WEB-INF/lib contents in war
Not sure I follow how profiles help here? My understanding was that they let you control different versions of the build, e.g. to target different runtimes / containers etc. I don't have any such requirement - I just want to build my ear file one way all the time. NB: Provided works for me here as the jars will be in the main ear file, so will be available to the war file thanks -Original Message- From: Antonio Petrelli [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 3:24 PM To: Maven Users List Subject: Re: M2 : Controlling WEB-INF/lib contents in war 2007/4/17, Shute, James [EMAIL PROTECTED]: An alternative approach I've tried is in the pom for the war to specify the dependencies again, but with a scope of provided, which does stop them being bundled in. However this is a bit of a hack as if I change the versions / add dependencies in future I've got to remember to change them there too, which isn't great. Use different profiles. The provided scope means exactly that the container will provide it. If it is in a directory of your Weblogic instance, well, I think it's provided :-) Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2 : Controlling WEB-INF/lib contents in war
I had already seen about scopes and my original mail did note that
setting the scope to provided for a.jar and b.jar did give me the layout
I wanted, but meant I had to duplicate all the dependencyversion
details which I wasn't keen on.
I have now found the dependencyManagement section I can declare in the
parent POM which means I can declare the version in that, and then the
scope override in my webapp module pom. This seems to give me what I
need for my command line build which is a good start. Unfortunately the
corresponding IDEA module generated suffers from the bug MIDEA-62, but
that'll get fixed when the 2.1 version of that plugin is released.
thanks
-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 5:04 PM
To: Maven Users List
Subject: Re: M2 : Controlling WEB-INF/lib contents in war
On 4/17/07, Shute, James [EMAIL PROTECTED] wrote:
The target layout I'm after is:
ear
|
|-lib
| |-a.jar
| |-b.jar
|
|-webapp
|
|-WEB-INF
|-web.xml
|-lib
|-c.jar
I can't use warSourceExcludes as AFAIK excludes take precedence over
james,
I think you need to look at the bottom of
http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-g
uide.html
in particular:
dependencies
dependency
groupIdorg.foo/groupId
artifactIdbar-jar1/artifactId
version${pom.version}/version
optionaltrue/optional
!-- goes in manifest classpath, but not included in WEB-INF/lib
--
/dependency
dependency
groupIdorg.foo/groupId
artifactIdbar-jar2/artifactId
version${pom.version}/version
!-- goes in manifest classpath, AND included in WEB-INF/lib --
/dependency
dependency
groupIdorg.foo/groupId
artifactIdbar-jar1/artifactId
version${pom.version}/version
scopeprovided/scope
!-- excluded from manifest classpath, and excluded from
WEB-INF/lib --
/dependency
Jerome
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as an
offer to sell or as a solicitation of an offer to buy any financial product, an
official confirmation of any transaction, or as an official statement of Lehman
Brothers. Email transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or accurate
and it should not be relied upon as such. All information is subject to change
without notice.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Plugin release schedules
Apologies if this question is answered in an FAQ somewhere but I can't for the life of me find it... Where should I look to see what the release schedule is for M2 plugins etc? I'm particularly interested in getting the 2.1 version of the Idea plugin as it'll have issue MIDEA-62 fixed. Given I'm in a corporate environment I'd really rather not go down the build from HEAD route if at all possible, so would like to use the official version if I can. thanks James - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven + XmlBeans + IDE
Hi, I've got an M1 project which uses xmlbeans, which I'm looking to convert over to M2. Now I've done this for the command line build using the standard XmlBeans plugin and that all works nicely. The point where I have a problem is then doing development work in an IDE (preferably Idea, though I have the same problem with Eclipse). The issue is that the IDE knows nothing about the src / classes generated by the xmlbeans plugin, so my build in the IDE fails. Now I can hack the Idea module file so the target\xmlbeans-source file is picked up as a source directory, but that still isn't sufficient as the classes need to find the TypeSystemHolder class (and associated files) which are generated to target\classes\schemaorg_apache_xmlbeans With my M1 build I hacked it so that all the generated xmlbeans classes were bundled into a standalone jar in target, which I then got Idea / Eclipse to use as a dependency. However this is very much a hack, so when moving to M2 I'd really like to do it the right way. Question is, what is the right way? Any help very much appreciated! thanks James - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[1.1-RC1] Scm parse issue
Just noticed a weird little issue whilst doing a release with the latest 1.1-RC1 snapshot. If I do maven scm:perform-release, and have maven.scm.url set to scm:cvs:pserver:anon:@cvshost:/home/source:MyModule then it works absolutely fine, but the scm:parse-connection goal produces some very misleading output: scm:parse-connection: [echo] Using SCM method: cvs [echo] Using CVSROOT: :pserver:anon:@cvshost [echo] Using module: /home/source This is obviously quite wrong. Removing the : from after anon in the url (i.e. the bit that says use a blank password) makes the output from scm:parse-connection correct, but then the checkout step fails (presumably because it's no longer tying to use a blank password) Am I doing something wrong, or is this a bug? James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 1.1 RC1 SNAPSHOT needs testers
Arnaud, I've had no issues with this snapshot so I'd be keen to see a 1.1 final version based on it James -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 6:04 AM To: Maven Users List Subject: Re: Maven 1.1 RC1 SNAPSHOT needs testers Arnaud, we are also on Maven 1.1 and would love a release. I'm on holidays and unable to do a complete test, but I will do so early next week. Is that ok? On 10/12/06, Arnaud HERITIER [EMAIL PROTECTED] wrote: Thanks James for your feedback. We'll add a note about plugin dependencies in projects. Nobody else is interested by maven 1.1 ? Should we continue to try to release a final version 1.1 ? Everybody moved to maven 2 or your existing maven 1.x satisfy you ? Arnaud On 10/10/06, Shute, James [EMAIL PROTECTED] wrote: You're quite correct - I had put an explicit dependency on scm-1.5 in my project.xml a while back when we were on 1.0.2 and I wanted to force people up to the later version of the plugin. Taking that out fixes things. thanks very much James -Original Message- From: Lukas Theussl [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 11:45 AM To: Maven Users List Subject: Re: Maven 1.1 RC1 SNAPSHOT needs testers This seems to be the cause indeed, the scm:status goal was only added in version 1.6 of the scm plugin. You don't have a dependency on 1.5 by any chance? Try to remove the .maven/cache/maven-scm-plugin-1.5/ directory and see what happens.. -Lukas Shute, James wrote: Arnaud, I've succesfully been using 1.1b2 for a while so thought I'd give this a spin. I'm having trouble with the scm:prepare-release goal. I've included the output when running with -X below. I'm no expert but it looks a bit suspicious that the version of maven-scm-plugin mentioned in the 2nd line below is 1.6, but in the BUILD FAILED section is 1.5. Is this a known issue? I'm running on WinXP SP2 with the 1.5.0_05 JDK if that helps in any way. I also cleaned out the cache before starting so it's not that causing the problem. thanks James Output from maven -X scm:prepare-release: ... Reinstalling: source = C:\Temp\.maven\cache\maven-scm-plugin-1.6\plugin.jelly project = null script = null Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm popping off [EMAIL PROTECTED] for [EMAIL PROTECTED] in com.lehman.fid:Jdialtone BUILD FAILED File.. file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly Element... scm:status Line.. 192 Column 158 org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/s cm/r ep ository/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apach e/ maven/scm/command/status/StatusScmResult; org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [scm:prepare-release] -- file:/C:/Temp/.maven/cache/maven-scm-plugin -1.5/plugin.jelly:192:158: scm:status org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/s cm/r ep ository/ScmRepository;Lorg/a pache/maven/scm/ScmFileSet;)Lorg/apache/maven/scm/command/status/S tatu sS cmResult; at org.apache.maven.werkz.Goal.fire(Goal.java:654) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.ja va:7 11 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264) at org.apache.maven.cli.App.doMain(App.java:556) at org.apache.maven.cli.App.main(App.java:1411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm pl.j av a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc cess or Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly:192:158: scm:status or g.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm /rep os itory/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apache/ ma ven/scm/command/status/StatusScmResult; at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag. java :1 93) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript. java :1 02
Machine specific settings
I'm having a go at moving from Maven 1.x up to 2.0 and can't quite work out the correct way to model local machine specific settings. I've looked through the docs and mailing lists so have found various details about profiles but I can't quite see how to use them to cater for certain setup issues. Take, for example, the jdkName property for the idea plugin. Under 1.x I just added this to my build.properties: maven.idea.jdk=1.4 and all is well - that's the name I've given to it in my local Idea setup so it works nicely. Now switching over to M2 I could just put this in the pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-idea-plugin/artifactId configuration jdkName1.4/jdkName /configuration /plugin Now this forces every developer to have a JDK set up in Idea called 1.4, which they may not want - perhaps they prefer to name them fully (e.g. 1.4.2_05). I did look to just put an override for this setting in a settings.xml or profiles.xml file, but changing plugin settings seems to be disallowed in these files. Another example would be specifying a specific compiler executable. This can be set in the pom plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration executableC:/Program Files/Java/jdk1.4.2_05/bin/javac/executable but that relies on everybody installing Java to the same location, which never happens, so doesn't work. Can somebody enlighten me? Given the amount of thought that's clearly gone into M2 I'm sure this sort of thing must be catered for and it's just me not seeing how thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Machine specific settings
Afraid I'd already tried that but it doesn't work: org.apache.maven.reactor.MavenExecutionException: Failed to activate local (project-level) build profiles: Cannot parse profiles.xml resource from dir C:\Dev\Foo ... Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'build' (position: START_TAG seen .../properties This would seem to be consistent with the documentation at http://maven.apache.org/guides/introduction/introduction-to-profiles.htm l under the Which areas of a POM can be customized by each type of profile? Why? section, which says you can only customise the plugin config in the actual pom.xml, not the settings.xml or profile.xml I'm using 2.0.4 - are you using a newer build that now supports this? thanks James -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet Sent: Wednesday, October 11, 2006 2:17 PM To: users@maven.apache.org Subject: Re: Machine specific settings Add in ~/.m2/settings.xml a profilesprofile that defaults activates and has a buildpluginsplugin... idea with configurationjdkName1.4/jdkName Or create a profiles.xml file in your project dir, which does the same thing. See the free m2 book. Shute, James wrote, On 2006-10-11 11:25 AM: I'm having a go at moving from Maven 1.x up to 2.0 and can't quite work out the correct way to model local machine specific settings. I've looked through the docs and mailing lists so have found various details about profiles but I can't quite see how to use them to cater for certain setup issues. Take, for example, the jdkName property for the idea plugin. Under 1.x I just added this to my build.properties: maven.idea.jdk=1.4 and all is well - that's the name I've given to it in my local Idea setup so it works nicely. Now switching over to M2 I could just put this in the pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-idea-plugin/artifactId configuration jdkName1.4/jdkName /configuration /plugin Now this forces every developer to have a JDK set up in Idea called 1.4, which they may not want - perhaps they prefer to name them fully (e.g. 1.4.2_05). I did look to just put an override for this setting in a settings.xml or profiles.xml file, but changing plugin settings seems to be disallowed in these files. Another example would be specifying a specific compiler executable. This can be set in the pom plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration executableC:/Program Files/Java/jdk1.4.2_05/bin/javac/executable but that relies on everybody installing Java to the same location, which never happens, so doesn't work. Can somebody enlighten me? Given the amount of thought that's clearly gone into M2 I'm sure this sort of thing must be catered for and it's just me not seeing how thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information
RE: Maven 1.1 RC1 SNAPSHOT needs testers
Arnaud, I've succesfully been using 1.1b2 for a while so thought I'd give this a spin. I'm having trouble with the scm:prepare-release goal. I've included the output when running with -X below. I'm no expert but it looks a bit suspicious that the version of maven-scm-plugin mentioned in the 2nd line below is 1.6, but in the BUILD FAILED section is 1.5. Is this a known issue? I'm running on WinXP SP2 with the 1.5.0_05 JDK if that helps in any way. I also cleaned out the cache before starting so it's not that causing the problem. thanks James Output from maven -X scm:prepare-release: ... Reinstalling: source = C:\Temp\.maven\cache\maven-scm-plugin-1.6\plugin.jelly project = null script = null Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm popping off [EMAIL PROTECTED] for [EMAIL PROTECTED] in com.lehman.fid:Jdialtone BUILD FAILED File.. file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly Element... scm:status Line.. 192 Column 158 org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/rep ository/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apache/ maven/scm/command/status/StatusScmResult; org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [scm:prepare-release] -- file:/C:/Temp/.maven/cache/maven-scm-plugin -1.5/plugin.jelly:192:158: scm:status org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/rep ository/ScmRepository;Lorg/a pache/maven/scm/ScmFileSet;)Lorg/apache/maven/scm/command/status/StatusS cmResult; at org.apache.maven.werkz.Goal.fire(Goal.java:654) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:711 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264) at org.apache.maven.cli.App.doMain(App.java:556) at org.apache.maven.cli.App.main(App.java:1411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly:192:158: scm:status or g.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/repos itory/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apache/ma ven/scm/command/status/StatusScmResult; at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:1 93) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:1 02) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) ... 11 more Caused by: java.lang.NoSuchMethodError: org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/rep ository/ScmRepository;Lorg/a pache/maven/scm/ScmFileSet;)Lorg/apache/maven/scm/command/status/StatusS cmResult; at org.apache.maven.plugins.scm.ScmStatusBean.status(ScmStatusBean.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:1 80) ... 16 more Final Memory : 3M/7M -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 11:20 PM To: Maven Users List Subject: Maven 1.1 RC1 SNAPSHOT needs testers Hi everybody, We just deployed a new SNAPSHOT of maven 1.1 RC1 [1]. This version incorporates 2 important changes and we would like to have your feedback : - MAVEN-1755 : We fixed the last main backward incompability with maven 1.0.x, this new version supports XML entities in the POM. - MAVEN-1789 : The default repository is now http://repo1.maven.org/maven/ ( These two issues aren't yet closed because we have to update the documentation and we are waiting for your feedback ;-) ) Be careful, that to use this snapshot version, you'll certainly have to define the following set of remote repositories to download dependencies.
RE: Maven 1.1 RC1 SNAPSHOT needs testers
You're quite correct - I had put an explicit dependency on scm-1.5 in my project.xml a while back when we were on 1.0.2 and I wanted to force people up to the later version of the plugin. Taking that out fixes things. thanks very much James -Original Message- From: Lukas Theussl [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 11:45 AM To: Maven Users List Subject: Re: Maven 1.1 RC1 SNAPSHOT needs testers This seems to be the cause indeed, the scm:status goal was only added in version 1.6 of the scm plugin. You don't have a dependency on 1.5 by any chance? Try to remove the .maven/cache/maven-scm-plugin-1.5/ directory and see what happens.. -Lukas Shute, James wrote: Arnaud, I've succesfully been using 1.1b2 for a while so thought I'd give this a spin. I'm having trouble with the scm:prepare-release goal. I've included the output when running with -X below. I'm no expert but it looks a bit suspicious that the version of maven-scm-plugin mentioned in the 2nd line below is 1.6, but in the BUILD FAILED section is 1.5. Is this a known issue? I'm running on WinXP SP2 with the 1.5.0_05 JDK if that helps in any way. I also cleaned out the cache before starting so it's not that causing the problem. thanks James Output from maven -X scm:prepare-release: ... Reinstalling: source = C:\Temp\.maven\cache\maven-scm-plugin-1.6\plugin.jelly project = null script = null Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm Caching Taglib Uri -- scm:transform Caching Taglib Uri -- changes:transform Caching Taglib Uri -- scm popping off [EMAIL PROTECTED] for [EMAIL PROTECTED] in com.lehman.fid:Jdialtone BUILD FAILED File.. file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly Element... scm:status Line.. 192 Column 158 org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/r ep ository/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apache/ maven/scm/command/status/StatusScmResult; org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [scm:prepare-release] -- file:/C:/Temp/.maven/cache/maven-scm-plugin -1.5/plugin.jelly:192:158: scm:status org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/r ep ository/ScmRepository;Lorg/a pache/maven/scm/ScmFileSet;)Lorg/apache/maven/scm/command/status/Statu sS cmResult; at org.apache.maven.werkz.Goal.fire(Goal.java:654) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:7 11 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264) at org.apache.maven.cli.App.doMain(App.java:556) at org.apache.maven.cli.App.main(App.java:1411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j av a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess or Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly:192:158: scm:status or g.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/rep os itory/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;)Lorg/apache/ma ven/scm/command/status/StatusScmResult; at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java :1 93) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java :1 02) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag .j ava:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perform Ac tion(MavenGoalTag.java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) ... 11 more Caused by: java.lang.NoSuchMethodError: org.apache.maven.scm.manager.ScmManager.status(Lorg/apache/maven/scm/r ep ository/ScmRepository;Lorg/a pache/maven/scm/ScmFileSet;)Lorg/apache/maven/scm/command/status/Statu sS cmResult; at org.apache.maven.plugins.scm.ScmStatusBean.status(ScmStatusBean.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j av a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess or Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java :1 80) ... 16 more Final Memory
Scm problem
I've been on 1.0.2 for a while and so thought I'd move on up to one of the 1.1 rcs. I'm having trouble with rc3 though - when I do certain scm operations it fails. e.g. scm:update scm:update: [echo] Updating from SCM BUILD FAILED File.. file:/C:/Temp/.maven/cache/maven-scm-plugin-1.5/plugin.jelly Element... scm:update Line.. 131 Column 138 org.apache.maven.scm.manager.ScmManager.update(Lorg/apache/maven/scm/rep ository/ScmRepository;Lorg/apache/maven/scm/ScmFileSet;Ljava/lang/String ;)Lorg/apache/maven/scm/command/update/UpdateScmResult; This is the repo section from my project.xml: repository connectionscm:cvs:pserver:[EMAIL PROTECTED]:/home/eu_fid_source/eufidetradec vs:Jdialtone/connection developerConnectionscm:cvs:pserver:[EMAIL PROTECTED]:/home/eu_fid _source/eufidetradecvs:Jdialtone/developerConnection /repository Running scm:parse-connection shows it's working things out from the url fine, so I'm not sure what could be wrong. Using rc2 is absolutely fine though. Any ideas? I have had a browse through the archives but I can't see anything that looks like the answer thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: build after every checkin
Are there any plans to add support for this though? Those of us using Continuum in corporate environments may well not be able to add hooks into the scm system so it would certainly be a great plus point for me. James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:54 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin Continuum can do this but without the interface. You need to wite a xml-rpc client (http://maven.apache.org/continuum/guides/mini/guide-xmlrpc-api.html) and add a hook in your scm. Emmanuel Satish a écrit : How can i configure the build to happen after every checkin instead of the sceduled time. Does continum does this by default? when i go schedules tab, i only see specifying the cron timings - expressions. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: build after every checkin
Not sure you understood my point - our CVS repo is managed and administered by a separate team using servers we have no access to (other than via standard CVS access). Hence any sort of hook based approach is no use to me - regardless of whether there's a helper class or not. So some sort of scan for updates approach (as Cruisecontrol does) would be good for me. This would also be easier for users who want to just run Continuum out of the box and not worry about SCM hooks - I'm betting a decent percentage of Continuum users don't have a suitably high level of familiarity with their scm system to do that. Is a solution just to set the schedule to a small interval, like every 5 minutes? Is there any downside to that? James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 8:06 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin We can't add a hook in your scm. It's generally a script that you add in a directory of your scm. We can't create the full xml-rpc because it depends on how you want to use it, but we provide a helper class that will help you. Emmanuel Shute, James a écrit : Are there any plans to add support for this though? Those of us using Continuum in corporate environments may well not be able to add hooks into the scm system so it would certainly be a great plus point for me. James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:54 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin Continuum can do this but without the interface. You need to wite a xml-rpc client (http://maven.apache.org/continuum/guides/mini/guide-xmlrpc-api.html) and add a hook in your scm. Emmanuel Satish a écrit : How can i configure the build to happen after every checkin instead of the sceduled time. Does continum does this by default? when i go schedules tab, i only see specifying the cron timings - expressions. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: build after every checkin
Excellent - thanks -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 8:26 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin oh I misunderstood. It's the default mode. With a small interval, it will be ok. Emmanuel Shute, James a écrit : Not sure you understood my point - our CVS repo is managed and administered by a separate team using servers we have no access to (other than via standard CVS access). Hence any sort of hook based approach is no use to me - regardless of whether there's a helper class or not. So some sort of scan for updates approach (as Cruisecontrol does) would be good for me. This would also be easier for users who want to just run Continuum out of the box and not worry about SCM hooks - I'm betting a decent percentage of Continuum users don't have a suitably high level of familiarity with their scm system to do that. Is a solution just to set the schedule to a small interval, like every 5 minutes? Is there any downside to that? James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 8:06 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin We can't add a hook in your scm. It's generally a script that you add in a directory of your scm. We can't create the full xml-rpc because it depends on how you want to use it, but we provide a helper class that will help you. Emmanuel Shute, James a écrit : Are there any plans to add support for this though? Those of us using Continuum in corporate environments may well not be able to add hooks into the scm system so it would certainly be a great plus point for me. James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:54 AM To: continuum-users@maven.apache.org Subject: Re: build after every checkin Continuum can do this but without the interface. You need to wite a xml-rpc client (http://maven.apache.org/continuum/guides/mini/guide-xmlrpc-api.html) and add a hook in your scm. Emmanuel Satish a écrit : How can i configure the build to happen after every checkin instead of the sceduled time. Does continum does this by default? when i go schedules tab, i only see specifying the cron timings - expressions. - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete
DB connection details
Hi, I've got a Maven1 project building under Continuum, but now have some unit tests that need to connect to a database. When I just run the tests on my box via Maven then I leave the username / password blank so it uses the integrated security and picks up the username / password of the current user, which is great and works nicely. But when running under Continuum this doesn't work as the account it's running as doesn't have DB access. Now due to various audit / security policies in place here giving that account access to the db isn't an option. Now the only working solution I've come up with so far is to specify system properties on the command line which give the username and password. These can then be specified in the arguments section on the project build definition page in Continuum. BUT. Those values are publicly viewable, i.e. everybody can see the password and I'm not exactly keen on that. Access to the build box is more restricted so a solution based on a local file there would be better (even if the password has to be stored as plain text) Anybody got any suggestions? I would just put the properties in the local build.properties file for the project on the build box, but that gets blown away by the CVS update. thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
M1 Snapshots
Hi, I've got 2 projects (both Maven 1.x) where project A depends on project B. Now at the moment I've got them both building in Continuum independently which is ok, but what I'd really like is that when building A it uses the latest build of B done by Continuum. Ideally a change to B would also trigger a build of A. Now I'm sure the solution to this involves SNAPSHOTs and probably Continuum's internal repository which I've seen mentioned in a few posts. But I've been unable from searching the mailing list archive to work out exactly what I should be doing - esp as I'm using M1 for the builds. Any suggestions very gratefully received thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: How to setup log4j with different settings for main, test and developmen
I use this setup which works for me (Idea 5.1 / Maven 1.0.2) and looks like it covers what you want: Put the appropriate log4j.properties file in: 1. main/resources 2. test/resources 3. test/java (plus the relevant resource location definition in the pom for 1 2) So for me 3 always gets precedence over 1 2 when running in the IDE and 2 gets precedence over 1 when running the tests under maven. The only limitation is that if you don't do a clean before running the tests then 3 can get precedence when running the tests under maven if you've run the tests in the IDE. A fairly simple solution to this is to call file 2 maven-log4j.properties, and then in your project.properties add: maven.junit.sysproperties=log4j.configuration log4j.configuration=maven-log4j.properties Hope that helps James On 6/10/06, Jimisola Laursen [EMAIL PROTECTED] wrote: Hi! I've seen various posts on log4j and Maven, but I haven't seen any answer to what I want to do. I want to be able to use different settings for log4j for: 1. main (releases using mvn assembly) 2. tests (unit tests) 3. development (when running/debugging the program within Eclipse or outside with more extra logging) I know that I should place log4j.properties under main/resources and test/resources. This will hopefully solve 1) and 2) . However, I read something about Maven giving precedence to main/resources instead of test/resources - is that still the case? I would like to avoid a long line of system properties on the command line since they're easy to forget and especially for new develepors to get. I'd then prefer to just add one environment property (main, test, development) which can then be used throughout our Maven environment in case we have similiar situations. Any ideas? Regards, Jimisola -- View this message in context: http://www.nabble.com/How-to-setup-log4j-with-different-settings-for-m ain%2C-test-and-developmen-t1766805.html#a4808936 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mail Notifier self-replication
Thanks. As a workaround I've discovered that the notifier added from the nagEmailAddress element in the POM doesn't suffer from this replication so I've added that for this project and am ok for now. James -Original Message- From: Carlo Bonamico [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 8:31 AM To: continuum-users@maven.apache.org Subject: Re: Mail Notifier self-replication Hi Shute, I have the same problem and already created a jira bug report for this. http://jira.codehaus.org/browse/CONTINUUM-678 It should be fixed in the source tree, but I am not sure when the next release will be. Carlo Shute, James wrote: Hi, I'm using 1.0.3 and am having a problem with one of my (Maven 1) projects. Every time the build runs it adds copies of the configured Mail Notifiers, so I get an ever expanding number of emails. It looks like it's doubling each time. Other projects are building ok. The main difference with this one is that it's a multi-project build, (i.e. my target is clean:clean multiproject:install) - don't know if that's relevant or not. The other difference is that when I imported the pom the initial mail notifier it created looks slightly different to those for the other projects, in that the ones that work have the 1st notifier with a From value of Project, where as this one only has User notifiers. I can't see anything in any of the mail archives that might help - anybody got any ideas? thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Mail Notifier self-replication
Hi, I'm using 1.0.3 and am having a problem with one of my (Maven 1) projects. Every time the build runs it adds copies of the configured Mail Notifiers, so I get an ever expanding number of emails. It looks like it's doubling each time. Other projects are building ok. The main difference with this one is that it's a multi-project build, (i.e. my target is clean:clean multiproject:install) - don't know if that's relevant or not. The other difference is that when I imported the pom the initial mail notifier it created looks slightly different to those for the other projects, in that the ones that work have the 1st notifier with a From value of Project, where as this one only has User notifiers. I can't see anything in any of the mail archives that might help - anybody got any ideas? thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: Project specific build.properties for Maven1 build
Thanks Emmanuel - prompt reply as ever! I'm planning to have 2 instances of Continuum running: one on linux, one on windows so I can be sure my tests work on both platforms. Given the property in question is an absolute file path the project.properties approach won't work, but the command line idea should do nicely. thanks James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 9:37 AM To: continuum-users@maven.apache.org Subject: Re: Project specific build.properties for Maven1 build I think you can put your property in project.properties and maven1 on continuum machine will use it. For developers, the value define in their build.properties will override the value in project.properties. An other solution would be to add the property on the m1 command line via the build definition of your project. Emmanuel Shute, James a écrit : Hi, Just started using Continuum and am really liking it, but have just 1 small issue I can't seem to find an answer to. One of our projects, which is built using Maven 1, needs a machine specific property set (it's an absolute path to a specific file), so that goes in build.properties in the project dir and each developer sets it to the correct value for their box. It's potentially different on each box, hence it can't go in project.properties. Now I tried fixing our build under Continuum by adding the build.properties file with the value set into the working area, but next time a CVS update happens during the build that file gets wiped out and the build fails again. For now I've got it working by putting the setting in the system wide build.properties file, but that's not an ideal solution as this property is only really relevant to this 1 project. Is there some way round this, or shall I file a JIRA? thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Project specific build.properties for Maven1 build
Hi, Just started using Continuum and am really liking it, but have just 1 small issue I can't seem to find an answer to. One of our projects, which is built using Maven 1, needs a machine specific property set (it's an absolute path to a specific file), so that goes in build.properties in the project dir and each developer sets it to the correct value for their box. It's potentially different on each box, hence it can't go in project.properties. Now I tried fixing our build under Continuum by adding the build.properties file with the value set into the working area, but next time a CVS update happens during the build that file gets wiped out and the build fails again. For now I've got it working by putting the setting in the system wide build.properties file, but that's not an ideal solution as this property is only really relevant to this 1 project. Is there some way round this, or shall I file a JIRA? thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
[M1] Comparing properties in maven.xml
Does anybody know how I can compare 2 properties in a custom goal in my
maven.xml file?
e.g.
For a build where the properties are
java.specification.version : 1.5
maven.compile.target : 1.4
Then these steps
echo${java.specification.version ne maven.compile.target}/echo
echo${java.specification.version eq maven.compile.target}/echo
echo${java.specification.version != maven.compile.target}/echo
echo${java.specification.version == maven.compile.target}/echo
output this
[echo] false
[echo] true
[echo] false
[echo] true
which is the exact opposite of what I'd expect, as they're not the same.
In fact forcing the 2nd property to be 1.5 via the command line still
gives the same output, as do any other values I try.
Surely this must be possible? Every example I can find compares a
property to a string literal, but I can't believe I'm the 1st person to
ever want to compare 2 properties?!
thanks
James
--
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as an
offer to sell or as a solicitation of an offer to buy any financial product, an
official confirmation of any transaction, or as an official statement of Lehman
Brothers. Email transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or accurate
and it should not be relied upon as such. All information is subject to change
without notice.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1.1 gold?
Are there any plans to turn Maven 1.1b2 into 1.1 final? I'm personally quite happy to trust using a b2 version but being in a commercial organisation eyebrows are always raised when you say you're using a beta build of an open source project! thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migrating to M2 - local jar overrides
Hi, I'm experimenting with moving over to Maven 2 from 1.0.2 and have drawn a blank on what the M2 way to do local jar overrides is. The reason I particularly need to do this is we use a 3rd party library that's basically just a thin layer on top of some native (windows) libraries. For compilation I can happily put the jar in the repository, download from there and all is well. But to run the tests the jar MUST match what is installed locally on the box, which can vary from developer to developer - normally only by minor version no but that's still enough to stop it working if the wrong one is used. So when using 1.0.2 this in the project.properties did the trick nicely: maven.jar.override=on maven.jar.tibrvj=C:/Program Files/TIBCO/TIBRV/lib/tibrvj.jar Along with a dependency like this dependency groupIdtibco/groupId artifactIdtibrvj/artifactId versionlocal/version /dependency Searching through the mailing lists hasn't got me very far, other than a few statements that seem to say local overrides aren't supported under M2. Can anybody suggest a way forward? many thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrating to M2 - local jar overrides
Merci! Works a treat James -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Friday, March 24, 2006 1:39 PM To: Maven Users List Subject: Re: Migrating to M2 - local jar overrides You can use the system scope : http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Emmanuel Shute, James a écrit : Hi, I'm experimenting with moving over to Maven 2 from 1.0.2 and have drawn a blank on what the M2 way to do local jar overrides is. The reason I particularly need to do this is we use a 3rd party library that's basically just a thin layer on top of some native (windows) libraries. For compilation I can happily put the jar in the repository, download from there and all is well. But to run the tests the jar MUST match what is installed locally on the box, which can vary from developer to developer - normally only by minor version no but that's still enough to stop it working if the wrong one is used. So when using 1.0.2 this in the project.properties did the trick nicely: maven.jar.override=on maven.jar.tibrvj=C:/Program Files/TIBCO/TIBRV/lib/tibrvj.jar Along with a dependency like this dependency groupIdtibco/groupId artifactIdtibrvj/artifactId versionlocal/version /dependency Searching through the mailing lists hasn't got me very far, other than a few statements that seem to say local overrides aren't supported under M2. Can anybody suggest a way forward? many thanks James -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - 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] -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
