Re: maven compile error message format
On Wed, Apr 11, 2012 at 4:45 PM, mike digioia mpd...@gmail.com wrote: Can anyone in the world tell me what line number and what error this compiler thinks my error is in source file ServiceDiscovery.java? /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,12] '.' expected Line 5, Column 12. /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,13] ';' expected Line 5, Column 13. /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,14] '.' expected Line 6, Column 14. /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,15] ';' expected Line 6, Column 15. The errors are telling you its expecting a . I suspect you have your imports defined incorrectly. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-install-plugin:install - naming the installed artifact
Use the groupid, artifactid, version and classifier parameters of the goal to achieve that Ji Le 10 avr. 2012 19:51, Mehul Sanghvi mehul.sang...@gmail.com a écrit : Hi, g Hi, Below is the output of the maven-install-plugin being executed. What do I have to do so that I can specify the name of the installed artifact ? If you look at line 26, the artifact got renamed to mandrage-module-rpm-1.4.0-bin.rpm and that is not the name that it should have. The name should be the same as the source. 24: [2012-04-03_18-05-16] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mandrake-module-rpm --- 25: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/pom.xml to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0.pom 26: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/target/rpm/mandrake_20120403_180515-bin/RPMS/noarch/mandrake_20120403_180515-1.4.0-20120403_180515.noarch.rpm to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0-bin.rpm 27: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/target/rpmversion.properties to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0-rpmversion.properties 28: [2012-04-03_18-05-16] [INFO] cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
ok thnak you very much. This was what I was expecting, however i could not
see what the issue was. Here are the lines in the code from line 1 on
package com.huawei.cona.android.zeroconf;
import java.io.IOException;
import jmdns-1.0;
import service-1.0;
import service.ServiceEvent;
import service.ServiceInfo;
import service.ServiceListener;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class ServiceDiscovery extends Activity {
any ideas? My pom has these exact files names in them as dependency
On Wed, Apr 11, 2012 at 12:28 AM, Barrie Treloar baerr...@gmail.com wrote:
On Wed, Apr 11, 2012 at 4:45 PM, mike digioia mpd...@gmail.com wrote:
Can anyone in the world tell me what line number and what error this
compiler thinks my error is in source file ServiceDiscovery.java?
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,12]
'.' expected
Line 5, Column 12.
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,13]
';' expected
Line 5, Column 13.
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,14]
'.' expected
Line 6, Column 14.
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,15]
';' expected
Line 6, Column 15.
The errors are telling you its expecting a .
I suspect you have your imports defined incorrectly.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: maven compile error message format
Hi, ok thnak you very much. This was what I was expecting, however i could not see what the issue was. Here are the lines in the code from line 1 on package com.huawei.cona.android.zeroconf; import java.io.IOException; import jmdns-1.0; import service-1.0; (...) Quite easy: These package names are invalid. See for example here: http://java.about.com/od/i/g/identifier.htm HTH Thorsten
Re: Re: Re: maven compile error message format
Hi, ok thnak you very much. This was what I was expecting, however i could not see what the issue was. Here are the lines in the code from line 1 on package com.huawei.cona.android.zeroconf; import java.io.IOException; import jmdns-1.0; import service-1.0; (...) Quite easy: These package names are invalid. See for example here: http://java.about.com/od/i/g/identifier.htm Or better: http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isJavaIdentifierStart%28int%29 http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isJavaIdentifierPart%28int%29 HTH Thorsten
Re: maven compile error message format
Line 5 column 12 On Wednesday, April 11, 2012 9:15:24 AM UTC+2, mpd wrote: Can anyone in the world tell me what line number and what error this compiler thinks my error is in source file ServiceDiscovery.java? /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,12] '.' expected /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,13] ';' expected /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,14] '.' expected /home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,15] ';' expected - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need to change parameters of War, when overlay.
Yes, You given correct solution to me. Thank you all. -- View this message in context: http://maven.40175.n5.nabble.com/replace-parameters-when-overlaying-in-maven-tp5626856p5632304.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OSX and Maven Compiler Plugin (tools.jar missing)
Ok guys, I sorted it out! In fact my project was using the args4j library (2.0.10), this lib had a dependency to tools.jar. As the profile solution was not working for me (guess because it was a dynamic dependency), I finally ended up with upgrading the args4j lib to 2.0.16 and everything works just fine now since args4j no more needs tools.jar. Thanks for your helps. Francois Le 10/04/12 20:46, Benson Margulies a écrit : That page tells you to only enable tools.jar when a profile is activated, and the profile is only activated when the vendor is 'Sun', and Apple != Sun, so you leave tools.jar out altogether on Apple On Tue, Apr 10, 2012 at 2:32 PM, Francois Eylf...@smaeur.eu wrote: Ok I see, you make a symbolic link on classes.jar right? I guess there is a cleaner way to achieve this with maven? Thanks, Francois Le 10/04/12 20:23, Siegfried Goeschl a écrit : Hi folks, the last time I created a link Cheers, Siegfried Goeschl On 10.04.12 19:20, Benson Margulies wrote: Apple has no tools.jar, they just load it into the regular jar. This is why the standard web page http://maven.apache.org/general.html#tools-jar-dependency has you make a profile. On Tue, Apr 10, 2012 at 1:06 PM, Anders Hammarand...@hammar.netwrote: Most likely there is a system scope dependency pointing at the locally installed tools.jar. The path is different on Windows (for example) and Mac OS. Have a look in the pom and look for that dependency. System scope dependencies are evil, /Anders On Tue, Apr 10, 2012 at 18:50, Francois Eylf...@smaeur.euwrote: Hi guys, I'm facing to a strange issue with the maven-compiler-plugin on my OSX system while the same project/pom work fine on windows and linux. For some reason the plugin tries to access the tools.jar in a directory that doesn't exist on OSX since I'm not using the Oracle JVM but the Apple one. Here is the full message : [ERROR] Failed to execute goal on project com.sma.connector.movex: Could not resolve dependencies for project com.sma.connector.movex:com.sma.connector.movex:jar:2.3.3-SNAPSHOT: Could not find artifact jdk:tools:jar:5.0 at specified path /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar -[Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project com.sma.connector.movex: Could not resolve dependencies for project com.sma.connector.movex:com.sma.connector.movex:jar:2.3.3-SNAPSHOT: Could not find artifact jdk:tools:jar:5.0 at specified path /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:196) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:108) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project com.sma.connector.movex:com.sma.connector.movex:jar:2.3.3-SNAPSHOT: Could not find artifact jdk:tools:jar:5.0 at specified path /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar at
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
I was able to compile with no problems on 2.2.1. The only pom.xml changes I had to make to get this (almost) working on 3.0.4 was to add version numbers for plugins that didn't have them specified, move plugins under reporting/reporting into build/build, and run mvn -N install on the parent pom -- although that's what I'm trying to avoid. I don't know if the issues you're running into are related, or caused by something else. Any thoughts from anyone about either Mike's issues, or mine? Thanks! On Tue, Apr 10, 2012 at 12:37 PM, mike digioia mpd...@gmail.com wrote: Hi, I just posted a similar issue I am having with the same kind of errors. Did you ever get this to compile on the 2.2.1? I have built two machines, one with 2.2.1 and the other one with 3.0.4. I have different problems with each. Main issue with 3.0.4 is it could not locate some of my dependency jars. So I copied them from the 2.2.1 release system. But still issues. The other main issue is using extension to java/javax with the jmdns.jar. So I modified the classes inside this jar to avoid the problem but still have issues. On the 2.2.1 system it does not see my jar, even though it is inside the pom and was successful with the mvn install-file command. On Tue, Apr 10, 2012 at 12:19 PM, Brain Dump braindump2...@gmail.com wrote: Hi everyone, I'm trying to upgrade my project from Maven 2.2.1 to Maven 3.0.4 but am running into problems with a dependency resolution. I spent a full day trying to research this by looking through Maven documentation and similar posts, but I'm still stuck. I posted on stackoverflow ( http://stackoverflow.com/q/10092772/1324379) but realized that this Maven User List might be a better place to ask for help. Hope that's okay, and thanks in advance for your help. My project structure is as follows: pom.xml (acme-parent) child-alpha +- pom.xml In addition, I have the following files in my own repository: http://maven.my-own-repo.com/acme/child-dep-jdk15/maven-metadata-local.xml http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.jar http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.pom child-alpha/pom.xml in turn has a profile dependency on my own acme:child-dep-jdk15, which has been separately built into a jar file and has its own .pom file specifying a parent that is the same acme-parent parent as child-alpha. Here are excerpts from the relevant files: acme-parent pom.xml: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdacme/groupId artifactIdacme-parent/artifactId nameAcme Parent Project/name version1/version packagingpom/packaging properties.../properties modules modulechild-alpha/module /modules repositories repository idacme-repo/id urlhttp://maven.my-own-repo.com/url /repository repository idcentral/id urlhttp://repo1.maven.org/maven2/url /repository /repositories pluginRepositories.../pluginRepositories build plugins.../plugins /build dependencies.../dependencies /project child-alpha pom.xml: project modelVersion4.0.0/modelVersion parent groupIdacme/groupId artifactIdacme-parent/artifactId version1/version /parent artifactIdchild-alpha/artifactId nameChild Alpha Project/name version1.0/version packagingjar/packaging scm.../scm properties.../properties build resources.../resources plugins.../plugins /build profiles profile idjdk15/id activation activeByDefaulttrue/activeByDefault jdk1.5/jdk /activation dependencies dependency groupIdacme/groupId artifactIdchild-dep-jdk15/artifactId version1.0/version /dependency /dependencies /profile /profiles dependencies.../dependencies /project child-dep-jdk15-1.0.pom: project modelVersion4.0.0/modelVersion parent groupIdacme/groupId artifactIdacme-parent/artifactId version1/version /parent groupIdacme/groupId artifactIdchild-dep-jdk15/artifactId nameAcme Child Dependency/name version1.0/version packagingjar/packaging build.../build dependencies.../dependencies /project
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Any thoughts from anyone about either Mike's issues, or mine? Can you boil it down to 5 sentences? I gave up and I'm sure everyone else did too. Sorry but that was just total information overload. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
If you add relativePath../pom.xml/relativePath Into the parent section of child-alpha, does it resolve any issue your having? Specifically with having to do mvn -N install on the parent 1st. On 11 April 2012 16:14, Brain Dump braindump2...@gmail.com wrote: I was able to compile with no problems on 2.2.1. The only pom.xml changes I had to make to get this (almost) working on 3.0.4 was to add version numbers for plugins that didn't have them specified, move plugins under reporting/reporting into build/build, and run mvn -N install on the parent pom -- although that's what I'm trying to avoid. I don't know if the issues you're running into are related, or caused by something else. Any thoughts from anyone about either Mike's issues, or mine? Thanks! On Tue, Apr 10, 2012 at 12:37 PM, mike digioia mpd...@gmail.com wrote: Hi, I just posted a similar issue I am having with the same kind of errors. Did you ever get this to compile on the 2.2.1? I have built two machines, one with 2.2.1 and the other one with 3.0.4. I have different problems with each. Main issue with 3.0.4 is it could not locate some of my dependency jars. So I copied them from the 2.2.1 release system. But still issues. The other main issue is using extension to java/javax with the jmdns.jar. So I modified the classes inside this jar to avoid the problem but still have issues. On the 2.2.1 system it does not see my jar, even though it is inside the pom and was successful with the mvn install-file command. On Tue, Apr 10, 2012 at 12:19 PM, Brain Dump braindump2...@gmail.com wrote: Hi everyone, I'm trying to upgrade my project from Maven 2.2.1 to Maven 3.0.4 but am running into problems with a dependency resolution. I spent a full day trying to research this by looking through Maven documentation and similar posts, but I'm still stuck. I posted on stackoverflow ( http://stackoverflow.com/q/10092772/1324379) but realized that this Maven User List might be a better place to ask for help. Hope that's okay, and thanks in advance for your help. My project structure is as follows: pom.xml (acme-parent) child-alpha +- pom.xml In addition, I have the following files in my own repository: http://maven.my-own-repo.com/acme/child-dep-jdk15/maven-metadata-local.xml http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.jar http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.pom child-alpha/pom.xml in turn has a profile dependency on my own acme:child-dep-jdk15, which has been separately built into a jar file and has its own .pom file specifying a parent that is the same acme-parent parent as child-alpha. Here are excerpts from the relevant files: acme-parent pom.xml: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdacme/groupId artifactIdacme-parent/artifactId nameAcme Parent Project/name version1/version packagingpom/packaging properties.../properties modules modulechild-alpha/module /modules repositories repository idacme-repo/id urlhttp://maven.my-own-repo.com/url /repository repository idcentral/id urlhttp://repo1.maven.org/maven2/url /repository /repositories pluginRepositories.../pluginRepositories build plugins.../plugins /build dependencies.../dependencies /project child-alpha pom.xml: project modelVersion4.0.0/modelVersion parent groupIdacme/groupId artifactIdacme-parent/artifactId version1/version /parent artifactIdchild-alpha/artifactId nameChild Alpha Project/name version1.0/version packagingjar/packaging scm.../scm properties.../properties build resources.../resources plugins.../plugins /build profiles profile idjdk15/id activation activeByDefaulttrue/activeByDefault jdk1.5/jdk /activation dependencies dependency groupIdacme/groupId artifactIdchild-dep-jdk15/artifactId version1.0/version /dependency /dependencies /profile /profiles dependencies.../dependencies /project child-dep-jdk15-1.0.pom: project modelVersion4.0.0/modelVersion parent groupIdacme/groupId artifactIdacme-parent/artifactId version1/version
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Or start from scratch with simple pom.xml and nothing in src, then add src and fix dependencies, build up slowly then diff the resulting pom and see what's different. On 11 April 2012 16:25, John Patrick nhoj.patr...@gmail.com wrote: If you add relativePath../pom.xml/relativePath Into the parent section of child-alpha, does it resolve any issue your having? Specifically with having to do mvn -N install on the parent 1st. On 11 April 2012 16:14, Brain Dump braindump2...@gmail.com wrote: I was able to compile with no problems on 2.2.1. The only pom.xml changes I had to make to get this (almost) working on 3.0.4 was to add version numbers for plugins that didn't have them specified, move plugins under reporting/reporting into build/build, and run mvn -N install on the parent pom -- although that's what I'm trying to avoid. I don't know if the issues you're running into are related, or caused by something else. Any thoughts from anyone about either Mike's issues, or mine? Thanks! On Tue, Apr 10, 2012 at 12:37 PM, mike digioia mpd...@gmail.com wrote: Hi, I just posted a similar issue I am having with the same kind of errors. Did you ever get this to compile on the 2.2.1? I have built two machines, one with 2.2.1 and the other one with 3.0.4. I have different problems with each. Main issue with 3.0.4 is it could not locate some of my dependency jars. So I copied them from the 2.2.1 release system. But still issues. The other main issue is using extension to java/javax with the jmdns.jar. So I modified the classes inside this jar to avoid the problem but still have issues. On the 2.2.1 system it does not see my jar, even though it is inside the pom and was successful with the mvn install-file command. On Tue, Apr 10, 2012 at 12:19 PM, Brain Dump braindump2...@gmail.com wrote: Hi everyone, I'm trying to upgrade my project from Maven 2.2.1 to Maven 3.0.4 but am running into problems with a dependency resolution. I spent a full day trying to research this by looking through Maven documentation and similar posts, but I'm still stuck. I posted on stackoverflow ( http://stackoverflow.com/q/10092772/1324379) but realized that this Maven User List might be a better place to ask for help. Hope that's okay, and thanks in advance for your help. My project structure is as follows: pom.xml (acme-parent) child-alpha +- pom.xml In addition, I have the following files in my own repository: http://maven.my-own-repo.com/acme/child-dep-jdk15/maven-metadata-local.xml http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.jar http://maven.my-own-repo.com/acme/child-dep-jdk15/1.0/child-dep-jdk15-1.0.pom child-alpha/pom.xml in turn has a profile dependency on my own acme:child-dep-jdk15, which has been separately built into a jar file and has its own .pom file specifying a parent that is the same acme-parent parent as child-alpha. Here are excerpts from the relevant files: acme-parent pom.xml: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdacme/groupId artifactIdacme-parent/artifactId nameAcme Parent Project/name version1/version packagingpom/packaging properties.../properties modules modulechild-alpha/module /modules repositories repository idacme-repo/id urlhttp://maven.my-own-repo.com/url /repository repository idcentral/id urlhttp://repo1.maven.org/maven2/url /repository /repositories pluginRepositories.../pluginRepositories build plugins.../plugins /build dependencies.../dependencies /project child-alpha pom.xml: project modelVersion4.0.0/modelVersion parent groupIdacme/groupId artifactIdacme-parent/artifactId version1/version /parent artifactIdchild-alpha/artifactId nameChild Alpha Project/name version1.0/version packagingjar/packaging scm.../scm properties.../properties build resources.../resources plugins.../plugins /build profiles profile idjdk15/id activation activeByDefaulttrue/activeByDefault jdk1.5/jdk /activation dependencies dependency groupIdacme/groupId artifactIdchild-dep-jdk15/artifactId version1.0/version /dependency /dependencies /profile /profiles
Error: Could not resolve dependencies for project from local repository because of _maven.repositories
Hi, My situation is not really unusual. I have a workaround for it, but I'm trying to see if there are any other options, ones that fit with Maven but don't require me to install a repository manager on my home PC. :) I zipped up a copy of a project from work, and my maven repository, and set it up on my home computer. However, I'm getting these messages about Maven not being able to find the dependencies. Non-resolvable parent POM: The repository system is offline but the artifact [corporate pom details] is not available in the local repository. and 'parent.relativePath' points at wrong local POM At first I just manually installed the corporate POM, but then it led to more errors about other dependencies not being found. Dependencies that were present in my repository. Now I know it's related to the repository indicated in _maven.repositories file (it's referring to the ID of my work repo). The quick fix is to just do cd ~/.m2 find . -name '_maven.repositories' -type f -delete Is there any other recommended way to deal with this situation? Using the -o parameter for offline didn't work, even using Maven 3.0.4. Is there somewhere that I could tell Maven to just treat the local repository as the corporate repo named in _maven.repositories? This is covering some issues last discussed here, in Maven 3, _maven.repositories and *lastUpdated http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html And a related issue: http://jira.codehaus.org/browse/MNG-5185 Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No overwrite
I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Hey -- sorry about the information overload. I've seen other posts on other forums where people posted too little information and were asked to post their source code or run something on full debug, etc., so I tried to be complete. Didn't mean to overwhelm, and thanks for the responses. Simply said, the dependency child-dep-jdk15 was handled without a problem in Maven 2.2.1 but its presence causes Maven 3.0.4 to look for the parent POM in remote repositories. Both child-alpha and child-dep-jdk15 have the same parent. The dependency child-dep-jdk15 was separately compiled and available on our own remote repository. I did try adding relativePath../pom.xml/relativePath to the parent section of child-alpha, and that had no effect. The only two things that I've managed to do to get the build to succeed is to (1) remove the dependency listed within profiles/profiles of child-alpha, or (2) first run mvn -N install on the parent first. So it seems that the presence of the dependency is what's causing the problem, but I don't understand why. (I haven't tried starting from scratch yet.) Neither option above is okay because I need that dependency, and running mvn -N install would be complicated for branching and our continuous integration server. *From: *Wayne Fay wayne...@gmail.com *To: *Maven Users List users@maven.apache.org *Sent: *Wednesday, April 11, 2012 8:21:44 AM *Subject: *Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4 Any thoughts from anyone about either Mike's issues, or mine? Can you boil it down to 5 sentences? I gave up and I'm sure everyone else did too. Sorry but that was just total information overload. Wayne On Wed, Apr 11, 2012 at 8:27 AM, John Patrick nhoj.patr...@gmail.comwrote: Or start from scratch with simple pom.xml and nothing in src, then add src and fix dependencies, build up slowly then diff the resulting pom and see what's different. On 11 April 2012 16:25, John Patrick nhoj.patr...@gmail.com wrote: If you add relativePath../pom.xml/relativePath Into the parent section of child-alpha, does it resolve any issue your having? Specifically with having to do mvn -N install on the parent 1st.
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
I've managed to do to get the build to succeed is to (1) remove the dependency listed within profiles/profiles of child-alpha, or (2) first For a ton of reasons, including a dependency in a profile is a really terrible thing to do. The very first thing I would do would be to remove it. In fact, I'd do everything I could to remove the use of profiles from your build entirely. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Just to see if it would work, I moved the child-dep-jdk15 dependency out of profiles and moved it into dependencies/dependencies (outside of profiles). It still fails with the same stack trace. Any idea why? I can get the build to pass if I leave out that dependency altogether, but that's not really an option without significant code rewriting. I'm also curious about why including a dependency in a profile is not a good idea (as is using profiles at all). I'm working on a large codebase and would need to explain to the rest of the team before making such changes. Where can I read up on best practices about this? On Wed, Apr 11, 2012 at 1:29 PM, Wayne Fay wayne...@gmail.com wrote: I've managed to do to get the build to succeed is to (1) remove the dependency listed within profiles/profiles of child-alpha, or (2) first For a ton of reasons, including a dependency in a profile is a really terrible thing to do. The very first thing I would do would be to remove it. In fact, I'd do everything I could to remove the use of profiles from your build entirely. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Brian, You can find detail in the manual - What do we mean by different build environments? Two example build environments are production and devel- opment. When you are working in a development environment, your system might be configured to read from a development database instance running on your local machine while in production, your system is configured to read from the production database. Maven allows you to define any number of build environments (build profiles) which can override any of the settings in the pom.xml. You could configure your application to read from your local, development instance of a database in your development profile, and you can configure it to read from the production database in the production profile. Profiles can also be activated by the environment and platform, you can customize a build to run differently depending the Operating System or the installed JDK version. Before we talk about using and configuring Maven profiles, we need to define the concept of Build Portability. * I don't see anything wrong with their use to fix the many current issues with using this system in very different industry/commercial settings On Wed, Apr 11, 2012 at 2:48 PM, Brain Dump braindump2...@gmail.com wrote: Just to see if it would work, I moved the child-dep-jdk15 dependency out of profiles and moved it into dependencies/dependencies (outside of profiles). It still fails with the same stack trace. Any idea why? I can get the build to pass if I leave out that dependency altogether, but that's not really an option without significant code rewriting. I'm also curious about why including a dependency in a profile is not a good idea (as is using profiles at all). I'm working on a large codebase and would need to explain to the rest of the team before making such changes. Where can I read up on best practices about this? On Wed, Apr 11, 2012 at 1:29 PM, Wayne Fay wayne...@gmail.com wrote: I've managed to do to get the build to succeed is to (1) remove the dependency listed within profiles/profiles of child-alpha, or (2) first For a ton of reasons, including a dependency in a profile is a really terrible thing to do. The very first thing I would do would be to remove it. In fact, I'd do everything I could to remove the use of profiles from your build entirely. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
Hi Barrie,
Sorry to take anymore of your time up. But I have not had any success with
all the changes I have made to correct this problem. Based on your
recommendation I suspect it is a mismatch in what I have in my code and in
my pom/environment. I used mvn install to add jar files that I created
manually (Old one was changed today to this in an attempt to correct it)
Like this-
conalab@ching-jen-laptop:~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$
mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar
-DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar
-DgeneratePom=true
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'install'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [install:install-file] (aggregator-style)
[INFO]
[INFO] [install:install-file {execution: default-cli}]
[INFO] Installing
/home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar
to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new.jar
[INFO] Installing
/home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar
to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new-sources.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Wed Apr 11 14:10:43 PDT 2012
[INFO] Final Memory: 4M/80M
[INFO]
*
As you can see this created new jar/pom files in my local repository. Then
I also changed the source file using these new jars. The main issue that
seem to cause my problem before was the use of jmdns-1.0.jar where the
1.0 in the name did not seem to be recommended in the write up about syntax
used for packages in java. So this time I don't have any numbers. But I do
have jmdns-new.tar for my new jar. The local (in repository) pom gets
automatically created as this-
groupIdsrc.service/groupId
artifactIdservice/artifactId
versionnew/version
descriptionPOM was created from install:install-file/description
I also added this to my project pom (did same thing last time) as this -
/dependency
dependency
groupIdsrc.service/groupId
artifactIdservice/artifactId
versionnew/version
scopesystem/scope
systemPath/home/conalab/.m2/repository/src/service/service/new/service-new.jar/systemPath
But in the code I have attempted to import them without any success and get
the same dumb error messages. Here is the source file section -
package com.huawei.cona.android.zeroconf;
import java.io.IOException;
import jmdns-new;
import service-new;
import service.ServiceEvent;
import service.ServiceInfo;
import service.ServiceListener;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
Error messages seem to complain about the -new now instead of the 1.0
like last time.
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,12]
'.' expected
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,13]
';' expected
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,14]
'.' expected
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[6,15]
';' expected
**
So I have attempted to change the way the two import statement are but
nothing makes it work.
Do you (or anyone else) see something basic that is still not correct?
By the way. nothing like this should take this long to fix without
suspecting the basic system is just broken, since not enough information is
know about the internals of Maven. The manual has not helped. Not enough
time to study the code.
/mpd
On Wed, Apr 11, 2012 at 12:28 AM, Barrie Treloar baerr...@gmail.com wrote:
On Wed, Apr 11, 2012 at 4:45 PM, mike digioia mpd...@gmail.com wrote:
Can anyone in the world tell me what line number and what error this
compiler thinks my error is in source file ServiceDiscovery.java?
Re: No overwrite
Sorry but I looked at this- *8 You're describing the two possible solutions. Either bump the version on all artifacts produced, or just deploy the artifact that has changed (with a new version number). Which way to go depends on My comment was this first option should not exists, unless you are just testing in your local sandbox. On Wed, Apr 11, 2012 at 12:58 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: maven compile error message format
On Thu, Apr 12, 2012 at 8:22 AM, mike digioia mpd...@gmail.com wrote: Hi Barrie, Sorry to take anymore of your time up. But I have not had any success with all the changes I have made to correct this problem. Based on your recommendation I suspect it is a mismatch in what I have in my code and in my pom/environment. I used mvn install to add jar files that I created manually (Old one was changed today to this in an attempt to correct it) Like this- conalab@ching-jen-laptop:~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$ mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar -DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar -DgeneratePom=true [del] [INFO] Installing /home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new-sources.jar [del] As you can see this created new jar/pom files in my local repository. Then I also changed the source file using these new jars. The main issue that seem to cause my problem before was the use of jmdns-1.0.jar where the 1.0 in the name did not seem to be recommended in the write up about syntax used for packages in java. So this time I don't have any numbers. But I do have jmdns-new.tar for my new jar. The local (in repository) pom gets automatically created as this- groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version descriptionPOM was created from install:install-file/description I also added this to my project pom (did same thing last time) as this - /dependency dependency groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version scopesystem/scope systemPath/home/conalab/.m2/repository/src/service/service/new/service-new.jar/systemPath [del] package com.huawei.cona.android.zeroconf; import java.io.IOException; import jmdns-new; import service-new; [del] I'm sorry, the short and blunt answer is you need to go on a Java course. Start with http://docs.oracle.com/javase/tutorial Plus other replies have also provided other links you might find useful. You are misunderstanding the fundamentals of programming in Java and mixing up java archives (*.jar files) with java packages (the stuff you import). There is just way to much knowledge missing for people on this list to help you out. Once you have a solid foundation in Java, I recommend you read the freely available books on Maven at http://maven.apache.org/articles.html This will help you understand what are good values for version, what is the purpose of scope, why should avoid the use of scopesystem/scope. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No overwrite
True .. but the issue is how to restrict it from happening when it comes to formal builds. -Raj On Wed, Apr 11, 2012 at 4:03 PM, mike digioia mpd...@gmail.com wrote: Sorry but I looked at this- *8 You're describing the two possible solutions. Either bump the version on all artifacts produced, or just deploy the artifact that has changed (with a new version number). Which way to go depends on My comment was this first option should not exists, unless you are just testing in your local sandbox. On Wed, Apr 11, 2012 at 12:58 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: maven compile error message format
Thanks I see you don't know what the issue is either. This is not a java programming issue. It is a maven issue. I have been living with the maven manual for a week. But that has not been much time considering what they built. On Wed, Apr 11, 2012 at 4:25 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Apr 12, 2012 at 8:22 AM, mike digioia mpd...@gmail.com wrote: Hi Barrie, Sorry to take anymore of your time up. But I have not had any success with all the changes I have made to correct this problem. Based on your recommendation I suspect it is a mismatch in what I have in my code and in my pom/environment. I used mvn install to add jar files that I created manually (Old one was changed today to this in an attempt to correct it) Like this- conalab@ching-jen-laptop :~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$ mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar -DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar -DgeneratePom=true [del] [INFO] Installing /home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new-sources.jar [del] As you can see this created new jar/pom files in my local repository. Then I also changed the source file using these new jars. The main issue that seem to cause my problem before was the use of jmdns-1.0.jar where the 1.0 in the name did not seem to be recommended in the write up about syntax used for packages in java. So this time I don't have any numbers. But I do have jmdns-new.tar for my new jar. The local (in repository) pom gets automatically created as this- groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version descriptionPOM was created from install:install-file/description I also added this to my project pom (did same thing last time) as this - /dependency dependency groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version scopesystem/scope systemPath/home/conalab/.m2/repository/src/service/service/new/service-new.jar/systemPath [del] package com.huawei.cona.android.zeroconf; import java.io.IOException; import jmdns-new; import service-new; [del] I'm sorry, the short and blunt answer is you need to go on a Java course. Start with http://docs.oracle.com/javase/tutorial Plus other replies have also provided other links you might find useful. You are misunderstanding the fundamentals of programming in Java and mixing up java archives (*.jar files) with java packages (the stuff you import). There is just way to much knowledge missing for people on this list to help you out. Once you have a solid foundation in Java, I recommend you read the freely available books on Maven at http://maven.apache.org/articles.html This will help you understand what are good values for version, what is the purpose of scope, why should avoid the use of scopesystem/scope. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No overwrite
yes that is a much harder question and solution! On Wed, Apr 11, 2012 at 4:38 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: True .. but the issue is how to restrict it from happening when it comes to formal builds. -Raj On Wed, Apr 11, 2012 at 4:03 PM, mike digioia mpd...@gmail.com wrote: Sorry but I looked at this- *8 You're describing the two possible solutions. Either bump the version on all artifacts produced, or just deploy the artifact that has changed (with a new version number). Which way to go depends on My comment was this first option should not exists, unless you are just testing in your local sandbox. On Wed, Apr 11, 2012 at 12:58 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: I think suggestion is not to bump version of all the artifacts. And also Ron explained the approach they took to manage diff artifact version ( if u understood it correctly ). -Raj On Mon, Apr 9, 2012 at 12:57 PM, mike digioia mpd...@gmail.com wrote: Hi Maybe I don't understand the recommendation here! One should never change/bump the rev number of anything that has not changed, including artifacts, especially if they are known elsewhere with the original rev. If use cases require this, then it is broken. On Sat, Apr 7, 2012 at 10:27 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Here is a dev scenario : We are using maven 3 + artifactory + microst TFS server We dont want to over write an existing version of an artifact in our company repo , so the the consumers of artifacts should not be surprised all the sudden when producers update artifact. Now this can simply be done by removing delete permissions in artifactory but then that causes another problem. In multi module maven project if one module changes then either dev need to modify version on all artifacts ( which doesnt make sense ) or then need to modify individual pom and publish only the artifact that is changes * which again is not manageable ) So need some advice on how this can be handled ? I have couple of thoughts : - Before running mvn command , write some thing custom to go through all pom's and query artifactory is version of artifact exist. if yes then dont compile. Basically compile only artifacts who version doesnt exist in artifactory using mvn -pl - Try Jenkins , I know jenkins is aware of modules in project , but not sure if it intelligent enough to compile only those which are changed ? Please advice -Raj
Re: maven compile error message format
On Thu, Apr 12, 2012 at 9:12 AM, mike digioia mpd...@gmail.com wrote: Thanks I see you don't know what the issue is either. This is not a java programming issue. It is a maven issue. I have been living with the maven manual for a week. But that has not been much time considering what they built. [del] As others have pointed out your problem is here: import jmdns-new; import service-new; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: DependencyResolutionException when upgrading from Maven 2.2.1 to Maven 3.0.4
Profiles per-se are “ok” Adding dependencies in a profile is not. The problem is when do those profiles get activated, and hence when will the dependencies get pulled in. When people have profiles activated by the presence of a file, and then that pom is resolved from the local repo and not from the checkout... then the file will not be in ~/.m2/repository/.../.../.../ so the profile will not be activated, and hence the dependency is lost. When people have profiles activated by the presence of a system property, and then the pom is resolved by a different build where the system property is not defined, the dependency will go missing. When people have profiles activated by a specific OS or JDK and then you build e.g. a WAR file that depends on it with one JDK, then the WAR file will only work for that JDK. Every time somebody tries adding a dependency via a profile, it comes back to shoot a downstream consumer of the pom in the ass. It was a mistake to allow (transitive scoped) dependencies in profiles in the first place. BTW a similar sin is using properties to define dependency coordinates and using profiles to change those properties. I suspect non-transitive dependencies (i.e. scope=test or provided) in profiles *might* have one or two valid use cases... but you would *REALLY* need to be sure you knew what exactly you were doing and why, and I would fight tooth and nail to avoid needing to go down that road. -Stephen On 11 April 2012 23:22, mike digioia mpd...@gmail.com wrote: Brian, You can find detail in the manual - What do we mean by different build environments? Two example build environments are production and devel- opment. When you are working in a development environment, your system might be configured to read from a development database instance running on your local machine while in production, your system is configured to read from the production database. Maven allows you to define any number of build environments (build profiles) which can override any of the settings in the pom.xml. You could configure your application to read from your local, development instance of a database in your development profile, and you can configure it to read from the production database in the production profile. Profiles can also be activated by the environment and platform, you can customize a build to run differently depending the Operating System or the installed JDK version. Before we talk about using and configuring Maven profiles, we need to define the concept of Build Portability. * I don't see anything wrong with their use to fix the many current issues with using this system in very different industry/commercial settings On Wed, Apr 11, 2012 at 2:48 PM, Brain Dump braindump2...@gmail.com wrote: Just to see if it would work, I moved the child-dep-jdk15 dependency out of profiles and moved it into dependencies/dependencies (outside of profiles). It still fails with the same stack trace. Any idea why? I can get the build to pass if I leave out that dependency altogether, but that's not really an option without significant code rewriting. I'm also curious about why including a dependency in a profile is not a good idea (as is using profiles at all). I'm working on a large codebase and would need to explain to the rest of the team before making such changes. Where can I read up on best practices about this? On Wed, Apr 11, 2012 at 1:29 PM, Wayne Fay wayne...@gmail.com wrote: I've managed to do to get the build to succeed is to (1) remove the dependency listed within profiles/profiles of child-alpha, or (2) first For a ton of reasons, including a dependency in a profile is a really terrible thing to do. The very first thing I would do would be to remove it. In fact, I'd do everything I could to remove the use of profiles from your build entirely. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
Oh we all know what the issue is. Hint: You don't know what a valid package name is and you don't understand some basic concepts of Java. Trust us, this *is* a java programming issue. This is *not* a maven issue. On 12 April 2012 00:42, mike digioia mpd...@gmail.com wrote: Thanks I see you don't know what the issue is either. This is not a java programming issue. It is a maven issue. I have been living with the maven manual for a week. But that has not been much time considering what they built. On Wed, Apr 11, 2012 at 4:25 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Apr 12, 2012 at 8:22 AM, mike digioia mpd...@gmail.com wrote: Hi Barrie, Sorry to take anymore of your time up. But I have not had any success with all the changes I have made to correct this problem. Based on your recommendation I suspect it is a mismatch in what I have in my code and in my pom/environment. I used mvn install to add jar files that I created manually (Old one was changed today to this in an attempt to correct it) Like this- conalab@ching-jen-laptop :~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$ mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar -DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar -DgeneratePom=true [del] [INFO] Installing /home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new-sources.jar [del] As you can see this created new jar/pom files in my local repository. Then I also changed the source file using these new jars. The main issue that seem to cause my problem before was the use of jmdns-1.0.jar where the 1.0 in the name did not seem to be recommended in the write up about syntax used for packages in java. So this time I don't have any numbers. But I do have jmdns-new.tar for my new jar. The local (in repository) pom gets automatically created as this- groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version descriptionPOM was created from install:install-file/description I also added this to my project pom (did same thing last time) as this - /dependency dependency groupIdsrc.service/groupId artifactIdservice/artifactId versionnew/version scopesystem/scope systemPath/home/conalab/.m2/repository/src/service/service/new/service-new.jar/systemPath [del] package com.huawei.cona.android.zeroconf; import java.io.IOException; import jmdns-new; import service-new; [del] I'm sorry, the short and blunt answer is you need to go on a Java course. Start with http://docs.oracle.com/javase/tutorial Plus other replies have also provided other links you might find useful. You are misunderstanding the fundamentals of programming in Java and mixing up java archives (*.jar files) with java packages (the stuff you import). There is just way to much knowledge missing for people on this list to help you out. Once you have a solid foundation in Java, I recommend you read the freely available books on Maven at http://maven.apache.org/articles.html This will help you understand what are good values for version, what is the purpose of scope, why should avoid the use of scopesystem/scope. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
I read in my morning mail that you were told how to fix this.
import com.huawei.cona.android.jmdns-new;
The compiler is not even looking at your maven dependencies.
It is telling you that you have a syntax error. jmdns-new is not a legal syntax
for a class name in an import statement since it is missing the package part of
the class name.
It can not even figure out what you want to import so it does not care what you
have as dependencies in Maven.
Follow Barrie's advice and read up on Java packages.
http://en.wikipedia.org/wiki/Java_package is a start.
Once you have a line without a syntax error, you will get into Maven.
Barrie's advice about reading up on Maven to understand dependencies and the
structure of the GAV (GroupId, ArtifactId, Version)
dependency
groupIdcom.huawei.cona.android/groupId
artifactIdjmdns-new/artifactId
version1.0/version
scopecompile/scope
/dependency
or
dependency
groupIdcom.huawei.cona/groupId
artifactIdandroid-jmdns-new/artifactId
version1.0/version
scopecompile/scope
/dependency
Ron
On 11/04/2012 6:52 PM, mike digioia wrote:
Hi Barrie,
Sorry to take anymore of your time up. But I have not had any success with
all the changes I have made to correct this problem. Based on your
recommendation I suspect it is a mismatch in what I have in my code and in
my pom/environment. I used mvn install to add jar files that I created
manually (Old one was changed today to this in an attempt to correct it)
Like this-
conalab@ching-jen-laptop:~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$
mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar
-DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar
-DgeneratePom=true
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'install'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [install:install-file] (aggregator-style)
[INFO]
[INFO] [install:install-file {execution: default-cli}]
[INFO] Installing
/home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar
to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new.jar
[INFO] Installing
/home/conalab/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0/src.jmdns.jar
to /home/conalab/.m2/repository/src/jmdns/jmdns/new/jmdns-new-sources.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Wed Apr 11 14:10:43 PDT 2012
[INFO] Final Memory: 4M/80M
[INFO]
*
As you can see this created new jar/pom files in my local repository. Then
I also changed the source file using these new jars. The main issue that
seem to cause my problem before was the use of jmdns-1.0.jar where the
1.0 in the name did not seem to be recommended in the write up about syntax
used for packages in java. So this time I don't have any numbers. But I do
have jmdns-new.tar for my new jar. The local (in repository) pom gets
automatically created as this-
groupIdsrc.service/groupId
artifactIdservice/artifactId
versionnew/version
descriptionPOM was created from install:install-file/description
I also added this to my project pom (did same thing last time) as this -
/dependency
dependency
groupIdsrc.service/groupId
artifactIdservice/artifactId
versionnew/version
scopesystem/scope
systemPath/home/conalab/.m2/repository/src/service/service/new/service-new.jar/systemPath
But in the code I have attempted to import them without any success and get
the same dumb error messages. Here is the source file section -
package com.huawei.cona.android.zeroconf;
import java.io.IOException;
import jmdns-new;
import service-new;
import service.ServiceEvent;
import service.ServiceInfo;
import service.ServiceListener;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
Error messages seem to complain about the -new now instead of the 1.0
like last time.
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,12]
'.' expected
/home/conalab/MikesNewAndroidWork/workspace3/jxwhiteboard_ccn_gohuawei_dist/trunk/src/com/huawei/cona/android/zeroconf/ServiceDiscovery.java:[5,13]
';' expected
antrun cannot run junit task
I am converting a convoluted ant build to maven. It has a large number of functional tests, mostly built on either TestNG or the now-deceased author's private framework, but some on junit. I am running the tests via the antrun plugin, but it when it hits a junit task, it fails with: Could not load class (org.apache.tools.ant.taskdefs.optional.junit.JunitTask) for type junit I have confirmed that the ant-junit jar is in the classpath (although I'd have expected all ant task jars to be there automatically). What do I need to do to get this to work? And no, I cannot simply move these tests to let maven run them normally - the test build is a horrible mess. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
conalab@ching-jen-laptop:~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$ mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar -DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar -DgeneratePom=true You have already been sufficiently razed over the real issue regarding your import statements. I won't pile on but assume that you will review your Java 101 documentation. I do want to point out (for you and anyone else who sees this thread in the future) that it is highly unlikely that you want to use the same jar for sources and binary. This is what your install-file command above is doing. In general, I'd expect to see a binary jar (eg jmdns.jar) and a sources jar (eg jmdns-src.jar). You would specify the binary file with -Dfile and the source file with -Dsources. In fact, I'd go so far as to strongly encourage you to NOT use a sources jar (or a binary jar that packs the sources along with the compiled binaries) as if it was a binary jar. Compilers will do funky things when they run into Java source code in binary jars -- we've seen several complaints from people doing GWT work on this list where their compilers were giving odd error messages that were related to the source files in their binary jars. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: antrun cannot run junit task
Could not load class (org.apache.tools.ant.taskdefs.optional.junit. JunitTask) for type junit I have confirmed that the ant-junit jar is in the classpath (although I'd have expected all ant task jars to be there automatically). What do I need to do to get this to work? And no, I cannot simply move Being on the classpath is not necessarily sufficient. Did you simply declare this as a dependency (scope=test) in the project? Or did you add it to the PLUGIN classpath via plugindependenciesdependency which is what is required for this to work? More here: http://maven.40175.n5.nabble.com/running-optional-ant-tasks-with-maven-antrun-plugin-td105083.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Missing key cacheFile, checkstyle plugin, custom check class
Disclaimer: I don't use Checkstyle as a primary component in my builds.
property name=cacheFile value=${checkstyle.cache.file}/
property name=cacheFile value=${cacheFile}/
Did you try leaving cacheFile out entirely? Did you try setting
value=? Samples at the Checkstyle site show
value=target/cachefile, did you try that?
not sure why the plugin is complaining about it. Appreciate any thoughts
before I opt for looking into the plugin source code.
...
Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: missing
key 'cacheFile' in TreeWalker
at
com.puppycrawl.tools.checkstyle.DefaultConfiguration.getAttribute(DefaultConfiguration.java:74)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:270)
I doubt looking at the Maven checkstyle plugin source code will be
much help. The stacktrace shows a root cause in
com.puppycrawl.tools.checkstyle which I assume is part of Checkstyle
itself. And I further assume the plugin simply calls out to Checkstyle
and provides configuration etc so it can run properly (which is how
most plugins work, thin wrappers around a larger codebase to integrate
the tool into Maven's build process).
If you're looking at any source code, look at the Checkstyle source
itself specifically DefaultConfiguration.getAttribute() line 74. (But
you'll need to figure out which version of the binary is being used.)
You probably need to take this email over to the Checkstyle support
channels directly since their code is throwing this exception, not
Maven and not the plugin.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: antrun cannot run junit task
Aha! Thank you! I searched the antrun plugin docs for info, but it's not there. What would it take for this to be added as a FAQ? It seems other people have been running into the same problem. On Apr 11, 2012, at 10:37 PM, Wayne Fay wrote: Could not load class (org.apache.tools.ant.taskdefs.optional.junit. JunitTask) for type junit I have confirmed that the ant-junit jar is in the classpath (although I'd have expected all ant task jars to be there automatically). What do I need to do to get this to work? And no, I cannot simply move Being on the classpath is not necessarily sufficient. Did you simply declare this as a dependency (scope=test) in the project? Or did you add it to the PLUGIN classpath via plugindependenciesdependency which is what is required for this to work? More here: http://maven.40175.n5.nabble.com/running-optional-ant-tasks-with-maven-antrun-plugin-td105083.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: antrun cannot run junit task
Aha! Thank you! I searched the antrun plugin docs for info, but it's not there. What would it take for this to be added as a FAQ? It seems other people have been running into the same problem. I hate to say RTFM but it is appropriate in this case... http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Missing key cacheFile, checkstyle plugin, custom check class
On Thu, Apr 12, 2012 at 12:29 PM, Wayne Fay wayne...@gmail.com wrote:
Disclaimer: I don't use Checkstyle as a primary component in my builds.
property name=cacheFile value=${checkstyle.cache.file}/
property name=cacheFile value=${cacheFile}/
Did you try leaving cacheFile out entirely? Did you try setting
value=? Samples at the Checkstyle site show
value=target/cachefile, did you try that?
Are you running into http://jira.codehaus.org/browse/MCHECKSTYLE-159?
While I use Checkstyle, I have never set cacheFile myself and not sure
why you would.
In order to use the magic of property expansion, i.e. ${}, you need to
add a configuration section to the checkstyle plugin as documented in
the above JIRA, and define the key/vale pair for the expansion.
BEWARE: the comments in the Jira have a typo for the expansion, which
someone notes in a sub-comment.
Are you using the latest version of the checkstyle plugin?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven compile error message format
Thanks Wayne, That is the reason for my two jars, one is source and the other binary. However, this statement does not make sense in all cases, since one can create self-running JAR files with mainclass.mf manifest file to run the program with java -jar myProgram.jar. This may include both binary and source. On Wed, Apr 11, 2012 at 7:30 PM, Wayne Fay wayne...@gmail.com wrote: conalab@ching-jen-laptop :~/.m2/repository/com/huawei/cona/android/zeroconf/jmdns/1.0$ mvn install:install-file -Dfile=src.jmdns.jar -Dsources=src.jmdns.jar -DgroupId=src.jmdns -DartifactId=jmdns -Dversion=new -Dpackaging=jar -DgeneratePom=true You have already been sufficiently razed over the real issue regarding your import statements. I won't pile on but assume that you will review your Java 101 documentation. I do want to point out (for you and anyone else who sees this thread in the future) that it is highly unlikely that you want to use the same jar for sources and binary. This is what your install-file command above is doing. In general, I'd expect to see a binary jar (eg jmdns.jar) and a sources jar (eg jmdns-src.jar). You would specify the binary file with -Dfile and the source file with -Dsources. In fact, I'd go so far as to strongly encourage you to NOT use a sources jar (or a binary jar that packs the sources along with the compiled binaries) as if it was a binary jar. Compilers will do funky things when they run into Java source code in binary jars -- we've seen several complaints from people doing GWT work on this list where their compilers were giving odd error messages that were related to the source files in their binary jars. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
