My (new) Gradle project depends on a Maven project that is a child of a parent Maven project with many subprojects. Notice that I only care about one little subproject there, nothing else from that parent.
Trouble is, Gradle walks up the Maven project tree and when it sees the "dependencyManagement" in parent pom instead of treating it for what it is - list of "approved versions" of dependencies for any and all subprojects of that parent, it actually assumes that they are ALL actual dependencies of the child/subproject I care about... And that brings waaaay too much stuff into my Gradle project.
I am presently working around by explicitly excluding all those dependencies I presently know are not presently (again) not needed, but I don't want to do that as that would mean that I have to keep up my project essentially in sync with ALL projects from that parent.
This is with Gradle 1.6. I MAY have some (little) level of influence on how those Maven projects are structured but preferably such a thing would not be needed and I could somehow tell Gradle to behave as it should... Is there a way?
Please help!
EDIT 1
The dependency is via a maven repository. The dependency I have is a subproject of a project built and deployed by Maven, to a Maven repository.
I also asked this on Gradle forums: http://forums.gradle.org/gradle/topics/8mftwmyn8uu75?rfm=1
Turns out this was not a problem at all. Huge POM of that parent project was hiding some actual dependencies that exploded...
Related
I need to extract a project from a repository which uses several layers of parent projects. Every parent project adds some dependency or plugins or properties. This is becoming a nightmare as I'm not able to build any more the project, once I've manually added pieces from parent projects.
Is there a way to create a list of all dependencies/plugins/properties which are linked by a single pom.xml so that I can build a portable, single Maven project?
Thanks
You can create the effective pom (https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html) that is a kind of merge with all parent POMs.
This is useful to understand the complete list and configuration of plugins.
Whether this helps you to build a "portable" Maven project, I don't know. Without the appropriate Maven repositories with all the plugins, dependencies and so on, Maven will not build.
Base concept of Maven is CoC (Convention over Configuration). Maven has a SuperPOM and all model is inherited from that. SuperPOM is located in maven-model-builder jar. Here is the source https://maven.apache.org/ref/3.6.2/maven-model-builder/super-pom.html
Each Maven goal is using a merged model called effective pom. The help plugin has effective-pom goal which displays the full model including parent model(s) and SuperPOM.
So the answer is just run: mvn help:effective-pom command to see actual model.
I have a need to convert the maven project to gradle project. All is going fine, but there is one problem that I faced, in the current project we are using dependency management throw parent pom of maven and in gradle as long as I researched there is no possibility to do so. I was thinking to convert somehow parent pom to maven bom and use in build.gradle because I know that gradle can use maven boms.
Do anyone have better ideas how to accoplish that ?
Or may be someone also had this kind of problem, can suggest best ways to do it ?
Regards
You could use my gradle-maven-transform plugin to transform your pom.xmls into gradle scripts.
You can use the DependencyAggregator to find versions which are common across all projects and generate a root build.gradle containing the common versions.
Each project script can then reference a version variable from the root project instead of hard coding
You might choose to use nebula dependency recomnender plugin to manage common versions. The maven-transform plugin can generate scripts to support this style of declaration too
Whilst you are evaluating the gradle build you "apply" the generated gradle scripts in your gradle build. During this time both maven and gradle builds will work in parallel. Once your happy with the gradle build you copy paste the generated scripts into your build.gradle files and ditch maven for ever! Yay!
For my project, I would like to prevent in maven modules the usage of dependencies that would not be declared in the dependencyManagement in the parent pom, is there a way to achieve this ?
Thanks
First, you will never be able to completely block the user to add dependency.
User can still add the jar manualy in his code.
Secondly yo can also decompres a module jar and put it in your project.
(actually the same as with a ant build)
It's a good start to maintain a central place with all the version of your dependencies. In a kind of "corporate parent pom".
If your company have a nexus/artifactory, you can "close the door" at that point.
I think that's utopic to have the same version of your dependencies for all your applications. You always want to be able to use the latest feature of the latest version of the dependency.
I am transitioning from using Buckminster to build an Eclipse product to Tycho. I've mavenized my plug-ins and features and have a question:
I created a parent feature with a POM that references my features and plugins. I don't know if I am doing this correctly, but I find that I need to add all features and plugins as modules. So if I have pluginA, pluginB and feature1 that includes pluginA and pluginB, I add all three to parent POM. This is a bit strange to me, because in Buckminster I had to reference only feature1 and it would get its dependencies based on the feature.xml file.
I am doing something wrong in my Tycho builds, or is this how it's suppose to work?
A Tycho build is driven by Maven, i.e. Maven first determines which modules should be part of the build reactor, and then Tycho builds the modules. Therefore, you'll need an aggregator POM that tells Maven about the list of artifacts to be built.
I have a maven project which has multiple profiles and lots of dependencies which are specific to each of those profiles. The current solution to clean this up works by creating an intermediate dependency pom for each profile which groups the dependencies together as described here in 3.6.1: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html Each of these dependency grouping poms lives in their own svn project and is build and deployed as a separate jenkins job.
The problem is that these poms, and the dependencies within them change and are released often and it has become difficult to maintain. Ideally, I would like all of the dependency management to live under one svn project and one build.
Any suggestions would be appreciated.
As khmarbaise writes, it would help with more information and an example.
However, just answering your actual question, how to get all your depenency grouping poms as one project and one build. It sound as if a multi module project with each module being one of your "dependency grouping pom" projects would be what you are looking for.
The Maven Release Plugin did what we needed.