issue with apache-maven-3.0.4-bin.tar.gz
Hi, I have just downloaded apache-maven-3.0.4-bin.tar.gz. The particular version which I got from http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0.4-bin.tar.gz had mismatching md5sum's and gpg signatures. I ended up downloading from www.apache.org/dist. I do not know which concrete mirror was picked up by "closer.cgi" for me. My IP address is an IP address of New York city if this helps find out which mirror can have served me. Regards, Antoine - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven resources plugin exclude not working
Excludes is always a subset of includes, but since excludes matches every
include nothing is filtered.
Try it without the excludes-section
-Robert
Op Mon, 19 Mar 2012 18:38:12 +0100 schreef Al Dispennette
:
I am trying to use the resources plugin to copy files from one location
to another.
I only want certain files to be copied so I am using the include and
exclude stanzas.
It seems these are being ignored though.
Here is my configuration:
org.apache.maven.plugins
maven-resources-plugin
2.5
${user.home}/cms/conf
${basedir}/src/main/resources
**/*.properties
**/*.*
true
Am I missing something or is this a bug.
Al Dispennette
Customer Software Sustaining
Sr. Development Support Engineer
781 Lincoln Ave., Suite 200
San Rafael, CA 94901
Phone: (415) 526-7000 ext 7206
Cell: (309) 868-1401
Fax: (415) 526-7099
al.dispenne...@clairmail.com
[cid:image001.jpg@01CD05BC.62175820]
*
This email and any attachment may contain confidential, proprietary,
and/or privileged information. It is intended solely for the
recipient. If you have received this email in error or are not able or
willing to take reasonable steps to protect the information contained
herein from improper disclosure, please notify the sender immediately by
reply email and destroy all copies.
*
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency resolution problem
Wouldn't "-x" option give debug information from which the actual problem can be found and resolved? -Original Message- From: Niranjan Rao [mailto:nhr...@gmail.com] Sent: March-19-12 1:31 PM To: Maven Users List Subject: Dependency resolution problem After banging my head for half an hour, I finally figured what was wrong. I was trying to use org.xerial:sqlite-jdbc version 3.7.2 on maven 3. This jar is part of central repository and I was able to to see when I went to local nexus mirror. However maven was not "seeing" it. Any time I tried compilation, I was getting error about unable to resolve dependencies. It turned out that this artifact is dependent upon some other artifacts which come from xerial.org repository. If maven had told me about the actual missing dependencies, it would have been much easier. Was there any switch that I could have used to the name of actual missing dependency? During my tries maven only complained about dependency that was in my pom and not the transitive dependencies. I managed to fix it by adding xerial mirror to my nexus, but this can be baffling problem as error message was misleading. Regards, Niranjan - 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
Dependency resolution problem
After banging my head for half an hour, I finally figured what was wrong. I was trying to use org.xerial:sqlite-jdbc version 3.7.2 on maven 3. This jar is part of central repository and I was able to to see when I went to local nexus mirror. However maven was not "seeing" it. Any time I tried compilation, I was getting error about unable to resolve dependencies. It turned out that this artifact is dependent upon some other artifacts which come from xerial.org repository. If maven had told me about the actual missing dependencies, it would have been much easier. Was there any switch that I could have used to the name of actual missing dependency? During my tries maven only complained about dependency that was in my pom and not the transitive dependencies. I managed to fix it by adding xerial mirror to my nexus, but this can be baffling problem as error message was misleading. Regards, Niranjan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: generate-sources target called twice
I don't see anything in the output of the effective pom that uses the word "fork" What should I look for? I'm fairly new to Maven, so I don't know a lot about configuration... Here is my plugin management section: maven-antrun-plugin 1.3 maven-assembly-plugin 2.2-beta-5 maven-dependency-plugin 2.1 maven-release-plugin 2.0 maven-compiler-plugin 2.3.2 1.6 1.6 UTF-8 and my plugins (much longer): maven-antrun-plugin 1.3 delete-resources clean run maven-site-plugin 2.1 default-site site site Z:\src\6_2_main\sms\vtl-api\target\site org.apache.maven.plugins maven-project-info-reports-plugin default-deploy site-deploy deploy Z:\src\6_2_main\sms\vtl-api\target\site org.apache.maven.plugins maven-project-info-reports-plugin Z:\src\6_2_main\sms\vtl-api\target\site org.apache.maven.plugins maven-project-info-reports-plugin maven-dependency-plugin 2.1 maven-idea-plugin 2.2 1.6 maven-resources-plugin 2.4.1 default-resources process-resources resources UTF-8 default-testResources process-test-resources testResources UTF-8 UTF-8 org.bsc.maven maven-processor-plugin 2.0.5 process generate-sources process src/main/generated com.company.processors.VtlRemoteProcessor maven-clean-plugin 2.4.1 default-clean clean clean maven-install-plugin 2.3.1 default-install install install maven-surefire-plugin 2.7.2 default-test test test maven-compiler-plugin 2.3.2 default-testCompile test-compile testCompile 1.6 1.6 UTF-8 default-compile compile compile 1.6 1.6 UTF-8 1.6 1.6 UTF-8 maven-jar-plugin 2.3.1 default-jar package jar maven-deploy-plugin 2.5 default-deploy deploy deploy -- View this message in context: http://maven.40175.n5.nabble.com/generate-sources-target-called-twice-tp5577988p5578095.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: generate-sources target called twice
> I'm pretty sure that something I've done recently has caused the second > iteration, but I don't know what it could be. Any help would be > appreciated. What does "mvn help:effective-pom" tell you? Is there another plugin running that might be forking the build? (Various plugins will do this.) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
generate-sources target called twice
All, I have a problem with the generate-sources goal is being called twice and I don't know why. I have a super pom that defines the project with several sub-modules. One sub-module has this: org.bsc.maven maven-processor-plugin 2.0.5 process process generate-sources src/main/generated com.company.processors.RemoteProcessor This is calling out to my custom annotation processor to do some code generation, but it is called twice. The second time around the same file is encountered and is causing me an error. My command to start the compile is this: mvn install -Dmaven.test.skip=true I'm pretty sure that something I've done recently has caused the second iteration, but I don't know what it could be. Any help would be appreciated. Thanks, Scott -- View this message in context: http://maven.40175.n5.nabble.com/generate-sources-target-called-twice-tp5577988p5577988.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: Transitive Dependencies for Unused Artifact
Typically each project module will have a parent that the individual developer does not play with. It includes a dependency management section that specifies versions for all of the dependencies that the team cares about. The individual module projects will list their dependencies but not specify a version number on each one since that is a team decision documented in the parent. Ron On 19/03/2012 10:26 AM, Lyons, Roy wrote: You can use dependencymanagement section to define the version as a filter to any subsequent dependencies section. Putting it in dependencymanagement does not declare it as a dependency but does define the version to be used when it find the dependency declared. Sent from my Blackberry. - Original Message - From: kdobrik To: users@maven.apache.org Sent: Mon Mar 19 09:06:03 2012 Subject: Re: Transitive Dependencies for Unused Artifact Thank you for the answer. I will revisit my question. At the end of the day I need to centralize the versions used among all modules. Nevertheless these modules do not share all the jars needed. I need to refresh my Maven knowledge :) Once again thank you! -- View this message in context: http://maven.40175.n5.nabble.com/Transitive-Dependencies-for-Unused-Artifact-tp5570805p5577176.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive Dependencies for Unused Artifact
You can use dependencymanagement section to define the version as a filter to any subsequent dependencies section. Putting it in dependencymanagement does not declare it as a dependency but does define the version to be used when it find the dependency declared. Sent from my Blackberry. - Original Message - From: kdobrik To: users@maven.apache.org Sent: Mon Mar 19 09:06:03 2012 Subject: Re: Transitive Dependencies for Unused Artifact Thank you for the answer. I will revisit my question. At the end of the day I need to centralize the versions used among all modules. Nevertheless these modules do not share all the jars needed. I need to refresh my Maven knowledge :) Once again thank you! -- View this message in context: http://maven.40175.n5.nabble.com/Transitive-Dependencies-for-Unused-Artifact-tp5570805p5577176.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive Dependencies for Unused Artifact
Thank you for the answer. I will revisit my question. At the end of the day I need to centralize the versions used among all modules. Nevertheless these modules do not share all the jars needed. I need to refresh my Maven knowledge :) Once again thank you! -- View this message in context: http://maven.40175.n5.nabble.com/Transitive-Dependencies-for-Unused-Artifact-tp5570805p5577176.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: Maven 2.2.1 Checksum errors against oss.sonatype.org
I believe this is a Nexus issue as Nexus has a feature of downgrading the metadata file returned to Maven 2 clients. They *might* have overlooked the checksum impact of this. I think your best shot is to ask on the Nexus users list and/or open a issue ticket for Nexus. /Anders On Mon, Mar 19, 2012 at 12:17, Matthew Buckett wrote: > Hi, > > The Sakai project (http://sakaiproject.org) is deploying it's > artifacts against the Sonatype OSS repository and while this works > fine for Maven 3 builds anyone attempting to download the artifacts > using Maven 2.2.1 gets checksum errors against the maven-metadata.xml. > > So far it seems that Maven 2.2.1 is not downloading the maven metadata > file directly but is somehow rebuilding the information in it (or > downloading it and stripping it). It's not easy to see if maven is > requesting the file as proxying https connection is hard. As the > metadata files are then different the checksums don't match. > > It seems that the sonatype repository has a metadata file that > contains information about the additional artifacts such as the > sources and javadocs. The metadata about these artifacts isn't > supported by maven 2 and was added for maven 3. However maven 2 was > updated to ignore this extra information. > > If I perform a build with maven 3 then the metadata gets updated > correctly and the checksums all match. After I've done a good build > with maven 3 performing another build which updated the snapshot > versions (-U switch) causes maven 2 to update the maven-meta to become > bad. Attached are the metadata that is in my local .m2 repo for maven > 2 and maven 3. > > -- > Matthew Buckett > VLE Developer, LTG, Oxford University Computing Services > > > - > 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
Maven 2.2.1 Checksum errors against oss.sonatype.org
Hi, The Sakai project (http://sakaiproject.org) is deploying it's artifacts against the Sonatype OSS repository and while this works fine for Maven 3 builds anyone attempting to download the artifacts using Maven 2.2.1 gets checksum errors against the maven-metadata.xml. So far it seems that Maven 2.2.1 is not downloading the maven metadata file directly but is somehow rebuilding the information in it (or downloading it and stripping it). It's not easy to see if maven is requesting the file as proxying https connection is hard. As the metadata files are then different the checksums don't match. It seems that the sonatype repository has a metadata file that contains information about the additional artifacts such as the sources and javadocs. The metadata about these artifacts isn't supported by maven 2 and was added for maven 3. However maven 2 was updated to ignore this extra information. If I perform a build with maven 3 then the metadata gets updated correctly and the checksums all match. After I've done a good build with maven 3 performing another build which updated the snapshot versions (-U switch) causes maven 2 to update the maven-meta to become bad. Attached are the metadata that is in my local .m2 repo for maven 2 and maven 3. -- Matthew Buckett VLE Developer, LTG, Oxford University Computing Services org.sakaiproject.entitybroker entitybroker-api 1.6-SNAPSHOT 20120312.183226 13 20120312183226 org.sakaiproject.entitybroker entitybroker-api 1.6-SNAPSHOT 20120312.183226 13 20120312183226 jar 1.6-20120312.183226-13 20120312183226 pom 1.6-20120312.183226-13 20120312183226 sources jar 1.6-20120312.183226-13 20120312183226 javadoc jar 1.6-20120312.183226-13 20120312183226 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > When been over this several times on this list. You have to extract > the configuration out of the binary. You mustn't have a Maven build > that could generate different flavors of an artifact. Which one would > you deploy to the repository? Ok, this was a bit misleading by me. With "flavors" I just meant * mvn clean deploy by command or on a nightly base * mvn release:prepare release:perform final releases / pre-releases meant for an integration build and/or tests by our business department > If you can't separate the configuration out of the binary, you should > have multiple projects each one generate one of the flavors. +1 Regards Thorsten
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
> We're having lots of projects building at least one EAR, and each EAR is > deployed to the same application server(s), but in different flavors: > developer (snapshot) build, integration build and/or release build. Using > a CI server configured with special jobs doing these deployment tasks > would result in having to implement the same tasks again and again. IMHO > this is more error-prone than having a default job in a parent pom doing > that... When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > > I'm using profiles at work for the sole purpose of deciding what to do > > with the build artifact, i.e. activating different deployment targets > > (application servers) for an EAR. > > I see this as a completely different task where you're simply using > Maven as a utility tool. When using Maven as a "build tool", you will > be deploying the artifacts to a repository. What you then do with the > artifacts after that (like e.g. publish to an app server) is outside > of the build story, and should be handled as a separate task. Ok, but in that case I'm just simplifying life: We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... Regards Thorsten
