Deploying Java projects in Linux

1. Check out the project from SVN

SVN Co SVN address and project directory (e.g., SVN co Http://172.18.59.101/svn/svnroot/project/testpro)

2. Use MVN to download the project-dependent package and package the project (enter the command in the Pom.xml sibling directory )

MVN install--Installing the jar in the local repository

MVN install:install-file-dfile= "Lib/server-1.1.jar"-dgroupid= "Org.server"-dartifactid= "Server"-Dversion= "1.1"- dpackaging=jar--Publishing third-party jars to local libraries

MVN-E-X Clean compile--removes the compiled content from the target directory and compiles the project

MVN package--Packaging

3. Start the Running project

Appendix:

First, MVN common commands

1. Create a generic Java project for Maven:
MVN Archetype:create-dgroupid=packagename-dartifactid=projectname
2. Create a MAVEN Web project:
MVN Archetype:create-dgroupid=packagename-dartifactid=webappname-darchetypeartifactid=maven-archetype-webapp
3. Compiling source code: MVN Compile
4. Compiling test code: MVN test-compile
5. Run the test: MVN test
6. Generate site (website that generates project-related information): MVN site
7. Packaging (Generate target directory, compile, test code, generate test report, generate Jar/war file): MVN package
8. Installing the JAR:MVN install in the local repository
9. Clear the resulting project (delete compiled content from target directory): MVN clean
10. Build Eclipse Project: MVN eclipse:eclipse
11. Generate the Idea project: MVN Idea:idea
12. Combine with goal commands, such as package-only not tested: Mvn-dtest packages
13. Compile the content of the test: MVN test-compile
14. Only hit jar package: MVN Jar:jar
15. Test without compiling and not compiling: mvn test-skipping compile-skipping Test-compile
(-skipping's flexible use, of course, can also be used for other combination commands)
16. Clear some system settings for Eclipse: mvn Eclipse:clean
17. Display version information: mvn-version/-v
18. Build the WTP Plugin Web project: mvn-dwtpversion=1.0 eclipse:eclipse
19. Clear configuration information for Eclipse projects (Web project): mvn-dwtpversion=1.0 Eclipse:clean
20. Publish the third-party jar to the local library: MVN Install:install-file-dgroupid=com-dartifactid=client-dversion=0.1.0-dpackaging=jar-dfile=d : \client-0.1.0.jar
21. Display verbose error message: MVN-E
22. Verify that the project is correct and that all required resources are available: MVN validate
23. Compile the Project test code: MVN test-compile
24. Processing and publishing packages in an environment where integration testing can run: MVN integration-test
25. Run any checks to verify that the package is valid and meets the quality standards: MVN verify
26. Generate any additional source code required by the application, such as XDOCLET:MVN generate-sources
The Exec plugin allows us to run this program without loading the appropriate dependencies into classpath: mvn exec:java-dexec.mainclass=org.sonatype.mavenbook.weather.main
28. Print out a list of resolved dependencies: MVN dependency:resolve
29. Print the entire dependency tree: MVN dependency:tree
30. To view the complete dependency trail, including those that were rejected for conflict or other reasons, open Maven Debug tag run: mvn install-x
31. Building the assembly MAVEN Assembly plugin is a plugin to create your application-specific distribution package: MVN install assembly:assembly
32. Constructing the database using the Hibernate3 plugin: mvn hibernate3:hbm2ddl
33. Use the describe target of the help plugin to output the information for the Maven add plugin: mvn help:describe-dplugin=help
34. Use the Help plugin to output the complete target column with parameters: MVN help:describe-dplugin=help-dfull
35. Get information for a single target, set the Mojo parameter and the plugin parameter. This command lists all the information for the compile target of the compiler plug-in: mvn help:describe-dplugin=compiler-dmojo=compile-dfull
36. List the targets available for all Maven Exec plugins: mvn help:describe-dplugin=exec-dfull
37. Look at this "active (Effective)" POM, which exposes the default settings for Maven: MVN Help:effective-pom

Ps:

The general usage is this, first through CVS or svn download code to the native, then execute MVN eclipse:eclipse generate Ecllipse project file, and then import to eclipse on the line, modify the code after the MVN compile or MVN test test, You can also download the Maven plugin for Eclipse.

Using multiple repositories with applications
<repositories>
<repository>
<id>Ibiblio</id>
<name>Ibiblio</name>
<url>http://www.ibiblio.org/maven/</url>
</repository>
<repository>
<id>PlanetMirror</id>
<name>planet mirror</name>
<url>http://public.planetmirror.com/pub/maven/</url>
</repository>
</repositories>

MVN Deploy:deploy-file-dgroupid=com-dartifactid=client-dversion=0.1.0-dpackaging=jar-dfile=d:\client-0.1.0.jar- drepositoryid=maven-repository-inner-durl=ftp://xxxxxxx/opt/maven/repository/

Two, SVN conflict resolution

The first is to use the Update option for conflict resolution, which means that the-accept parameter is used as a conflict handling mode regardless of whether the current copy copy is the latest version

–accept Arg:specify Automatic Conflict resolution action
(' Postpone ', ' base ', ' mine-conflict ', ' theirs-conflict ', ' mine-full ', ' theirs-full ', ' edit ', ' launch ')

(p) Postpone–mark the conflict to be resolved later//Let the file remain in a conflict state after the update is complete.
(DF) Diff-full–show All changes made to merged file//uses the standard distinguished format to show the difference between the base revision and the conflicting file itself.
(e) Edit–change merged file in an editor//use your favorite editor to open the conflicting files, the editor is set by the environment variable editor.
(r) resolved–accept merged version of File//finish editing the files, notify SVN that you have resolved the file conflict, it must accept the current content-essentially you have "resolved" the conflict.
(MF) mine-full–accept My version of entire file (ignore their change//discards the new changes received from the server and only uses the local modifications you view the files.
(TF) theirs-full–accept their version of entire file (lose my changes)//discard your local modifications to the view file, using only the newly received changes from the server.
(l) Launch–launch External tool to resolve conflict//initiates an external program to perform conflict resolution, which requires some preparation.
(h) Help–show this list//displays all commands that may be used in conflict resolution.

Second, when update does not deal with conflicts, use SVN resolve to resolve conflicts

1. Use SVN resolve–accept base to select the base version, i.e. 1.txt.rold as the last submitted version

–accept arg:specify Automatic conflict resolution source
(' base ', ' working ', ' mine-conflict ', ' theirs-conflict ', ' mine-full ', ' theirs-full ')

2, manually modify the 1.txt file, and then the current copy is 1.txt as the last commit version

SVN resolve–accept Working 1.txt

3, SVN resolve–accept theirs-full 1.txt use 1.txt.rnew as the last submitted version

4, SVN resolve–accept mine-full 1.txt use 1.txt.mine as the last submitted version

5, SVN resolve–accept mine-conflict 1.txt Use the conflict part of 1.txt.mine as the last commit version

6, SVN resolve–accept theirs-conflict 1.txt Use the conflict part of 1.txt.rnew as the last commit version

Third, use SVN revert to cancel the change

The previous two days in resolving the conflict with the SVN resolve command, found this article mainly because his description of the –accept parameter is more detailed than the official document.

Conflict classification

Occasionally, you encounter conflicts when you update, merge files from the repository, or switch the working copy to a different URL. There are two types of conflicts:

File conflicts

A file conflict occurs when two (or more) developers modify an adjacent or identical row in the same file.

Tree clash

A tree conflict occurs when a developer moves, renames, deletes a file or folder, and another developer moves, renames, deletes, or simply modifies it.

file Conflicts

A file conflict occurs when two or more developers modify an adjacent or identical row in the same file. Because Subversion does not know the specifics of your project, it leaves the conflict resolution task to the developer. In the event of a conflict, you should open the problematic file and look for lines that begin with the string <<<<<<<. Zones with conflicts are marked in the following way:

<<<<<<< file name  your modifications =======  merge code >>>>>>> versions from the repository

For each conflicting file Subversion placed three files in your directory:

File name. ext.mine

This is your file that exists in your working copy before you update your working copy-that is, there is no conflict flag. This file has nothing else but your latest changes.

File name. EXT.R old version

This is the base version (base revision) file before you update your working copy. In other words, it is the file that was checked out before you made the last modification.

File name. EXT.R New version

This file is the one that your Subversion client received from the server when you updated your working copy. This file corresponds to the latest version in the repository.

You can run the external merge tool/conflict editor through TortoiseSVN → edit conflicts , or you can manually resolve conflicts using any other editor. You need to decide which code is needed, make some necessary changes, and then save it.

Then, execute the command TortoiseSVN → resolved and the author's modifications to the repository. Note that the resolved command does not really resolve the conflict, it just removes the filename.ext.mine and filename.ext.r* two files, allowing you to commit the changes.

Subversion does not attempt to merge files if your binaries are conflicting. The local file remains the same (exactly what you did when you last modified it), but you will see the filename.ext.r* file. If you want to undo your changes and keep the version in the repository, use the Restore (Revert) command. If you want to keep your version covered in the version of the repository, use the resolved command and then submit your version.

You can right-click the parent folder, select TortoiseSVN → resolved ..., and use the resolved command to resolve multiple files. This will bring up a dialog box listing all the conflicting files under the folder, and you can choose which ones to mark as resolved.

Tree clash

A tree conflict occurs when a developer moves, renames, deletes a file or folder, and another developer moves, renames, deletes, or simply modifies it. There are many different scenarios that can cause tree collisions, and different situations require different steps to resolve conflicts.

When a file is deleted by Subversion, the file is also deleted from the native file system. Therefore, even if it is part of a tree conflict, it is not possible to display conflicting overlay icons or to resolve conflicts by right-clicking. Use the Check Modify dialog box to get edit conflict options.

TortoiseSVN can assist in finding the correct location for merge changes, but some additional work is needed to organize the conflicts. Keep in mind that when an update is performed, the underlying file for the working copy will include the version of each item in the repository when the update operation is performed. If you undo the changes after you make the update, the working copy will return to the repository state, not the state you started before making the change.

Local Delete, when the update has changed into

1. Developer A modifies the FOO.C and submits it to the repository

2. Developer B also renamed the file foo.c to bar.c in his working copy, or just deleted FOO.C or its parent folder.

Updating a working copy of developer B results in a tree conflict:

• In the working copy, FOO.C is deleted, but is marked as a tree conflict.

• If the conflict is caused by changing the file name and not the deletion, BAR.C is marked as added, but does not include what developer A modified.

Developer B must now make a choice as to whether to keep developer A's changes. In the case of changing the file name, he can merge the foo.c changes into the renamed file BAR.C. For cases where a file or folder is deleted, he can choose to keep the item that contains developer A changes and discard the delete operation. Or do nothing and directly mark the conflict as resolved, so he actually discards the changes to developer a.

If TortoiseSVN can find the original file that was renamed BAR.C, the Conflict Edit dialog box will be able to merge the changes. Depending on where the update operation is called, it may not be able to find the original file.

Local changes, when updated with delete entry

1. Developer A renamed the file foo.c to BAR.C and submitted it to the repository.

2. Developer B modifies the file foo.c in his working copy.

Or in a case where a folder is renamed ...

1. Developer A renames the parent folder Foofolder to Barfolder and submits it to the repository.

2. Developer B modifies the file foo.c in his working copy.

Updating a working copy of developer B causes a tree conflict. For a simple file conflict:

• The bar.c is added to the working copy as a normal file.

• FOO.C is marked as added (including its history) and generates a tree conflict.

For a folder conflict:

• Barfolder is added to the working copy as a normal folder.

• Foofolder is marked as added (including its history) and generates a tree conflict.

  FOO.C is marked as modified.

Developer B now needs to make a decision whether to accept the structural changes made by developer A and merge her changes into the appropriate files under the new structure, or discard the changes to developer a directly and keep the local files.

To merge her native changes into the new layout, developer B must first find out what the conflicting files foo.c after renaming/moving the new file name in the repository. You can use the Log dialog box to accomplish this task. The changes have to be merged manually, because there is no way to automate or simply complete this operation. Once the changes have been migrated, the conflicting paths are redundant and can be deleted. In this case, use the delete button in the Conflict Edit dialog box to clean up and mark the conflict as resolved.

If developer B thinks that A's change is wrong, she must select the keep button in the Conflict Edit dialog box. This will mark the conflicting files/folders as resolved, but requires manual removal of developer A's changes. It also helps track which files are moved by using the Log dialog box.

Local Delete, when updated with delete entry

1. Developer A renamed the file foo.c to BAR.C and submitted it to the repository.

2. Developer B renamed file foo.c to Bix.c

Updating a working copy of developer B results in a tree conflict:

• BIX.C is marked for addition (including its history).

• The bar.c is added to the working copy and its status is ' normal '.

• FOO.C is marked for deletion and produces a tree conflict.

To resolve this conflict, developer B must find out what the conflicting file foo.c the new file name in the repository after it was renamed/moved. You can use the Log dialog box to accomplish this task.

Then, developer B needs to decide which of the new file names in FOO.C needs to be retained-the one that developer a changed or the one he changed himself.

After developer B manually resolves the conflict, use the buttons in the Conflict Edit dialog box to mark the tree conflict as resolved.

Local missing, when merging has changed into

1. Developer A works on the trunk, modifies the foo.c and submits it to the repository

2. Developer B works on the branch, renaming foo.c to BAR.C and committing it to the repository

Merging the backbone of developer A to the branch working copy of developer B causes tree conflicts:

• Bar.c already exists in the working copy and its status is ' normal '.

• FOO.C is marked as missing and has a tree conflict.

To resolve this conflict, developer B marks the file as resolved in the Conflict Edit dialog box so that it is removed from the conflict list. She next needs to decide whether to copy the missing file foo.c from the repository to the working copy, whether to change developer A's changes to foo.c and merge it into the renamed BAR.C or whether to ignore the change by marking the conflict as resolved.

Note that if you copy the missing files from the repository to your working copy and then mark them as resolved, the files that you copied will be deleted again. You must resolve the conflict first.

Local changes, when merging with delete entry

1. Developer A works on the trunk, renaming foo.c to BAR.C and submitting it to the repository

2. Developer B works on the branch, modifies the FOO.C and submits it to the repository

There was a similar case when the folder was renamed, but it was not recognized in Subversion 1.6 ...

1. Developer A works on the trunk, renaming the parent folder Foofolder to Barfolder and committing it to the repository.

2. Developer B works on the branch and modifies the foo.c in her working copy.

Merging the backbone of developer A to the branch working copy of developer B causes tree conflicts:

• BAR.C is marked as added.

• FOO.C is marked as modified and a tree conflict is created.

Developer B now needs to make a decision whether to accept the structural changes made by developer A and merge her changes into the appropriate files under the new structure, or discard the changes to developer a directly and keep the local files.

To merge her native changes into the new layout, developer B must first find out what the conflicting files foo.c after renaming/moving the new file name in the repository. This task can be done by using the Log dialog box for the merge source. The conflict editor displays only the log of the working copy because it does not know which path to merge in, so you need to find it yourself. The changes have to be merged manually, because there is no way to automate or simply complete this operation. Once the changes have been migrated, the conflicting paths are redundant and can be deleted. In this case, use the delete button in the Conflict Edit dialog box to clean up and mark the conflict as resolved.

If developer B thinks that A's change is wrong, she must select the keep button in the Conflict Edit dialog box. This will mark the conflicting files/folders as resolved, but requires manual removal of developer A's changes. It also helps track which files are moved by using the Log dialog box.

Local deletion, when merging with delete entry

1. Developer A works on the trunk, renaming foo.c to BAR.C and submitting it to the repository

2. Developer B works on a per cent, renamed FOO.C to BIX.C and submits it to the repository

Merging the backbone of developer A to the branch working copy of developer B causes tree conflicts:

• The bix.c is marked as a normal (unmodified) state.

• BAR.C is marked for addition (including its history).

• FOO.C is marked as missing and has a tree conflict.

To resolve this conflict, developer B must first identify the conflicting file foo.c the new file name in the repository after renaming/moving. This task can be done by using the Log dialog box for the merge source. The conflict editor displays only the log of the working copy because it does not know which path to merge in, so you need to find it yourself.

Then, developer B needs to decide which of the new file names in FOO.C needs to be retained-the one that developer a changed or the one he changed himself.

After developer B manually resolves the conflict, use the buttons in the Conflict Edit dialog box to mark the tree conflict as resolved.

About My Solution
I have encountered this problem, no matter how kind can not be deleted. Finally, you have to delete all local files and re-update the library. Then delete the file you want to delete and submit it. This is not the problem.

From: http://hi.baidu.com/ostech/blog/item/1c6ea627ca67af6b34a80f91.html

This article from reprint please indicate source: http://blog.csdn.net/lifxue/archive/2009/10/14/4662902.aspx

Deploying Java projects in Linux