[ANN] Maven Plugin Plugin 3.1 Released
The Maven team is pleased to announce the release of the Maven Plugin Plugin, version 3.1. This version fixes mostly the support of Java annotations for Maven plugins ( http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using- annotations.html ) The Maven Plugin Plugin is used to create a Maven plugin descriptor for any Mojo's found in the source tree, to include in the JAR. It is also used to generate report files for the Mojos as well as for updating the plugin registry, the artifact metadata and generating a generic help goal. http://maven.apache.org/plugin-tools/maven-plugin-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId version3.1/version /plugin Release Notes - Maven 2.x Plugin Tools - Version 3.1 ** Bug * [MPLUGIN-208] - HelpMojo class generated by helpmojo goal uses deprecated annotations * [MPLUGIN-210] - NPE in generated help mojo with M2 when no goal has description * [MPLUGIN-213] - NullPointerException in descriptor goal * [MPLUGIN-214] - generated descriptor for Maven object components is not like previous versions * [MPLUGIN-215] - role-hint and configuration generated with empty values * [MPLUGIN-216] - default dependency resolution set to RUNTIME * [MPLUGIN-217] - HelpMojo (always) contains description for the maven- plugin-plugin * [MPLUGIN-218] - Tag 'since' not recognized in the plugin model ** Task * [MPLUGIN-209] - use maven-plugin-tools' java 5 annotations Have Fun, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reactor build changes in module recompilation of dependent modules
Hi Wayne, The app version is '1.0-SNAPSHOT'. The Maven is: $ mvn --version Apache Maven 3.0.3 (r1075438; 2011-02-28 19:31:09+0200) Maven home: /opt/maven Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: /opt/jdk1.6.0_29/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.2.0-25-generic, arch: amd64, family: unix Below are the POMs which I use to reproduce the issue. Directory structure: pom.xml [root pom, the builds were run in this dir] | +-api [module of an interface] | | | +pom.xml | +-impl [module of an implementation] | +pom.xml The root POM: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIda.b.c/groupId artifactIdfoo/artifactId packagingpom/packaging version1.0-SNAPSHOT/version modules moduleapi/module moduleimpl/module /modules build pluginManagement plugins plugin artifactIdmaven-clean-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.5/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version configuration source1.6/source target1.6/target /configuration /plugin /plugins /pluginManagement /build /project The POM for 'api' module: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion parent groupIda.b.c/groupId artifactIdfoo/artifactId version1.0-SNAPSHOT/version relativePath../relativePath /parent artifactIdfoo-api/artifactId version1.0-SNAPSHOT/version packagingjar/packaging build finalNamefoo-api/finalName sourceDirectorysrc/main/java/sourceDirectory /build /project The POM for 'impl' module: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion parent groupIda.b.c/groupId artifactIdfoo/artifactId version1.0-SNAPSHOT/version relativePath../relativePath /parent groupIda.b.c/groupId artifactIdfoo-impl/artifactId version1.0-SNAPSHOT/version packagingjar/packaging dependencies dependency groupIda.b.c/groupId artifactIdfoo-api/artifactId version1.0-SNAPSHOT/version /dependency /dependencies build finalNamefoo-impl/finalName sourceDirectorysrc/main/java/sourceDirectory /build /project Thanks for your help, Dmitry On 07/04/2012 12:15 AM, Wayne Fay wrote: Question: Why Maven didn't complain on second build? What are the versions of the various projects in your build? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help me to understand this unpack-dependencies?
Hi Jirong, hujirong wrote: I found CDIPubSubMgmtMed-0.0.1-SNAPSHOT-scripts.zip in Nexus in this folder: local:8080/nexus/content/groups/mdm- public/com/nbfg/max/wesb/CDIPubSubMgmtMed/0.0.1-SNAPSHOT/ So I guess because the project is depending on the following: dependency groupIdcom.nbfg.max.wesb/groupId artifactIdCDIPubSubMgmtMed/artifactId version0.0.1-SNAPSHOT/version typeear/type classifierApp/classifier /dependency The classifier makes it look for *scripts.zip in that folder. Well, no. However, the Maven doc doesn't tell exactly how it works: http://maven.apache.org/plugins/maven-dependency-plugin/unpack- dependencies-mojo.html#classifier It works on the declared (or inherited) dependencies. You can implement a Mojo to look for artifacts of a different classifier, but I'd be really surprised if the assembly plugin does something like that. I'd bet that the script artifact is part of your dependency tree. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reactor build changes in module recompilation of dependent modules
On 3 July 2012 15:55, Dmitry Trunikov dmitry.truni...@zoral.com.ua wrote: Hi All, It seems that my question has an obvious answer. Unfortunately googling didn't give me a good one. Prerequisites: I have a classical multi-module project. The root POM declares two modules: 'api' and 'impl'. These modules have references to the parent. The module 'api' contains definition of an interface. The module 'impl' has dependency on 'api' and a class which implements the interface. Issue: In the top directory I run a reactor build: [First build] $ mvn clean compile The build finished with success. Then I made changes in the interface declaration in the module 'api' (added a new method) and run build again: [Second build] $ mvn compile javac will only recompile classes that have changed. it does not do dependency analysis, so a breaking change will only cause a compile failure until you do clean The build finished with success again. It is strange because I expected that build finished with failure because class in the module 'impl' had no implementation of the method just added to the interface. When I run build with command: [Third build] $ mvn clean compile It finished, as I expected, with failure. Question: Why Maven didn't complain on second build? Thanks for your help, Dmitry
Re: reactor build changes in module recompilation of dependent modules
javac will only recompile classes that have changed. it does not do dependency analysis, so a breaking change will only cause a compile failure until you do clean Thank you for clarification. Is there any way (except explicit 'clean') to turn on dependency analysis during compilation. The project consists of tens of modules so approach with 'clean' is not good enough because full re-biuld requires relative significant amount of time. Thanks for your help, Dmitry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: [mvn-3] jar files causing problems
Wayne 100%-nail-hit! how did you know that xalan-2.7.1.jar xalan-2.7.1.pom and other stuff . . . when downloaded as maven-artifact from the repository, comes down with such a bunch of HTML rubbish in it? Who deposits xalan-2.7.1.jar é all? Before I deleted the mirrors in my settings.xml, there was local company repository mirror defined. This mirror acts as proxy. And it provided me the same rubbish. So I removed this mirror. So the rubbish is located somehow central and I wonder if I am the only one having this types of troubles. Below my settings.xml Josef ?xml version=1.0 encoding=ISO-8859-1? settings localRepository/dka3/stadelma/.m2/repository/localRepository proxies proxy activetrue/active protocolhttp/protocol hostproxyserver.ch/host port8080/port usernameC770817/username passwordorbxorbx/password nonProxyHosts*.wgrintra.net/nonProxyHosts iddefault/id /proxy /proxies mirrors /mirrors /settings I am going to move now, from my local PC m2/repository, the failing artifacts into the OpenVMS m2/repository. -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:wayne...@gmail.com] Gesendet: Dienstag, 3. Juli 2012 18:28 An: Maven Users List Betreff: Re: [mvn-3] jar files causing problems [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details Cat the jar file or open it in vi etc. I bet you see an HTTP 503 or a 404 or something other HTML in there instead of the proper binary jar bits. Most likely you have a problem in your settings.xml. Ideally you should set up a proper local Maven Repository Manager (Nexus, Archiva, Artifactory, etc) and leverage it for your jar access. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reactor build changes in module recompilation of dependent modules
On 4 July 2012 09:46, Dmitry Trunikov dmitry.truni...@zoral.com.ua wrote: javac will only recompile classes that have changed. it does not do dependency analysis, so a breaking change will only cause a compile failure until you do clean Thank you for clarification. Is there any way (except explicit 'clean') to turn on dependency analysis during compilation. The project consists of tens of modules so approach with 'clean' is not good enough because full re-biuld requires relative significant amount of time. The way I do this is to use my IDE's dependency analysis to have my IDE do a Make (which rebuilds all the downstream changes)... then before I commit I will do a mvn clean verify to make sure that my changes are good Thanks for your help, Dmitry
AW: [mvn-3] jar files causing problems
Ok Wayne or anybody else we have a corporate repository acting as a proxy to central ! fine - this safes you a lot bandwidth and us time. But what shall I do if I get same rubbish from our repository as well as from central when I ask for pom / jar? for an artifact? I just cleared out my m2/repository and have all downloaded for a small axis2 project from our repository at axa-winterthur. As xalan jars and pom's and others are in error, just rubbish HTML in it, I expected our axa-winterthur repository is bad; Hence I took out from settings.xml the mirror to our repository. Sso I work without any mirror at the moment. But bad luck, our repository is really just a mirror of central and contains the same rubbish for xalan-2.7.1.pom and jar - HTML in a POM and in the jar's while my $ mvn install takes place I observer the following [INFO] [INFO] Building SpezplaService 1.6.1 [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml (614 B at 2.2 KB/sec) Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom [WARNING] Checksum validation failed, expected !DOCTYPE but is 2b52583a26dc455eebec16f29ab9480344f2c5a4 for http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom [WARNING] Checksum validation failed, expected !DOCTYPE but is 2b52583a26dc455eebec16f29ab9480344f2c5a4 for http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom let's take 1 by 1 Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom taking this URL into the browser brings you to the shibboleth site and it seems that the expected repository has been relocated to somewhere else. I think, maven cannot handle this bad redirection but sucks up the HTML rubbish instead from this site for the artifacts wanted. What I do not understand is, why xalan-* and a few other artifacts must come down from http://shibboleth.internet2.edu/downloads/maven2/org/apache/ Where can I prevent this? can I? can I black-list proactively the mirrorurlhttp://shibboleth.internet2.edu/downloads/maven2 ? can someone more fluent with that confirm or explain me what happens? any help welcome Josef -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:wayne...@gmail.com] Gesendet: Dienstag, 3. Juli 2012 18:28 An: Maven Users List Betreff: Re: [mvn-3] jar files causing problems [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details Cat the jar file or open it in vi etc. I bet you see an HTTP 503 or a 404 or something other HTML in there instead of the proper binary jar bits. Most likely you have a problem in your settings.xml. Ideally you should set up a proper local Maven Repository Manager (Nexus, Archiva, Artifactory, etc) and leverage it for your jar access. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[mvn] bad artifacs returned
what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef
Re: reactor build changes in module recompilation of dependent modules
The way I do this is to use my IDE's dependency analysis to have my IDE do a Make (which rebuilds all the downstream changes)... then before I commit I will do a mvn clean verify to make sure that my changes are good Yes my IDE does the analysis too. The problem is in my colleague. He is unix geek and orthodox and use Emacs as java IDE. At the start of the project we had a long discussion what use as build tool. He insisted on Ant because he knew exactly how it works and can easily adjust build process. I proposed to use Maven as it has perfect support of multi-module projects (at least I thought so at that time). I frustrated a lot because in my opinion recompilation of dependent modules when dependency was changed is a main goal of any matured build tool. And I was convinced that Maven reactor mechanism does it perfectly. Actually I can't believe in absence of such functionality in Maven.
Re: [mvn] bad artifacs returned
AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: [mvn] bad artifacs returned
To answer part of my question:
if a project has a dependency on xalan, and somehow maven-magic the artifact is
said to be at
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
however, there, a redirect happens, and the pom or the jar just ends in the
following content/page
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
titleInternet2 Shibboleth Project has moved/title
style type=text/css
h3, h4 {margin-bottom:0;}
h3+p {margin-top:0;}
. . .
in fact content of any jar or pom or sha downloaded is the html page explaining
the user that
*** Internet2 Shibboleth Project has moved ***
what is wrong ?
who has to act ?
this for the xalan and maybe many other artifacts expected to be found at the
http://shibboleth.internet2.edu/downloads/maven2 repository server
Josef
-Ursprüngliche Nachricht-
Von: Stadelmann Josef [mailto:josef.stadelm...@axa-winterthur.ch]
Gesendet: Mittwoch, 4. Juli 2012 16:28
An: Maven Users List
Betreff: [mvn] bad artifacs returned
what is returned to an depencey invoked artifact download
if the link to the artifact does not hit a .pom or the .jar wanted
but is redirected by the receiving repository server to a basic
html page explaing the user that artifacts have been moved?
i.e. currently for
/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar
/org/opensaml/openws/1.2.2/openws-1.2.2.jar;
jargs/jargs/1.0/jargs-1.0.jar
i.e. beeing requested to download from
Downloading:
http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
but is then redirected to
Downloading:
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
where it ends in the nirvana as this EP is redirected
http://shibboleth.internet2.edu/ explaing that stuff has been moved.
Josef
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: [mvn-3] jar files causing problems
Hi Josef, Stadelmann Josef wrote: Ok Wayne or anybody else [snip] What I do not understand is, why xalan-* and a few other artifacts must come down from http://shibboleth.internet2.edu/downloads/maven2/org/apache/ Where can I prevent this? can I? can I black-list proactively the mirrorurlhttp://shibboleth.internet2.edu/downloads/maven2 ? can someone more fluent with that confirm or explain me what happens? M2 has the unfortunate habbit to take repositories into account that are somewhere declared in one of the POMs that are part of your build (i.e. also those in transitive 3rd party POMs). That's the reason why it is discouraged to declare repositories in POMs. Therefore your mirror declaration should have a mirrorOf*/mirrorOf entry to mask all those additional injected repos. IIRC M3 behaves better, but uses such repos under some circumstances also. Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: [mvn] bad artifacs returned
that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: [mvn] bad artifacs returned
so in such case a solution is to exclude org.apache.xalan:xalan from the shibboleth artifact. and add a dependency to xalan:xalan. And contact those folks who publish bad poms. 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reactor build changes in module recompilation of dependent modules
Keep in mind that the reactor in general resolves the jar within the multi-module project... so you don't know which source files changed as easily and therefore you don't know which .class files to remove If you run with -DskipTests most builds are very fast anyway (hey I regularly rebuild all of Jenkins clean every day) and any decent unix guy worth their crusties should be able to fork maven in the background to build for them ;-) On 4 July 2012 15:30, Dmitry Trunikov dmitry.truni...@zoral.com.ua wrote: The way I do this is to use my IDE's dependency analysis to have my IDE do a Make (which rebuilds all the downstream changes)... then before I commit I will do a mvn clean verify to make sure that my changes are good Yes my IDE does the analysis too. The problem is in my colleague. He is unix geek and orthodox and use Emacs as java IDE. At the start of the project we had a long discussion what use as build tool. He insisted on Ant because he knew exactly how it works and can easily adjust build process. I proposed to use Maven as it has perfect support of multi-module projects (at least I thought so at that time). I frustrated a lot because in my opinion recompilation of dependent modules when dependency was changed is a main goal of any matured build tool. And I was convinced that Maven reactor mechanism does it perfectly. Actually I can't believe in absence of such functionality in Maven.
Re: Help me to understand this unpack-dependencies?
Thank you for the help, here is the result: C:\Sandbox\MDM\WESBmvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building WESB Deployment R2-0.0.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.4:tree (default-cli) @ MDM-WESB --- [INFO] com.nbfg.mdm.environments:MDM-WESB:pom:R2-0.0.1-SNAPSHOT [INFO] \- com.nbfg.fw.wsadmin:dpllib:zip:1.0.0-SNAPSHOT:compile [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.823s [INFO] Finished at: Wed Jul 04 11:19:09 EDT 2012 [INFO] Final Memory: 12M/512M [INFO] C:\Sandbox\MDM\WESB -- View this message in context: http://maven.40175.n5.nabble.com/Help-me-to-understand-this-unpack-dependencies-tp5712889p5712989.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: AW: [mvn] bad artifacs returned
It appears you have a bad dependency definition. Only you can fix it. The right one is dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency It appears that you have dependency groupIdorg.apache.xalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency No one knows how you got this included in your effective POM but it is wrong. Excluding all the repos in the world will not fix your problem. Ron On 04/07/2012 10:46 AM, Stadelmann Josef wrote: that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- 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
AW: AW: [mvn] bad artifacs returned
Ron I would not say that - because I just found out that the artifact org/apache/rampart/rampart-project/1.6.2/rampart-project-1.6.1.pom has the following snippet in it. AND My project so far depends on this artifact and it comes from apache ! Now I will check if I can make it without this artifact. rampart-project-1.6.1.pom and rampart-1.6.2 as well repositories repository releases enabledtrue/enabled updatePolicyalways/updatePolicy checksumPolicywarn/checksumPolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy checksumPolicywarn/checksumPolicy /snapshots idopen-saml/id nameOpenSAML/name urlhttp://shibboleth.internet2.edu/downloads/maven2//url /repository /repositories But the trouble makers are not at apache ! they are at EDU shibboleth which moved the artifact repository potentially without telling axis2/rampart folk what they did. what can maven do when a request for an artifact is re-directed into nirvana? Josef -Ursprüngliche Nachricht- Von: Ron Wheeler [mailto:rwhee...@artifact-software.com] Gesendet: Mittwoch, 4. Juli 2012 17:36 An: users@maven.apache.org Betreff: Re: AW: [mvn] bad artifacs returned It appears you have a bad dependency definition. Only you can fix it. The right one is dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency It appears that you have dependency groupIdorg.apache.xalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency No one knows how you got this included in your effective POM but it is wrong. Excluding all the repos in the world will not fix your problem. Ron On 04/07/2012 10:46 AM, Stadelmann Josef wrote: that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: [mvn] bad artifacs returned
And opensaml-2.2.3.pom has a reference as well repositories repository idshibboleth.internet2.edu/id nameInternet2/name layoutdefault/layout urlhttp://shibboleth.internet2.edu/downloads/maven2/url snapshots enabledfalse/enabled /snapshots /repository /repositories Just to become aware that this url is outdated and leads to troubles with maven when used in a download. Don't ask me about the mystery when this will happen. Josef -Ursprüngliche Nachricht- Von: Ron Wheeler [mailto:rwhee...@artifact-software.com] Gesendet: Mittwoch, 4. Juli 2012 17:36 An: users@maven.apache.org Betreff: Re: AW: [mvn] bad artifacs returned It appears you have a bad dependency definition. Only you can fix it. The right one is dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency It appears that you have dependency groupIdorg.apache.xalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency No one knows how you got this included in your effective POM but it is wrong. Excluding all the repos in the world will not fix your problem. Ron On 04/07/2012 10:46 AM, Stadelmann Josef wrote: that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: AW: [mvn] bad artifacs returned
That is why one should not put repo definitions in poms. The people at fault are the opensaml authors. It is also why you mirror ALL references to repos that Maven makes so that they all go to your repo manager and then your repo manager will decide what external repos should be consulted. That is your fault in this case. BTW: shibboleth.internet2.edu has no way to notify others who will be impacted by their shutdown. Perhaps they did notify you when they did it years ago but you did not understand how that would affect you until this week. OTOH: I sure hope Sonatype never shuts down Maven Central without sending me an e-mail. Sonantype guys, just to let you know... I really depend on Maven Central being up. Was I wrong about the dependency definition being incorrect? Ron On 04/07/2012 12:09 PM, Stadelmann Josef wrote: And opensaml-2.2.3.pom has a reference as well repositories repository idshibboleth.internet2.edu/id nameInternet2/name layoutdefault/layout urlhttp://shibboleth.internet2.edu/downloads/maven2/url snapshots enabledfalse/enabled /snapshots /repository /repositories Just to become aware that this url is outdated and leads to troubles with maven when used in a download. Don't ask me about the mystery when this will happen. Josef -Ursprüngliche Nachricht- Von: Ron Wheeler [mailto:rwhee...@artifact-software.com] Gesendet: Mittwoch, 4. Juli 2012 17:36 An: users@maven.apache.org Betreff: Re: AW: [mvn] bad artifacs returned It appears you have a bad dependency definition. Only you can fix it. The right one is dependency groupIdxalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency It appears that you have dependency groupIdorg.apache.xalan/groupId artifactIdxalan/artifactId version2.7.1/version /dependency No one knows how you got this included in your effective POM but it is wrong. Excluding all the repos in the world will not fix your problem. Ron On 04/07/2012 10:46 AM, Stadelmann Josef wrote: that is what I want to tell you that you will not find any artifacy at -Ursprüngliche Nachricht- Von: Olivier Lamy [mailto:ol...@apache.org] Gesendet: Mittwoch, 4. Juli 2012 16:37 An: Maven Users List Betreff: Re: [mvn] bad artifacs returned AFAIK xalan has the groupId:artifactId xalan:xalan see http://repo.maven.apache.org/maven2/xalan/xalan/ Maybe you declare the repository http://shibboleth.internet2.edu/downloads/maven2 in your pom (or in a project you are using) 2012/7/4 Stadelmann Josef josef.stadelm...@axa-winterthur.ch: what is returned to an depencey invoked artifact download if the link to the artifact does not hit a .pom or the .jar wanted but is redirected by the receiving repository server to a basic html page explaing the user that artifacts have been moved? i.e. currently for /org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar /org/opensaml/openws/1.2.2/openws-1.2.2.jar; jargs/jargs/1.0/jargs-1.0.jar i.e. beeing requested to download from Downloading: http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.p om but is then redirected to Downloading: http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/ 2.7.1/xalan-2.7.1.pom where it ends in the nirvana as this EP is redirected http://shibboleth.internet2.edu/ explaing that stuuf has been moved. Josef -- 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: [mvn] bad artifacs returned
in fact content of any jar or pom or sha downloaded is the html page explaining the user that *** Internet2 Shibboleth Project has moved *** what is wrong ? who has to act ? This is the result of a poorly configured Maven repository. This is not Maven's fault. The shibboleth repository should not return http 200 status code when it is unable to serve the proper file, which is what it is doing. Maven interprets the http 200 status code as everything is OK and saves the resulting HTML as the pom or jar file you requested. Ideally there would be some Maven magic which checks the contents of the file and ensures it seems like a reasonable pom, jar, war, etc before saving it to the local repo cache but that does not currently exist beyond a feature request in JIRA. Problems like this hopefully teach people to be aware of what Maven repositories they are linking to for dependencies and become a little bit more cautious about them. Also if you were running a proper MRM like Nexus, this problem would be dealt with in the MRM. For the best Maven-experience, you really need to be running an MRM. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mvn-3] jar files causing problems
100%-nail-hit! how did you know that xalan-2.7.1.jar xalan-2.7.1.pom and other stuff . . . when downloaded as maven-artifact from the repository, comes down with such a bunch of HTML rubbish in it? This is not entirely uncommon. I have seen it happen myself (from old java.net repo, don't get me started). Since then, I am much more careful about what mirrors I leverage in my builds and what repos we connect to. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mvn] bad artifacs returned
There should be a BIG note on the Maven front page and on the download page. Do NOT even think about using Maven until you have your Maven repo running! This means you!!! When applied without a repo, Maven is hazardous and may cause rage, intense loathing of your vocation and a desire to kick an innocent person, animal or inanimate object or to write ill-tempered e-mail to forums. Seriously, you will not like the experience and you may get hurt and waste days. If anything does not work and you do not have a repo, you are on your own and will have to depend on the pity of strangers! This whole problem would not even be in the forum if a repo had been installed. Ron On 04/07/2012 12:42 PM, Wayne Fay wrote: in fact content of any jar or pom or sha downloaded is the html page explaining the user that *** Internet2 Shibboleth Project has moved *** what is wrong ? who has to act ? This is the result of a poorly configured Maven repository. This is not Maven's fault. The shibboleth repository should not return http 200 status code when it is unable to serve the proper file, which is what it is doing. Maven interprets the http 200 status code as everything is OK and saves the resulting HTML as the pom or jar file you requested. Ideally there would be some Maven magic which checks the contents of the file and ensures it seems like a reasonable pom, jar, war, etc before saving it to the local repo cache but that does not currently exist beyond a feature request in JIRA. Problems like this hopefully teach people to be aware of what Maven repositories they are linking to for dependencies and become a little bit more cautious about them. Also if you were running a proper MRM like Nexus, this problem would be dealt with in the MRM. For the best Maven-experience, you really need to be running an MRM. Wayne - 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: [mvn] bad artifacs returned
This whole problem would not even be in the forum if a repo had been installed. Well, Josef did say in another post: we have a corporate repository acting as a proxy to central ! ... But bad luck, our repository is really just a mirror of central and contains the same rubbish for xalan-2.7.1.pom and jar So it seems he does have some kind of a corporate repository which is acting as a proxy. I don't know any more details though (what MRM he is running, what version, how it is configured, etc) which might be helpful to know. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mvn] bad artifacs returned
I think that the suggestion to validate items returned is a good one that we should raise with, I think, Aether. On Wed, Jul 4, 2012 at 2:38 PM, Ron Wheeler rwhee...@artifact-software.com wrote: There should be a BIG note on the Maven front page and on the download page. Do NOT even think about using Maven until you have your Maven repo running! This means you!!! When applied without a repo, Maven is hazardous and may cause rage, intense loathing of your vocation and a desire to kick an innocent person, animal or inanimate object or to write ill-tempered e-mail to forums. Seriously, you will not like the experience and you may get hurt and waste days. If anything does not work and you do not have a repo, you are on your own and will have to depend on the pity of strangers! This whole problem would not even be in the forum if a repo had been installed. Ron On 04/07/2012 12:42 PM, Wayne Fay wrote: in fact content of any jar or pom or sha downloaded is the html page explaining the user that *** Internet2 Shibboleth Project has moved *** what is wrong ? who has to act ? This is the result of a poorly configured Maven repository. This is not Maven's fault. The shibboleth repository should not return http 200 status code when it is unable to serve the proper file, which is what it is doing. Maven interprets the http 200 status code as everything is OK and saves the resulting HTML as the pom or jar file you requested. Ideally there would be some Maven magic which checks the contents of the file and ensures it seems like a reasonable pom, jar, war, etc before saving it to the local repo cache but that does not currently exist beyond a feature request in JIRA. Problems like this hopefully teach people to be aware of what Maven repositories they are linking to for dependencies and become a little bit more cautious about them. Also if you were running a proper MRM like Nexus, this problem would be dealt with in the MRM. For the best Maven-experience, you really need to be running an MRM. Wayne - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mvn] bad artifacs returned
Ideally there would be some Maven magic which checks the contents of the file and ensures it seems like a reasonable pom, jar, war, etc before saving it to the local repo cache but that does not currently exist beyond a feature request in JIRA. I think that the suggestion to validate items returned is a good one that we should raise with, I think, Aether. I don't disagree. I'm not sure that we can guarantee much beyond this seems to be XML (I'm not sure that we should test for it being well-formed etc) or this seems to be a zip file (for jars, wars and ears) but just a basic check of this is not garbage HTML would be sufficient (and a big enhancement) for most users. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mvn] bad artifacs returned
Am I mistaken to think that a mirrors mirror !--This sends everything else to /public -- idnexus/id mirrorOf*/mirrorOf urlhttp://myRepoURL:8081/nexus/content/groups/public/url /mirror /mirrors in my settings.xml will stop Maven from reaching a repo that someone defined in a jar that I include as a dependency? I believe that this setting sucks up any attempt by Maven on the developers workstation to reach any repo and forces it to mine. I will defer to your superior knowledge of Maven and repos but this was the belief that triggered my comments about the benefit of a properly configured Maven and repo preventing the problem in this case. Am I wrong in thinking that I am safe from third party libraries interfering with my master plan of library reference? Ron On 04/07/2012 4:36 PM, Wayne Fay wrote: This whole problem would not even be in the forum if a repo had been installed. Well, Josef did say in another post: we have a corporate repository acting as a proxy to central ! ... But bad luck, our repository is really just a mirror of central and contains the same rubbish for xalan-2.7.1.pom and jar So it seems he does have some kind of a corporate repository which is acting as a proxy. I don't know any more details though (what MRM he is running, what version, how it is configured, etc) which might be helpful to know. Wayne - 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: [mvn] bad artifacs returned
I am not sure I understand the reluctance to test that POMs are well-formed. A POM that is not well-formed is worthy of a note at least. Compared to the cost of a download, the test for well-formed XML should be pretty small for a file the size of a POM. It should be possible to recognize the HTML returned by the big-three repos in the case of an error and display the HTML body or part of it in the error message. Perhaps a standard could be agreed upon by the big-three to make it easier for Maven to detect the fact that an error message has been returned and have all three put out similar messages. Ron On 04/07/2012 6:24 PM, Wayne Fay wrote: Ideally there would be some Maven magic which checks the contents of the file and ensures it seems like a reasonable pom, jar, war, etc before saving it to the local repo cache but that does not currently exist beyond a feature request in JIRA. I think that the suggestion to validate items returned is a good one that we should raise with, I think, Aether. I don't disagree. I'm not sure that we can guarantee much beyond this seems to be XML (I'm not sure that we should test for it being well-formed etc) or this seems to be a zip file (for jars, wars and ears) but just a basic check of this is not garbage HTML would be sufficient (and a big enhancement) for most users. Wayne - 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
