The pure idiocy of Maven

[Oliver Watkins]

Why is the TEST before INSTALL in the build lifecycle in maven?

My unit tests are supposed to run once i have installed my web application. I am using selenium tests to test a number of test cases. The problem is, that Maven puts the TEST step right near the beginning of the lifecycle, so, that if the TEST step fails, then the whole thing fails. However I am trying to install something to FIX my test cases. So I cannot deploy these fixes, because the tests still fail. So, i am damned if I do, and damned if I don't. Maven wont let me deploy a fix to my tests because my tests don't work!!!

To get around this I need to hack around with run configurations to ignore the tests. But this is such poor and backward thinking on behalf of the maven developers.

Just idiotic in my opinion.

[Jaikiran Pai]

My unit tests are supposed to run once i have installed my web application.

It's logical that the unit tests are run before deploying any application. If those tests need a deployed application then it sounds like integration tests, which by the way has a separate phase in Maven. See this for details http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.

[Oliver Watkins]

It's logical that the unit tests are run before deploying any application.

But what if I am deploying to a development environment? I want to stage my application in a dev environment so that my selenium tests can run against it. However both TEST and INTEGRATION-TEST come before INSTALL.

[Jaikiran Pai]

Oliver Watkins wrote:

It's logical that the unit tests are run before deploying any application.

But what if I am deploying to a development environment? I want to stage my application in a dev environment so that my selenium tests can run against it. However both TEST and INTEGRATION-TEST come before INSTALL.

Install is supposed to copy over the successfully built artifact to the local maven repo. It's not meant for setting up artifacts required for integration testing. The document that I mentioned earlier has the explanations:

For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):

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.

[Jayesh A Lalwani]

IMO, using Maven as a deployment tool is not a good idea. You end up putting environment specific hacks into the build. Maven is a build tool. It should create a binary build that can be deployed by another deployment tool.

For integration testing, your tests should start a web server integrated inside Maven before running your selenium tests. It may not be always possible, but should be feasible for most applications. If you are setting up maven to deploy to your dev environment, what happens when 2 people run the same build? Now, you need a dev environment for every developer who is going to run the integration test. Since, you have developer specific environment, you need settings that developers need to override to put their environment specifics into. More properties, more external configuration, more confusion

If it's not possible to test your application in an embedded web server, you are better off moving your integration tests into a different module. This module can a) start the server b)deploy the web app c) run the tests d) stop the web app. The advantage of this is that you have isolated the environment specific properties into a separete module

[Oliver Watkins]

Well, yes i guess that is the crux of it. I need to deploy my app into an environment where I can fire off my selenium tests against.

I don't understand why this is such a big deal in Maven. Surely there must be thousands and thousands of other people out there who use selenium tests to test against their web sites and have them inegrated in Maven?

If Maven is not such a great deploy tool, should I start mixing in ANT with my Maven?

All I want to do is this :

- I have a website
- it is client side only. ie all javascript. all backend calls are mocked.
- i write some JUnit/Selenium tests in Java
- The tests work perfectly agains the website.
- When i commit, Jenkins takes over, and it is a nice continuous integration type thing.

...but

- when the unit tests break because i have changed something: I need to deploy my app locally so that i can run my tests against it before i check it in.
- it is this local test on my 8080 server before i check in where i get this idiotic "chicken or egg" scenario from Maven.
- precisely... I want to change something in my javascript that will fix my selenium tests.

[Jayesh A Lalwani]

The reason Maven is not a good deploy tool is because putting deployment functions into your build lies the way of madness. Sure, it sounds like a good idea in the beginning to have your build tool deploy your artifacts into your local dev environment to reduce the amount of work that developers have to do. It sounds like a great idea. Then the next great idea is to use the same to deploy the app into Qa environment. Then you start customizing your build to fit the specifics of QA environment. Then QA says they need to test performance in a clustered environment. So, you change your build to deploy into clustered environment. Then you get ready to deploy it in production, and your Implementation folks ask you "How do I deploy?". You say "Umm the build deploys" So, they say our machines are configured this way, and they need to configure apache. So, you go about customizing your build again. Now your deployment part of the build that started with simply copying a war to Jboss and creates database schema has bloated into something that deploys into multiple machines, configures apache. In the meantime, your developers stop using it because "It's just easier to copy war into JBoss manually. Who really wants to configure 20 properties just to deploy a war?!", and literally everyone is complaining that it takes an hour to refresh every environment, because guess what, since your deployment is married to your build, you have to literally build your entire source whenever you need to deploy. *pant* *pant* *pant*. Build hell is litterred with good ideas.


You know what's better.. a) seperate your integration tests in a differrent module. b) do this if you are running Jboss when you run your integration test

mvn jboss:start jboss:deploy integration-test jboss:stop

Bam!

If you are using a different container, google for it. Almost every container has a Maven plugin that can either help you manage the container from your maven build or run the container embedded inside maven. Yes, a lot of people have the same problem as you, but the approach that most people take nowdays is the approach that make sense in the long run:- Do not automate deployment of your web application from inside the build

ETA: Forgot to add. Yes, ant is a good deployment tool. You might want to consider having your maven build create a package that contains ant deployment scripts along with your artifacts that can be used by QA/Production to deploy into their environments. Think of your deployment tool as an artifact that is built by maven. It's really one of your deliverables