Tag Archives: maven

pom.xml is the configuration file of maven… the main file… the one most important file… and its kinda confusing… 🙁

the basic xml tags are easy and mostly slefexplaining… every thing is based on the basic lifecycle… but with plugins it is possible to improve and change the lifecycle…

first of all it is possible to create Mojo classes (<name>Mojo)… these classes can be executed during the build process… whereas the pluginname (artifactId) is mavan-<name>-plugin… and if set a groupId a java package name…  with a <configurations> tag it is possible to set private parameters on initialisation…

additionally these classes can be executed… in the <execution> the when of the execution can be defined, in which phase (phase-tag).

mostly helpful

actual its really confusing but i think  i start to see the power of maven… but i think learning maven is only possible to do so on the job… so only if you really need to create plugins, dependencies and other fancy stuff, you really understand it… and the problem of this learning approach is lerning-it-wrong possibility…

currently there is a pom.xml file on my project, so my maven learning curve will be slow 🙁 or just flat 😛

ok commands are cool… understanding them is easy… but seeing behind it is hard, but important… follworing list of commands is from Build Lifecycle Basics:

• validate – validate the project is correct and all necessary information is available
• compile – compile the source code of the project
• test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
• package – take the compiled code and package it in its distributable format, such as a JAR.
• integration-test – process and deploy the package if necessary into an environment where integration tests can be run
• verify – run any checks to verify the package is valid and meets quality criteria
• install – install the package into the local repository, for use as a dependency in other projects locally
• deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

the important thing here is, that if you call package, all the commands before will be called… eg. validate, compile, test and package.

this is the default behavior and can be modified by plugins…