I am quite new to gradle but have good experience with maven.
I am wondering what is the difference between these two below.
api project(':my-prj-1')
vs
api "com.mydomain:grpc-helper:${grpc-helperVersion}"
I can see that when using project, i am giving just the project name not the artifactory details.
So when should or when can i use api project and what is the difference compared with just api. And in this case is there any comparison possible with Maven.
(Sorry for my poor English)
I suppose you have a sub-project named my-prj-1 that can build the sub-artifact com.mydomain:grpc-helper.
By api project(':my-prj-1'), when you build the main project, the sub-project will also get built and its artifact will be used in the main project. (1)
By api "com.mydomain:grpc-helper:${grpc-helperVersion}", the main project will try to find the artifact from the repository only, if the sub-project is not built yet, the build will fail. (2)
From my experience, I would prefer the first approach since it a little bit safer. If the sub-artifact is already built then the sub-project build is skipped (due to incremental build) so there are no performance differences from the second approach.
Related
I am currently starting my adventure with Maven, and I actually don't understand the idea behind using it to automate compilation of my source code. For the time being I am working on small projects with up to 15-20 classes, and 1 main method in the "app" class. Could someone please give me the explanation with examples, when it's necesarry (or recommended) to use build automatation tool to compile the source code and how could I benefit from using it regarding source code compilation?
Thank you very much in advance!
I was looking for different answers and I have a lot of work to do but since I've seen this question, as a Maven fanboy, I couldn't resist anymore and this below is my answer.
First of all, I agree with JF Meier which answered before me, but I think the answer can be improved.
IMO you have to consider Maven not just as a build tool, but as a multi-purpose tool which can help you to do very different things. The best 3, for me are:
Compiler. Obviously. Maven allows you to easily compile giant projects with a lot of submodules, even if some of these modules are interdependent one with each other.
Dependency and repository manager. Maven allows you to automatically download third party software and bind this downlaod to the build. This is immediately understandable if you think to framework or api dependencies from big corps (Apache found., Spark, Spring, Hibernate and so on ...) but it's really powerful in every enterprise context.
Example: you have a Maven project (let's say project A) which manages requests coming from a webservice and provides responses. This Maven project relys on another Maven project (let's say project B) which actually generates webservice jar and uploads it to a company repository. Well, when you have to add a field or a method to the webservice you just have to implements new software in project B, upload it the repo and change the version in Maven poms in both project A and B. Voilà: now EVERY developer of the company just have to "mvn clean install" project A to have the new version.
Sources and code automatic generator. Since Maven 2.x are available a lot of plugins (from Apache found. and others) which allow you to generate code and sources (tipically xml files) starting from little to none implementations.
Example 1: CXF plugin is commonly used to generate java classes from xml or xsd files.
Example 2: JAXWS plugin is commonly used to generate wsdl from SOAP webservice implementations or implementation starting from wsdl file.
Do you feel the power now?
-Andrea
The question is not very specific, but I will try to answer.
Usually, you want your source code to end up in a jar or war, so that you can use it as a library or run it somewhere (e.g. on an application server).
Maven not only compiles the classes you have and creates the final artifact (jar, war), but also handles your dependencies, e.g. the libraries your project depends upon.
I am new to gradle. I am looking forward to migrating from maven to gradle.
I had few requirements:
Existing project is maven based, and is generating a fat jar/uber jar. I am planning to split this into multiple projects, and creating smaller/thinner jars/libraries
I am currently evaluating the Multi-project Build support.
I have to also edit the Java source code, automatically, like making the java source modifications based on certain conditions
Publish the project as maven based, as other projects which need these split-up jars are still maven based.
I suppose Maven plugin can be used for publishing?
Would Gradle be a good, scalable solution for these two requirements which I am looking into currently?
Also please provide some pointers around these two topics.
Gradle has very good multi-project support, far better than Maven's. You can start with this documentation section
You can setup compilation of generated/auto-edited sources as well. Take a look at this forum post, discussing compilation of sources created from database using hbm2dao
You can setup publishing of projects using the Maven plugin. pom.xml files will be generated automatically
So I am new to the continuous integration world and of course, like everyone else, have been thrown into the task of setting it up and integrating it.
My company is .NET based and handles MVC applications, regular websites, form applications, as well as windows services. We have a ton of solutions in our repository and most of these solutions have trouble building in our CI that I am testing out (TeamCity). My local PC being the testing server.
Anyways, I have been reviewing a ton of documentation regarding TeamCity on their confluence pages but a lot of it is very technical and I'm getting tired of reading things more than once. So with that being said, there were some terms and concepts that I was a little confused on that I was hoping someone could explain pretty plainly maybe with an example.
Build Parameters -
I understand what parameters are and know what they are used for. Why would I use one in a build?
2.Snapshot dependencies -
What are these and When should I use them? I am having trouble visualizing this.
Artifact Dependencies -
I understand what artifacts are, I don't know why a project would need them to build however.
Any input would be greatly appreciated. Thanks guys.
I could give you some examples.
Build Parameters
It gives you a way to configure your build. For example, you may want to control your build version in Teamcity. You can use build parameters to specify major, minor version (with default value) for your build.
Personally, I try to avoid to use it as we should control configuration in source code or somewhere.
Snapshot dependencies
It is mostly used to build a chain of builds. For example, you have two builds. One is building source and other one is deploying to development environment. If you want to trigger deployment build after each source code build is successful, you need to add snapshot dependency to deployment build.
Artifact Dependencies
The same example as above, you want to deploy the artifact build in other build. In this situation, you need to use artifact dependency to copy the artifact into deployment build to upload somewhere etc.
Or sometimes you may have different projects, some projects are common libraries. If you don't have a artifact repository, you can use artifact dependency when those common libraries are required by other projects.
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.
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.