AW: OpenJPA (together with jtds) cannot find javax.persistence?
How are you adding these jars to your runtime classpath? Maven downloads them from the central repository as soon as I run maven. I did not add any external repositories, I'm using the default one. Why do I assume, that everything is included into the classpath? I've also included itext, junit and javadoc via pom.xml and these work flawlessly without any changes. My .classpath looks like this: ?xml version=1.0 encoding=UTF-8? classpath classpathentry kind=src output=target/classes path=src/main/java/ classpathentry excluding=** kind=src output=target/classes path=src/main/resources/ classpathentry kind=src output=target/test-classes path=src/test/java/ classpathentry excluding=** kind=src output=target/test-classes path=src/test/resources/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry kind=con path=org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER/ classpathentry kind=output path=target/classes/ /classpath Perhaps this helps to figure out why javax.persistence doesn't work on my project... Uli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency:tree depth
Hello all, I was wondering how the dependency:tree mojo decides how deep it should go to list dependencies? For example, in the following output, why does it stop at org.springframework:spring-core:jar:1.2.4:compile and not go deeper. There are no parameters also to configure this. (using help:describe, haven't looked at the source) Either it should have stopped at one transitive dependency deep or gone all the way. Not sure what the rationale for the 3 deep I see here is. Thanks Pankaj [INFO] [dependency:tree] [INFO] xxx:earthSearch:war:3.4-SNAPSHOT [INFO] +- xxx:service:jar:3.4-SNAPSHOT:compile [INFO] | \- xxx:dataAccess:jar:3.4-SNAPSHOT:compile [INFO] | \- xxx:common:jar:3.4-SNAPSHOT:compile [INFO] +- junit:junit:jar:3.8.1:test (scope not updated to compile) [INFO] +- com.lowagie:itext:jar:1.3.1:compile [INFO] +- org.springframework:spring:jar:1.2.4:compile [INFO] +- org.springframework:spring-aop:jar:1.2.4:compile [INFO] | +- org.springframework:spring-beans:jar:1.2.4:compile [INFO] | | \- org.springframework:spring-core:jar:1.2.4:compile [INFO] | +- aopalliance:aopalliance:jar:1.0:compile [INFO] | +- oro:oro:jar:2.0.8:compile [INFO] | +- commons-pool:commons-pool:jar:1.2:compile [INFO] | +- commons-attributes:commons-attributes-api:jar:2.1:compile [INFO] | | +- ant:ant:jar:1.5:compile [INFO] | | \- qdox:qdox:jar:1.5:compile [INFO] | +- commons-attributes:commons-attributes-compiler:jar:2.1:compile [INFO] | | \- com.sun:tools:jar:1.4.2:system [INFO] | \- com.jamonapi:jamon:jar:1.0:compile [INFO] +- cglib:cglib-nodep:jar:2.1_2:compile [INFO] +- commons-lang:commons-lang:jar:2.2:compile [INFO] +- commons-io:commons-io:jar:1.4:compile [INFO] +- commons-logging:commons-logging:jar:1.1:compile [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile [INFO] +- rome:rome:jar:0.9:compile [INFO] | \- jdom:jdom:jar:1.0:compile [INFO] +- commons-codec:commons-codec:jar:1.3:compile [INFO] +- googlebase:googlebase:jar:0.2:compile [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile [INFO] +- log4j:log4j:jar:1.2.9:compile [INFO] +- struts:struts:jar:1.2.8:compile [INFO] | +- commons-digester:commons-digester:jar:1.6:compile [INFO] | \- commons-fileupload:commons-fileupload:jar:1.0:compile [INFO] +- googlemaps:googlemaps:jar:0.98c-Modified:compile [INFO] | \- javax.servlet:jsp-api:jar:2.0:compile [INFO] +- acegisecurity:acegi-security:jar:0.9.0:compile [INFO] | +- commons-collections:commons-collections:jar:3.1:compile [INFO] | \- taglibs:standard:jar:1.0.6:compile [INFO] +- javax.servlet:servlet-api:jar:2.3:compile [INFO] +- commons-email:commons-email:jar:1.0:compile [INFO] | +- javax.mail:mail:jar:1.3.3:compile [INFO] | \- javax.activation:activation:jar:1.0.2:compile [INFO] +- castor:castor:jar:1.0M1:compile [INFO] | \- xerces:xercesImpl:jar:2.4.0:compile [INFO] +- commons-dbcp:commons-dbcp:jar:1.2.1:compile [INFO] | \- xml-apis:xml-apis:jar:1.0.b2:compile [INFO] \- quartz:quartz:jar:1.5.2:compile [INFO] -- View this message in context: http://www.nabble.com/dependency%3Atree-depth-tp20525672p20525672.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency:tree depth
On Sun, Nov 16, 2008 at 9:14 AM, Pankaj Tandon [EMAIL PROTECTED]wrote: Hello all, I was wondering how the dependency:tree mojo decides how deep it should go to list dependencies? For example, in the following output, why does it stop at org.springframework:spring-core:jar:1.2.4:compile and not go deeper. There are no parameters also to configure this. (using help:describe, haven't looked at the source) Either it should have stopped at one transitive dependency deep or gone all the way. Not sure what the rationale for the 3 deep I see here is. It goes 'all the way', but when Maven finds an artifact/group at a higher level and a lower level, it prunes the lower level dependency -- assuming the higher level is closer to importance by being closer to your project, I guess? So all the dependencies that spring-core 1.2.4 depends on (commons-collections, commons-logging, servlet) are also listed at higher levels in your POM and have been pruned from the dependency tree, which accurately reflects how Maven will retrieve the dependencies as well. - Geoffrey -- Geoffrey Wiseman
Re: dependency:tree depth
Thanks! Makes sense... Geoffrey Wiseman wrote: On Sun, Nov 16, 2008 at 9:14 AM, Pankaj Tandon [EMAIL PROTECTED]wrote: Hello all, I was wondering how the dependency:tree mojo decides how deep it should go to list dependencies? For example, in the following output, why does it stop at org.springframework:spring-core:jar:1.2.4:compile and not go deeper. There are no parameters also to configure this. (using help:describe, haven't looked at the source) Either it should have stopped at one transitive dependency deep or gone all the way. Not sure what the rationale for the 3 deep I see here is. It goes 'all the way', but when Maven finds an artifact/group at a higher level and a lower level, it prunes the lower level dependency -- assuming the higher level is closer to importance by being closer to your project, I guess? So all the dependencies that spring-core 1.2.4 depends on (commons-collections, commons-logging, servlet) are also listed at higher levels in your POM and have been pruned from the dependency tree, which accurately reflects how Maven will retrieve the dependencies as well. - Geoffrey -- Geoffrey Wiseman -- View this message in context: http://www.nabble.com/dependency%3Atree-depth-tp20525672p20528511.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven DOCCK Plugin 1.0 Released
The Maven team is pleased to announce the release of the Maven DOCCK Plugin, version 1.0 This plugin checks that a project complies with the Plugin Documentation Standard. http://maven.apache.org/plugins/maven-docck-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-docck-plugin/artifactId version1.0/version /plugin Release Notes - Maven 2.x Documentation Checker Plugin - Version 1.0 ** Bug * [MDOCCK-10] - Use proper file encoding when checking site descriptor * [MDOCCK-12] - @Override let QDOX fail for this plugin ** Improvement * [MDOCCK-11] - Add support for Velocity filtered documents * [MDOCCK-13] - Set user agent for URL verifications Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice on version conventions for parallel, multi-team development
Am I the only one with this question? stug23 wrote: My question is related to the situation where there are multiple teams working on the same project. Let's call the project 'foo-bar' For example, Team A is working on a Subversion branch called 'team-a' and Team B is working on another Subversion branch called 'team-b'. The builds are automatically deployed to a shared Maven repo via Hudson build jobs. So there is a Hudson build job watching Team A's branch and another job watching Team B's branch. Obviously the two Maven builds will need to have different versions in order to make this work so that the deployed artifacts are distinct. These build jobs are of course working with SNAPSHOT versions. So what is a good convention for this? Would something like this make sense? Team A == com.foo:foo-bar:1.0-team-a-SNAPSHOT Team B == com.foo:foo-bar:1.0-team-b-SNAPSHOT Ultimately each of the separate Teams will merge/reintegrate their work back onto the trunk. At this point they would need to clean up their versions. For example, Team A finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Some time later Team B finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Then we release from trunk as: com.foo:foo-bar:1.0 Does this make sense? Or is there a better way to handle this parallel development scenario? TIA -- View this message in context: http://www.nabble.com/Advice-on-version-conventions-for-parallel%2C-multi-team-development-tp20490312p20529587.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advice on version conventions for parallel, multi-team development
My team is about to venture into this situation, my plan is to have each team should have its own internal repo. Each team must periodically merge into the main trunk which should also has its own internal repo. We only cut a release at the main trunk. -D On Sun, Nov 16, 2008 at 12:25 PM, stug23 [EMAIL PROTECTED] wrote: Am I the only one with this question? stug23 wrote: My question is related to the situation where there are multiple teams working on the same project. Let's call the project 'foo-bar' For example, Team A is working on a Subversion branch called 'team-a' and Team B is working on another Subversion branch called 'team-b'. The builds are automatically deployed to a shared Maven repo via Hudson build jobs. So there is a Hudson build job watching Team A's branch and another job watching Team B's branch. Obviously the two Maven builds will need to have different versions in order to make this work so that the deployed artifacts are distinct. These build jobs are of course working with SNAPSHOT versions. So what is a good convention for this? Would something like this make sense? Team A == com.foo:foo-bar:1.0-team-a-SNAPSHOT Team B == com.foo:foo-bar:1.0-team-b-SNAPSHOT Ultimately each of the separate Teams will merge/reintegrate their work back onto the trunk. At this point they would need to clean up their versions. For example, Team A finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Some time later Team B finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Then we release from trunk as: com.foo:foo-bar:1.0 Does this make sense? Or is there a better way to handle this parallel development scenario? TIA -- View this message in context: http://www.nabble.com/Advice-on-version-conventions-for-parallel%2C-multi-team-development-tp20490312p20529587.html Sent from the Maven - Users mailing list archive at Nabble.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: Advice on version conventions for parallel, multi-team development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My thought as well - Hudson would have each branch (as well as trunk) using a separate repository (config option). Johan Dan Tran wrote: My team is about to venture into this situation, my plan is to have each team should have its own internal repo. Each team must periodically merge into the main trunk which should also has its own internal repo. We only cut a release at the main trunk. -D On Sun, Nov 16, 2008 at 12:25 PM, stug23 [EMAIL PROTECTED] wrote: Am I the only one with this question? stug23 wrote: My question is related to the situation where there are multiple teams working on the same project. Let's call the project 'foo-bar' For example, Team A is working on a Subversion branch called 'team-a' and Team B is working on another Subversion branch called 'team-b'. The builds are automatically deployed to a shared Maven repo via Hudson build jobs. So there is a Hudson build job watching Team A's branch and another job watching Team B's branch. Obviously the two Maven builds will need to have different versions in order to make this work so that the deployed artifacts are distinct. These build jobs are of course working with SNAPSHOT versions. So what is a good convention for this? Would something like this make sense? Team A == com.foo:foo-bar:1.0-team-a-SNAPSHOT Team B == com.foo:foo-bar:1.0-team-b-SNAPSHOT Ultimately each of the separate Teams will merge/reintegrate their work back onto the trunk. At this point they would need to clean up their versions. For example, Team A finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Some time later Team B finishes their work and reintegrates onto trunk with a final version of: com.foo:foo-bar:1.0-SNAPSHOT Then we release from trunk as: com.foo:foo-bar:1.0 Does this make sense? Or is there a better way to handle this parallel development scenario? TIA -- View this message in context: http://www.nabble.com/Advice-on-version-conventions-for-parallel%2C-multi-team-development-tp20490312p20529587.html Sent from the Maven - Users mailing list archive at Nabble.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] - -- you too? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJIJiFpHYnED7evioRAlMVAJwJ/OIYJzjwgTN9Jbyx8TqfLHmkyACeM/lT TSaOyP6F7vT+Dw95aFomAZQ= =XF8b -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to share project?
Hello all! I have several projects which share the same class library. I don't want to release that library. When I create pom file for my library I have to create parent element. After that this library is not reusable any more. If I use eclipse, for example, I would add dependency to parent project, I don't have to modify library. How to do the same in maven? Thank you, Andrey
Is this cycle dependency ridiculous?
the dom4j:1.5.2 and jaxen:1.1-beta-4, the two guys depend on each other, Is that a problem? dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.5.2/version /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1-beta-4/version /dependency the attachment is a picture describe this relationship. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding a GroovyTestCase to a maven project
I'd like to use Groovy for unit testing a maven project, but I'm not sure how to configure the project so the groovy file containing the GroovyTestCase will compile and execute. I added the groovy-all-1.5.6.jar as a dependency in the top level pom. dependency groupIdorg.codehaus.groovy/groupId artifactIdgroovy-all/artifactId version1.5.6/version scopetest/scope /dependency I also added a GroovyTestCase file to src/test/java, and of course, it did not execute. I added the file to a src/test/groovy folder and it still did not execute. Is the only way to get this to work by using the GMaven plugin? -- Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding a GroovyTestCase to a maven project
On 17/11/2008, at 1:35 PM, Ed wrote: I'd like to use Groovy for unit testing a maven project, but I'm not sure how to configure the project so the groovy file containing the GroovyTestCase will compile and execute. I added the groovy-all-1.5.6.jar as a dependency in the top level pom. dependency groupIdorg.codehaus.groovy/groupId artifactIdgroovy-all/artifactId version1.5.6/version scopetest/scope /dependency I also added a GroovyTestCase file to src/test/java, and of course, it did not execute. I added the file to a src/test/groovy folder and it still did not execute. Is the only way to get this to work by using the GMaven plugin? It would definitely be easier. -- LD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding a GroovyTestCase to a maven project
Thanks for the encouragement... What's the recipe? Seems like there's alot to do. I added a couple more dependencies for the GMaven runtime and the gmaven mojo: dependency groupIdorg.codehaus.groovy.maven/groupId artifactIdgmaven-mojo/artifactId version1.0-rc-3/version /dependency dependency groupIdorg.codehaus.groovy.maven.runtime/groupId artifactIdgmaven-runtime-default/artifactId version1.0-rc-3/version /dependency and pluginManagement plugins plugin groupIdorg.codehaus.groovy.maven/groupId artifactIdgmaven-plugin/artifactId version1.0-rc-3/version /plugin /plugins /pluginManagement In the build section I tried to install the jar file to my local repository: mvn -e install:install-file -DgroupId=org.codehaus.groovy.maven.runtime -DartifactId=gmaven-runtime-default -Dversion=1.0-rc-3 -Dpackaging=jar -Dfile=c:/Documents and Settings/eyoun/Desktop/gmaven-runtime-default-1.0-rc-3.jar mvn -e install:install-file -DgroupId=org.codehaus.groovy.maven.runtime -DartifactId=gmaven-runtime-default -Dversion=1.0-rc-3 -Dpackaging=jar -Dfile=c:/Documents and Settings/eyoun/Desktop/gmaven-runtime-default-1.0-rc-3.jar + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] com.octo.mtg: checking for updates from central-plugins [WARNING] repository metadata for: 'com.octo.mtg' could not be retrieved from repository: central-plugins due to an error: Error transferring file [INFO] Repository 'central-plugins' will be blacklisted [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'and': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Invalid task 'and': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1521) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:405) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 22 seconds [INFO] Finished at: Sun Nov 16 21:51:27 MST 2008 [INFO] Final Memory: 3M/6M [INFO] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this cycle dependency ridiculous?
On Sun, Nov 16, 2008 at 9:16 PM, sean.chen(陈思淼) [EMAIL PROTECTED]wrote: the dom4j:1.5.2 and jaxen:1.1-beta-4, the two guys depend on each other, Is that a problem? dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.5.2/version /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1-beta-4/version /dependency Jaxen's dependencies are out of whack: http://furiouspurpose.blogspot.com/2008/10/xom-and-jaxen-transitive-dependencies.html -- Geoffrey Wiseman
How to use subversion in an ant task in maven?
Hi, can anyone show me an example how to use an svn ant task in maven? where can I get the svnant library in a repository? Cheers, Kai
Re: Adding a GroovyTestCase to a maven project
On 17/11/2008, at 2:54 PM, Ed wrote: What's the recipe? Seems like there's alot to do. All I had to do was drop the following in build - plugins… plugin groupIdorg.codehaus.groovy.maven/groupId artifactIdgmaven-plugin/artifactId version1.0-rc-3/version extensionstrue/extensions executions execution goals goalgenerateStubs/goal goalcompile/goal goalgenerateTestStubs/goal goaltestCompile/goal /goals /execution /executions /plugin You can probably drop the ‘generateStubs’ and ‘compile’ executions if you only want it for testing. -- LD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this cycle dependency ridiculous?
So please use option Tag to exclude jaxen out the dependency tree, or, it will be include in all the project which depend on dom4j. 2008/11/17 Geoffrey Wiseman [EMAIL PROTECTED] On Sun, Nov 16, 2008 at 9:16 PM, sean.chen(陈思淼) [EMAIL PROTECTED] wrote: the dom4j:1.5.2 and jaxen:1.1-beta-4, the two guys depend on each other, Is that a problem? dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.5.2/version /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1-beta-4/version /dependency Jaxen's dependencies are out of whack: http://furiouspurpose.blogspot.com/2008/10/xom-and-jaxen-transitive-dependencies.html -- Geoffrey Wiseman
Re: Is this cycle dependency ridiculous?
2008/11/17 sean.chen(陈思淼) [EMAIL PROTECTED] So please use option Tag to exclude jaxen out the dependency tree, or, it will be include in all the project which depend on dom4j. Totally agreed - only, I don't control that POM, so in the meantime, all you can do is 'exclude'. - Geoffrey -- Geoffrey Wiseman
Re: Is this cycle dependency ridiculous?
the exclude Tag in the dependency Tag is are not friendly,for example, i want to exclude all the dependency import by jaxen, I must look through the jaxen pom.xml,and find all the dependencies in that pom,and use excludes Tag, why cant I just use exclude*/exclude, so it will exclude all the transitive dependency by jaxen? 2008/11/17 Geoffrey Wiseman [EMAIL PROTECTED] 2008/11/17 sean.chen(陈思淼) [EMAIL PROTECTED] So please use option Tag to exclude jaxen out the dependency tree, or, it will be include in all the project which depend on dom4j. Totally agreed - only, I don't control that POM, so in the meantime, all you can do is 'exclude'. - Geoffrey -- Geoffrey Wiseman
