We Keep Coding

What are all the default plugins used by maven?

From what I read, maven cycles through the lifecycle phases and goals invoked through the command line and it simply cycles through the mentioned phases and goals. The defaults in pom.xml make sure that maven runs sensible defaults by always running a series of plugin goals according to packaging using default bindings.
Also, if I only and only want to download dependencies and do nothing else, I can call mvn dependency:generate-sources.
So my question is:
If we run mvn install, it also downloads the dependencies mentioned in the pom.xml? Does this happen because calling install calls all the phases up till install including generates-sources which is bound to dependency plugin by default?
If not, who is responsible for fetching all the dependencies? Maven core or some other plugin?
If yes, the list of plugins invoked by default does not seem to be exhaustive. What other plugin bindings exist in pom.xml?

Yes
N/A
All maven projects have, at their base the "Super POM" which lists all of the defaults for maven. You can look there for everything. This "Super POM" is placed as the parent for any POM that doesn't list a parent explicitly.

Maven deploy:deploy-file removes extension from file

I am trying to deploy signature files separately using deploy-file goal to Nexus staging repository, but I noticed that mvn deploy plugin removes the extension. My file is something like: azerty-0.1.jar.asc
but the file that gets deployed is: azerty-0.1.asc
I tried adding a classifier: -Dclassifier=jar
the file that gets deployed is: azerty-0.1-jar.asc
This seems like a strange behaviour.
Question: Any ideas how to work around it?

This is rather a normal behavior, Maven is using the file extension as artefact packaging, from maven-deploy-plugin, deploy-file, packaging option:
Type of the artifact to be deployed. Retrieved from the <packaging> element of the POM file if a POM file specified. Defaults to the file extension if it is not specified via command line or POM.
Note: bold is mine.
Moreover, the classifier option would indeed add an - between the version and the string provided as classifier: that's maven convention.
In your case you want to specify a special packaging, which would be jar.asc if you really want the remote file to have as extension jar.asc.
The following would hence work:
mvn deploy:deploy-file -Dfile=azerty-0.1.jar.asc -Dpackaging=jar.asc -DrepositoryId=your_id -Durl=http://your_repository -DgroupId=your_groupId -DartifactId=azerty -Dversion=0.1
Note the -Dpackaging=jar.asc which effectively tells Maven the file extension would be jar.asc.
As a general note, if you are using the repository as a build store, that would still be reasonable, otherwise in your case you would push to a Maven repository an artifact which would then be difficult (or rather weird) to import in a project.
If instead this is really an additional artifact of your project, you should look at the attach-artifact goal of the build-helper-maven-plugin, to effective define it as additional artifact, then Maven will automatically add it to its install and deploy phase.

Read Maven SCM url value from Properties file

My pom.xml has scm configuration as follows
<scm>
<url>${my.scm.url}</url>
</scm>
I have property file which I am reading using properties-maven-plugin which has the value of ${my.scm.url}, and also I am using buildnumber-maven-plugin to get latest revision from SVN.
The issue is buildnumber-maven-plugin throws invalid scm url error but, when i replace ${my.scm.url} with actual url to my svn repo , it works perfectly.
How can I achieve successful execution without having to hard code scm url ?
PS: I run build using : mvn clean install command.

The problem is probably due to the order that the plugins run. The following should work:
Bind the properties-maven-plugin to the initialize phase
AFTER that plugin configuration in the POM, add the buildnumber-maven-plugin plugin
AFTER the previous two, put the buildnumber-maven-plugin plugin (which by default bind to the initialize phase).
Now all 3 plugins should run in the correct order (you can check this from the logs). Alternatively you can bind the to different phases to ensure that they run in the correct order, but the above should be enough and conforms with the goal of the initialize phase (initialize build state, e.g. set properties or create directories).

Because you didn't post the POM file, I'm guessing a bit.
Obviously, the order is going to matter, you must get the properties loaded first. That said, looking at the mojo, I'm not sure setting properties is the equivalent of essentially setting a -D.
If you did a mvn -Dscm.url= clean install, then the value would be there because it's being defined to the mvn JVM. Depending at what point the ${scm.url} is being evaluated, if it's before the properties mojo has a chance to run, it's going to be too late.
If you use a CI tool (i.e. Jenkins, Hudson) that can load the properties before the mvn call, then the variable is defined.
I've used the buildNumber mojo for my builds, because I have buildNumbers automatically generated for my snapshot artifacts. The order things occurred:
property file is downloaded from Jenkins master to slave for this job
Jenkins plugin loads the properties file into the job
maven build starts, the build number is already defined before mvn is called (again, behaving like a -D) and my buildNumber is incorporated into my artifact version
buildNumber mojo causes the property file to have buildNumber incremented
property file copied back to Jenkins master
I also wanted to load the properties file within maven and have it "update" the artifact id on the fly, but by that point, Maven had already evaluated; hence, I had to do it beforehand.
Hope this helps.

Maven Run Error "maven-clean-plugin:2.5 or one of its dependencies could not be resolved"

Using İntelliJIdea, I Downloaded my project from Subversion for 12 times.
Deleted .m2/repository for 7-8 times.
Reimported, downloaded source for 15 times. Tried every possibilities but still cannot run my project.
Here is my Maven run profile and project hierarchy
and here this is my maven output
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-clean-plugin:jar:2.5 has not been downloaded from it before. -> [Help 1]
http://paste.ubuntu.com/10613835/
There is nothing wrong with project or maven files. I'm running it on my work computer. But not in my personel.
Update1: After I deleted "-o" parameter in maven run configuration. Here is my new log Logs after deletig "-o" paramter and here is image url http://i.hizliresim.com/Lp6dDJ.png
Update2: I run this command on cmd,
C:\MAYA\MAD4>mvn dependency:tree -Dverbose the result is success. And also saw C:\Users\tayfuny\.m2\repository\org\codehaus\plexus\plexus-digest\1.0\plexus-di‌​gest-1.0.jar in my dir. Here is latest maven output http://i.hizliresim.com/XBgD07.png

Update: Its early in the morning here in Switzerland - i have overseen you specified the -o parameter in your run configuration in the section Command line:. This is the console parameter to let Maven work offline ;) Remove it and you should be all good. Source: http://books.sonatype.com/mvnref-book/reference/running-sect-options.html
Update 2: Alright the initial problem is solved - your log however shows two more things to fix (one of them optionally but very recomended): 1.) The warnings at the very start of the build imply you have duplicate dependency/version declarations - those should be easy fixable. You can for example use mvn dependency:tree -Dverbose to get a overview on the duplicates (and which definition takes place in the end). The second is a actuall build error. I dont know about the install plugin you are using but i guess that you are missing this dependency: http://mvnrepository.com/artifact/org.codehaus.plexus/plexus-digest/1.0 (or another one containing the class that could not be found - adjust version as needed as well).
Answer regarding offline mode:
Remove the parameter -o when running maven unless you want to work in offline mode and with your local repository only.
Another probable cause is explicitly setting Maven to work in offline mode (e.g. only consult the local repository to resolve dependencies) from within the IDE itself (which will result in calling Maven with the -o parameter behind the scenes).
General Settings/ Project Settings:
File -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven
(The very first option Work offline should be deactivated/ deselected unless you realy want to work with the local repository only).
Those settings are inherited by Maven-run configurations by default but may be overwritten at two levels
Default Run Configuration:
(Those default configs will be inherited by specific run configurations. Note that changes to the general settings apply to newly created run configurations only and will not be populated to existing ones).
Specific Run Configuration:
Make sure none of the options is selected. In the end if you use a specific launch configuration make sure the option is not selected in that specific configuration and change the higher levels for convenience if it makes sence)

EASY WAY
This should work for all similar errors.
This is how an error looks like
Could not resolve : org.apache.maven.plugins:maven-clean-plugin:jar:2.5
Could not resolve : (groupID):(artifactID):version
So what you actually need is a correct version of the clean plugin.
<dependency>
<groupId>(groupId)</groupId>
<artifactId>(artifactId)</artifactId>
<version>(version)</version>
<type>maven-plugin</type>
</dependency>
This will become something like this. Add this to dependencies section Pom.xml. Reload build.
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<type>maven-plugin</type>
</dependency>
Reload build and IDE will automatically download these version of artefacts and
replace if there are other versions because your project needs these particular versions to run.
Do the same with other dependency errors. "Works every time".

Maven command to download latest version of a jar

We have a process to update part of a build that is not in Maven yet but will be soon. Once built, we manually put the jar in Nexus and then update the pom files that are in SVN. Works fine and doing a "mvn clean install" pulls down the new .jar and creates a new folder in my local repository etc. Grand.
Now I would like to be able to get any new version that has been uploaded by making a mvn call without doing a build (as with mvn install). I was looking at mvn dependency:get but it seems to have a lot of parameters that only gave me errors.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.1:get(default-cli) on project workflow-project: The parameters 'repositoryUrl' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:get are missing or invalid -> [Help 1]
I have tried adding the mentioned repositoryUrl param but it too gives me errors, not least about deprecation. Is this the correct goal? How is it most simply used if so?

Use the Maven Versions plugin. It has a ton of useful commands for managing dependency versions in a POM.
For example, you can run the following:
mvn versions:use-latest-versions
That command will replace versions in your POM with the latest version of artifacts. There are optional parameters you can pass to have more fine-grained control. For example, you can use the includes parameter to specify a particular artifact to update to the latest version.

Perhaps you would be happy with a
mvn compile
Which would load the dependencies and compile but go no futher. The only changes would be in target