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.
Related
I have three Java projects. The first is an application, com.foo:foo-application:1.0.0, and the second is a module used as a dependency to that application, com.foo:foo-framework:1.0.0. The third is a Maven plugin authored by our team, com.foo:foo-plugin:1.0.0.
My intention is that any project, e.g. foo-application, which uses classes available in foo-framework must also validate that it has used those classes correctly, where said validation is enforced by foo-plugin.
Is there a way to enforce this behaviour within foo-framework's POM.xml, whereby any Maven module which declares it as a dependency in its own POM will have foo-plugin executed as part of its build lifecycle?
No (at least no way that I'm aware of).
when you declare a dependency on something, youre declaring a dependency on its output artifacts (and transitively their dependencies as optionally described in that artifact's pom.xml file). There's no place in a pom file to force anything on the build importing it - the build importing it may not even be a maven build.
it appears you may be able to do something similar via other tools though - for example checkstyle supports discovering rules from dependencies on the classpath (not exactly what you want and depends on users of your library running checkstyle configured just right)
Noob question. I'm considering to learn Maven. I understand what it does in general. Let's say I have a Maven Eclipse project. Then I create an executable JAR, and wrap it with launch4j.
Now I have TestProgram.exe file. Will Maven reload the dependencies, whenever there is a there is a new version available? Will the inner structure of the TestProgram.exe change over time as new versions of dependencies are loaded? Or does Maven update dependencies only during the development stage?
Maven is a build tool. One of it's key benefits is that it yields a repeatable build process. It does not become part of your application.
The artefacts that are included in your build are fixed by the dependency versions that you specify in your project object model (aka pom.xml file).
If you need a newer version of one of these dependencies then you must update your pom.xml file and release a new version of your product.
I am in my project reusing an open source maven-based component that includes a bunch of shaded (e.g, using the maven-shade plugin) direct and transitive dependencies in the component uber-jar. Unfortunately some of those dependencies clash with dependencies that my own project has. Specifically, the component's dependencies transitively include servlet-api 2.x whereas I need 3.x in my project - and they appear to be in the same namespace. The component's top-level dependency that pulls in servlet-api (lucene-demo) is actually not needed for the functionality of the component, so I'd be happy to remove it if possible. My project is built with Gradle.
What is the recommended way of dealing with this type of situation? Is there any way of removing the offending dependencies from the reused uber-jar when I build my own project? Or should I rebuild the reused component myself, excluding the troublesome dependency? If so, can this be done in an automatic manner, such that I don't need to maintain my own fork of the open source component? The component is presently hosted in GitHub and published via Maven Central.
(As you might understand, I'm a bit of a beginner to both Maven and Gradle, so don't worry about dumbing things down).
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...
I have a Maven project multimodule project. Some of the modules create custom packaging for the libraries produced by the other modules. The packaging being used has its own suite of versioned dependencies that I need to play nice with.
As an example: my parent POM might have an entry for e.g. commons-codec:commons-codec 1.4, my "core-lib" POM includes it as a dependency (sans explicit version), and I want to make sure my packaging module bundles in the right version. However, the specific type of custom packaging that I'm using also needs e.g. log4j:log4j 1.2.15, and I want to make sure that when my packaging module runs, it also bundles the correct log4j version.
Here's the wrinkle: the example POM I'm working from for "project that makes {custom packaging}" uses a parent that's provided by the custom-packaging team. If I use their parent, I lose the version info for commons-codec. If I use my parent, I lose the version info for log4j.
Now, ordinarily if I ask "how do I make A and B depend on the same version", you'd answer "make A and B have the same parent, and include a dependencyManagementsection in the parent". My problem is, I need A, B, and C to depend on the same version, but I don't have any control over C.
I think this is what Maven "mixins" are meant to address, but of course they don't exist yet. In the meantime, what I've been doing is picking one parent, then copy-and-pasting the dependencyManagement section from the other POM, with a comment saying "make sure you keep this up to date". Obviously this is an ugly, ugly hack, but I haven't found another way to keep current with both sides.
What about using the assembly plugin to pack up your artifact with all its dependencies and having your packaging module run on that instead? Then you're not trying any pom magic. It's just a matter of one project using the artifact from another project, like usual.
For now, I'm going to accept the answer of "this is one of the really sucky things about Maven". Maybe this question can get updated when Maven 3.1 finally launches.
Could you not activate multiple profiles which have their own dependency section pulling in the required libraries when enabled. This allows some nice flexibility due to the ways that profiles can be activated.