How to define gradle project as library dependency in Play? - maven

I have a project, which is written using the Play Framework, say myproject-web. It is mostly a thin HTTP layer over another project, which forms the core of the entire business logic, called myproject-engine. In my build setup, myproject-web is a sbt project, whereas myproject-engine is a Gradle one.
What I want to achieve is that Play recognize myproject-engine as a dependency, and invoke gradle to build it whenever I try to build the play application (either on run, or automatically, as it happens in the dev mode) or when I do play dist. Is it possible? What is most important for me is that it automatically loads any dependencies that myproject-engine has.
Eventually, the state I want it to reach is that I host my Maven repo for these projects and then SBT can simply pull this package from over there and will get all its dependencies. Is this rather easy to setup? Even if it is, is it relatively easy to maintain?

As #Peter-Niederwieser pointed out in his comment, I think the only viable solution is to have a maven/ivy/gradle repository where the myproject-engine Gradle project is published to. With the correct resolvers the project becomes yet another project dependency, regardless of the build tool it uses.
See Resolvers in the official documentation of sbt.

Related

Multimodule Maven Project with interdependencies?

I have a top-level maven project with submodules. The first submodule is a Java project which generates some JavaScript library code from the compiler's annotation processor. I want to include those generated JS files into the second submodule, a webpack NPM managed project, for the build and then publish the webpack BACK into the first submodule before packaging into a fat-jar. Does anyone know of a way to accomplish this?
What you describe is a circular dependency. You have to break this circular dependency. (You probably do similar things in your code all the time.)
I have solved the same problem by breaking up the Java project. Once you do that you will recognize that, in fact, your first project was serving two separate roles that then become separated:
From:
Java project with code and assembly
JavaScript project
To:
Java project with code
JavaScript project
JAR-packaged project with assembly
I've often seen this happen in multi-module projects that build into a WAR file, and I've adopted the rule of thumb that the WAR project should not have any Java (production) code, acknowledging its role as the aggregator/assembler.
Some folks will think this third project is frivolous, some always argue that you're easily getting too many Maven modules. I think that often stems from tooling or build pipeline limitations, once you break through those, you can just embrace a growing number of Maven modules, given that the boundaries are chosen well, and I see no problems here.
One hesitation, though: why is the JavaScript project separate to begin with? If it is not deployed separately (evidently it isn't since you're assembling the "fat-jar"), the JavaScript code is following the delivery lifecycle of the "fat-jar", which would benefit from being in the same source repository, so why even make it a separate Maven module? (If they were in separate source repositories, there's a cost in version management between the modules that I'm unsure you have reasons for.) There's no shame in having a monolith (if done well -- it happens, microservices make you believe otherwise, but in that world you'd probably deploy the JavaScript code separately anyway).

Multi-project Play framework applications in IntelliJ

I’m using IntelliJ to develop a Play application. The application has several maven dependencies developed in house, some of them being marked “SNAPSHOT" meaning I want to see changes made in them immediately.
Now. When I make changes to the SNAPSHOT dependencies in IntelliJ, my Play Application doesn’t pick them up undil I build and install the modified artifacts (using maven) and trigger an SBT-build of the Play project. Otherwise the application doesn’t see my changes.
Is there any way for my Play application to resolve dependencies locally, without me having to do an install and build every time I modify one of the maven projects?
Cheers,
- hugi
PS: For those familiar with the Eclipse way of thinking, that’s kind of what I’m looking for. There I can split my project up into multiple modules and have Eclipse worry about resolving my dependencies in the workspace.
There is no easy way for this to magically work that I know of, however there are several alternatives that can ease your pain - use maven plugin for play:
maven-play2-plugin
http://nanoko-project.github.io/maven-play2-plugin/maven/release/
This one takes your dependencies and copies them into lib directory, where play picks them up. Still uses sbt to build play part of your application - that is the main disadvantage, you need to maintain 2 builds.
You still need to build your dependencies and then copy them to lib (using copy-dependencies command), but your IDE sees everything immediately.
play2-maven-plugin
https://code.google.com/p/play2-maven-plugin/
Everything is built by maven, but doesn't support play auto-reloading - you need to build & restart whole play project every time you make a change, which is kind of back to square one.

Library development/debug with Maven

I am in the processing of integrating Maven into my my projects. While maven has plenty of pros i'm finding it difficult to figure out how to maintain my current development process, which is as follows:
For creating SDKs I will create a sample app, which will depend on and directly reference the SDK source code, all from within the same code project. This means that I can make easily change/debug the SDK code with one click run/debugging.
I fear this won't really be possible with Maven. Can I create some type of Hybrid approach, where I continue my normal development approach and then push builds to Maven when it is appropriate.
Update - For Clarity
My problem is that when everything is done through maven, the dependencies are built and published to Maven. Then, the dependent project pulls down compiled references and uses them. My issues is that I don't want to go through this whole process every time I make a small change to a dependency.Thanks.
You should try creating parent level pom.xml with two modules - your library and simple app to test it. In simple app's pom.xml provide a dependency on library module.
Then open in your IDE parent pom as maven project. This should be sufficient for normal debug.
Other possible approach - install you library artifact into maven repo with sources. In this case you will be able to debug it, but test app still have to load use jars from repo.

Update dependencies while in hosted mode in GWT

I have a GWT webapp split into two Maven projects where one is a dependency to the other. Each time I change something in the dependency and I'm running webapp in hosted mode I have to rebuild the subproject and restart hosted mode for changes to apply. It takes a lot of time so I'd like to ask you if there is any way to make GWT using "live" version of the dependency?
There are 2 cases:
for server-side code, assuming you use the DevMode's embedded server, rebuilding the app and then refreshing the server should be enough
for client-side code, AFAICT, you have to use the source and output directories of the dependency module rather than the JAR containing them (GWT will load the source from the classpath, but apparently it'll only see the modified sources if it comes from a folder rather than a JAR; at least that's what I found in my tests). This goes against The Maven Way™ but the only solution so far is to use a special profile that will import the sources of the dependency project as sources of the project you're running. You can see examples of that in my archetypes.
There's actually a bug opened for the gwt-maven-plugin, MGWT-332, to do that automatically when running a reactor build. I also mused about what's really needed, for the forthcoming official gwt-maven-plugin (rewritten from scratch, independent from the CodeHaus Mojo plugin).
If your dependency does not come from a reactor build, then you're out on your own: you chose to make it totally distinct, so that's how it'll behave: you'll have to release it (even a snapshot) each time you make a change to it, and use the new version in your app (which means re-launching the DevMode).
This can be circumvented by running DevMode on your own, without the help of the gwt-maven-plugin. You're left on your own managing the classpath though (using the Google Plugin for Eclipse, I suppose you could simply edit the launch configuration to add the source folders of your dependency project to the classpath, before the classpath provided by Maven, that would reference the JAR).
Remove the dependent other application jar file from the primary application lib folder under webapp.
Eclipse should then resolve the dependency using the other project in the workspace if you have added it to your primary application classpath.
As GWT build takes ages, we invested some money in a JRebel license. We have two separate Eclipse projects for our back-end and our GWT front-end. JRebel reloads the classes automatically and I never need to restart my local server while writing code. It proved to be a wonderful time saver. Definitely worth the investment.

How to have different build task and dependency "on-demand" with Maven

Hi there i need some information or general tips on a problem with maven.
Context:
We just migrated one big eclipse project into 4 maven project. (Thats one step in the good direction!)
We were building that/those project with an ant script (build.xml) We were selecting the task to do "on-demand"
To keep it simple here are the 4 project : Core, Client, Server, Admin.
Each of those maven project build into a jar. This have been establish and it is working perfectly. Core is a dependency to Client and Server.
We use Jenkins-CI and Artifactory on a remote server.
Problem:
I need to create some kind of "parent project" that will build all those other maven project and add some task "on demand" that we were doing with an ant script.
Exemple: We want to build locally (So we don't use jenkins and artifactory on this side) for our developper so they can test manually their update (yes we have no test for now, we are working on a legacy system). On this build, we do not want to obfuscate the code or sign our jar..etc
We also want a "customer build" (The real release that we push on the server, so it does use jenkins and artifactory) That will add some task on some of the 4 project like obfuscating the code, signing the jar ..etc
For this "customer build", we need to be able to select our dependency of a library "on-the-fly" or more like "On demand". Our program is an extension to another software and all our customer don't use the same version. To make it simple the library "y" can be y-2.0.1.jar or y-2.0.2.jar.. etc
All of those "task" i need can be done in different maven-plugin with no problem.
Question: What would be a good practice to solve my problem. We would really like to get rid of our ant script. Also we are cleaning a big big dirty project so i would like a clean solution without a lots of duplicated stuff or lots of manually task to do each time we want to build either locally or on the remote server for our customer.
Idea: I though i could use different maven profile in all those 4 project as i saw there:
Ant to Maven - multiple build targets But i will have a seriously huge pom.xml for each project with lots of duplicated stuff so I really don't like this idea. I though we could have a parent maven project but this would contain no code so i think I'm wrong with this idea also.
Thank for answering and for your time!
Going with Maven Profiles is the right thing to do for this kind of customization. Then you'll probably have developerProfile and releaseProfile or such.
And yes, your poms will be big and complicated.
Looks like your demands are a little bit to much for what Maven can provide out-of-the-box, and it's not the best tool for doing highly-customized builds. Since (as I understand) you are on pretty early days with your new build infrastucture, I'd advice to look at Gradle. You could reuse your ant tasks and both Jenkins-CI and Artifactory work great with Gradle.

Resources