gandheshantanus
BAN USERThe clean, install and deploy phases are valid lifecycle phases and invoking them will trigger all the phases preceding them, and the goals bound to these phases.
mvn clean install
This command invokes the clean phase and then the install phase sequentially:
clean: removes files generated at build-time in a project's directory (target by default)
install: installs the package into the local repository, for use as a dependency in other projects locally.
mvn deploy
This command invokes the deploy phase:
deploy: copies the final package to the remote repository for sharing with other developers and projects.
mvn release
This is not a valid phase nor a goal so this won't do anything. But if refers to the Maven Release Plugin that is used to automate release management. Releasing a project is done in two steps: prepare and perform. As documented:
Preparing a release goes through the following release phases:
Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
Transform the SCM information in the POM to include the final destination of the tag
Run the project tests against the modified POMs to confirm everything is in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
Commit the modified POMs
And then:
Performing a release runs the following release phases:
Checkout from an SCM URL with optional tag
Run the predefined Maven goals to release the project (by default, deploy site-deploy)
The clean, install and deploy phases are valid lifecycle phases and invoking them will trigger all the phases preceding them, and the goals bound to these phases.
mvn clean install
This command invokes the clean phase and then the install phase sequentially:
clean: removes files generated at build-time in a project's directory (target by default)
install: installs the package into the local repository, for use as a dependency in other projects locally.
mvn deploy
This command invokes the deploy phase:
deploy: copies the final package to the remote repository for sharing with other developers and projects.
mvn release
This is not a valid phase nor a goal so this won't do anything. But if refers to the Maven Release Plugin that is used to automate release management. Releasing a project is done in two steps: prepare and perform. As documented:
Preparing a release goes through the following release phases:
Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
Transform the SCM information in the POM to include the final destination of the tag
Run the project tests against the modified POMs to confirm everything is in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
Commit the modified POMs
And then:
Performing a release runs the following release phases:
Checkout from an SCM URL with optional tag
Run the predefined Maven goals to release the project (by default, deploy site-deploy)
down vote accepted
A snapshot version in Maven is one that has not been released.
The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It's basically "1.0 under development". This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).
The difference between a "real" version an a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday.
Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.
Note:You can name the version number as per your wish :)
When you have a consistently changing design of your base class ,you should go for an abstract class as the classes which extend these base classes will automatically inherit functionality from the base classes.But instead if you use a interface,not only the interfaces would have to be changed but also the classes implementing the interface would have to be changed.So inshort when you have a consistently changing design you should opt for a Abstract class and vice versa.
- gandheshantanus March 16, 2012