I'm trying to create a multi module maven project from several inter-dependent android projects.
I've created individual pom files under the module folders and created a pom.xml in the parent folder. I've added all the modules to the parent pom.xml.
Now, when I do "mvn install" from parent folder, all the modules get compiled, apks are generated and the apks from modules that have tests are deployed to the virtual devices and instrumentation tests are run. All of this happens as expected.
Now, if I just want to deploy all the apks from the multi module project to all active virtual devices, how would I go about doing that? Doing "mvn android:deploy" from parent folder does not deploy any apks. It says "finished" for the parent project and then all other submodules are skipped. But no apks are deployed.
Is there a way to do what I'm trying to do?
Also, on a related note, "mvn install" bails out when one of the instrumentation tests fails. Is there a way to get "mvn install" to build other modules even when one of the instrumentation tests from previous modules failed?
Thank you,
Related
I have a multi-module project that uses maven. Is there a way I can point IntelliJ to maven target/ folder so when I start Debug it won't rebuild the project from scratch and re-upload a whole project via JRebel all over again.
Basically, use target/ as a build folder. Changing compile output path didn't work as I expected it to not compile classes that were compiled by mvn already.
The IntelliJ Run/Debug configurations can specify which actions happen before launching the application.
By default for say web applications, this would display
Build
Build x artifact
You may remove both entries if you are happy with building via maven before launching the application.
Regarding the JRebel side of it - it should certainly not be updating the classes on the second compile assuming nothing changed. The classes have their hashes checked before a reload. This is assuming maven and IntelliJ are using the default javac compiler. If either is configured to use ecj compiler, it's best to let JRebel only see classes built with the same compiler.
I am developing plugins for Spigot and I want to be able to build and run them from the same place, with the server's output going into the terminal. How do I make IntelliJ place my jar in a plugins folder and then run the server jar outside of it?
Make an artifact to build the jar to the directory and then make a run config that executes the other jar, and down at the bottom there is a list where you can have IntelliJ build the jar.
I have done an mvn install for a custom plugin and it gave me a bunch of directories in my target directory along with a jar. I'm stuck with the next step.
How do I bundle it?
Where do I place this?
What about the pom of this plugin?
What configuration changes do I have to make and where?
You can always test it on your local machine. Just run mvn clean install and it will be installed in your local repository. Then in the project you'd like to use it from, just add the plugin to the plugins section and set it up like any other plugin. This should be enough.
If you'll be using it in your company, you'll need to be able to deploy it to a Maven repository such as Nexus or Artifactory in order for other people to be able to download it.
Deploying it is the same as for regular artifacts:
mvn clean deploy
I have a project that's using the Play framework, and the corporate standard is that all projects should be built by Hudson. However, I cannot find out how to do this, as Hudson does not follow any Java standards, and requires the framework installed at the computer it runs on. I have tried to build the project with Maven (if I had managed this, adding it to Hudson should be quite simple), but I have failed to make it work. I tried the Play Maven module, but Maven claims it does not find the external repo that is listed (http://nexus.infin-it.fr/content/groups/public). This might be because I am behind a firewall. I also tried the recipe listed here, but the local maven build fails because it is unable to find org.playframework:play:1.1:jar.
Has anyone done this and can provide a howto?
It can be done without installing the Play framework on the Hudson server, but it is quite complicated:
Put the play libraries (play.jar and its dependencies) in a Maven repository
Create a pom.xml for your project, configured with:
theses libraries as dependencies
your project specific dependencies (project lib directory)
the java sources folder of your project (in the maven-compiler-plugin): "app"
If your project is simple (no module dependencies), this pom allows you to build the play project java sources using Maven.
If your project has module dependencies, you will have to add the dependencies jar in your pom dependencies.
To do that, you will have to create jar files from the modules if they don't have packaged jars (to get the "CRUD" class of the CRUD module for example).
You can find some help on this page I wrote :
http://blog.infin-it.fr/2010/12/15/play-framework-integration-continue-retour-dexperience/
Even if it's in French, I put my Ant stuff and the Play's pom I wrote.
At work we managed to integrate our Play applications with Bamboo.
It should not be difficult with my files.
Just looked at the repository, that you linked (http://nexus.infin-it.fr/content/groups/public). And guess what, I found the play-1.1.jar. However, the artifact ID is: org.play:play:1.1:jar and not org.playframework
In theory, you could put the full Play zip on your build or in in your repository, and then use Hudson to kick off an Ant script to download Play to the Hudson agent, unzip it, and then run commands on it. It's a little clunky, but it should work.
Note: This question has been originally posted by Lahiru Gunathilake as an answer to another question. I'm moving it here as a separated question for the sake of clarity.
When we are doing a release we just build in our local machine and do the QA and then we host it in to repository. If we run mvn deploy does it create new artifacts, this cause having different artifact in the repository and in binary distribution because we are creating the binary distribution from our local repository. But if someone get the source code and do the build they'll get a different one. But if mvn deploy doesn't build but only deploy it's fine.
As explained in Build Lifecycle Basics:
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
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.
These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.
To do all those, you only need to call the last build phase to be executed, in this case, deploy:
mvn deploy
That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase.
So, the answer is yes, mvn deploy will execute install and build the project artifacts. But if you don't change anything, this will produce exactly the same artifact.