Releasing from development into production in maven?

You're supposed to have your code under version control (and you never "upload" files to another machine, you "download" them from the Version Control System if required) You're supposed to package your code in a format (a WAR, an EAR, another kind of bundle) that can be deployed on the production environment for execution. Such bundles typically include the dependencies. To build more complex bundles, the Maven Assembly Plugin can help Maven generated artifacts (JARs, WARs, whatever) should be shared via a remote repository (and thus deployed I mean mvn deploy here - to this remote repository).

A remote repository can be a simple file system served via a web server or a more advanced solution like Nexus Development is usually done using SNAPSHOT dependencies (e.g. 1.0-SNAPSHOT). At release time, you're supposed to change the version into a "fixed" version (e.g.1.0) and some other bits from your pom. Xml run the build to check that everything is ok, commit the modified pom.

Xml create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g.1.1-SNAPSHOT) in the pom. Xml commit the new pom. Xml in the VCS.

The entire process require some work but this can be automated using the Maven Release Plugin On the production environment, get the artifacts to be deployed from the remote repository and deploy them (some projects automate the deployment to the production server using Maven but that's another story) Of course, there are variations around this (deployment to production is most of time company specific) but the general idea is there.

You're supposed to have your code under version control (and you never "upload" files to another machine, you "download" them from the Version Control System if required). You're supposed to package your code in a format (a WAR, an EAR, another kind of bundle) that can be deployed on the production environment for execution. Such bundles typically include the dependencies.To build more complex bundles, the Maven Assembly Plugin can help.

Maven generated artifacts (JARs, WARs, whatever) should be shared via a remote repository (and thus deployed - I mean mvn deploy here - to this remote repository). A remote repository can be a simple file system served via a web server or a more advanced solution like Nexus. Development is usually done using SNAPSHOT dependencies (e.g. 1.0-SNAPSHOT).

At release time, you're supposed to change the version into a "fixed" version (e.g.1.0) and some other bits from your pom. Xml, run the build to check that everything is ok, commit the modified pom. Xml, create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g.1.1-SNAPSHOT) in the pom.

Xml, commit the new pom. Xml in the VCS. The entire process require some work but this can be automated using the Maven Release Plugin.

On the production environment, get the artifacts to be deployed from the remote repository and deploy them (some projects automate the deployment to the production server using Maven but that's another story). Of course, there are variations around this (deployment to production is most of time company specific) but the general idea is there.

You need to look into the Maven Assembly Plugin and the Maven Release Plugin.

When building artifact you usually state what scope the dependency has. In default scope it should be packaged in your archive. If you do not want it, use scope "provided" - in such case you have to prepare runtime environment providing the dependency.It's generaaly a bad idea to rebuild a package only for deployment.

As for deploying, you can use maven's antrun plugin to copy files locally or via scp .

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.