Where do I specify repository paths in OpenDaylight Nitrogen (on Karaf 4.0)? I am building a Java application on this platform. I noticed that features.xml is generated from the POM. I need to load some features from my local Maven .m2/repository that are generated from another project. I see a features/features-X directory with a pom.xml where I can add the feature dependency, but where do I specify the repository in which to look for the feature?
This is probably more of a Maven question than an OpenDaylight question....
This is somewhat OpenDaylight-specific (although obviously the behaviour can be replicated using Maven in other contexts). As you’ve discovered, Karaf feature descriptors are now generated automatically, based on the POM dependencies. For this to work, the following requirements must be met:
the feature-generating module must have org.opendaylight.odlparent:single-feature-parent as its parent (transitively if necessary);
the POM must specify feature as its packaging type;
feature dependencies should be declared as build dependencies in the POM, using the default scope, with type set to xml and classifier set to features (plural).
If necessary, feature snippets can be given as src/main/feature/feature.xml (singular) in the corresponding module; these will be merged with the generated feature.xml (singular again). The result is installed as a features.xml (plural) file in the target repository.
It’s worth noting that feature descriptors generated in this fashion use each feature they depend upon as their own repositories; if you need a multi-feature repository instead, you should use a manually-generated feature descriptor.
This is briefly documented in the ODL Parent developer guide.
Just put it in as a dependency in features/features-X/pom.xml the plugin looks at the maven path and automatically generates the repository. ( Answering my own question so it could be of use to others. )
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)
Is there a way to install a BOM as part of maven invocation before maven tries
to resolve it. See related questions for a normal dependency
Install local jar dependency as part of the lifecycle, before Maven attempts to resolve it
Is there are way to install maven dependencies before maven attempts to resolve them?
I have tried to run a plugin in validate phase, but maven always resolved the
bom first be it a import scope bom or used as a parent bom.
About BOM: http://www.baeldung.com/spring-maven-bom
The expected usage of maven BOM is within the dependencyManagement section of a pom.xml.
Maven documentation states:
Other projects that wish to use the library should import this pom into the dependencyManagement section of their pom. (Please refer to Introduction to the Dependency Mechanism)
In a multi-module project you would usually have a dependencyManagement section with the parent pom only.
Also, just for clarification: The bom is NOT causing dependencies to the artifacts indicated therein. It is merely indicating the versions of the "ingredients" that are intended to be used together (for dependencies that are composed of several artifacts expected to be used together) in case a dependency is added somewhere in a related pom such dependencyManagement applies to.
With such setup maven will resolve the bom at time of processing dependencyManagement section. This is time of evaluating the surrounding pom.xml (or any referencing sub-module). The bom is then added to the local repository like any other dependency.
So, under normal circumstances there is no need for "fetching the bom from the net and installing it into the local repository".
Now, why would a bom artifact not be available at the time a maven call is being started?
The artifact source (repository) is not accessible
Then, downloading the artifact and providing it into local repository would be the way to go.
The artifact version is not known before (or is decided at starting time, e.g. either be specifying a profile or indicating the version as a runtime parameter)
Then the dependency mechanisms of maven still would work as expected.
The bom artifact content (list of artifacts or respective versions) is not known before (e.g. as it is depending on outcome of some build step during the build run)
Then, you likely need to rethink your build process, as it looks like you are trying to force maven into something it is not designed to support. Likely, the "dynamic" part is intrinsic to your project and thus, the dynamic dependency really should be a sub-module within your (multi-module) project. But it is really hard to advise without more input on a specific use case.
While a specific artifact to be consumed within a build step might be provided late (by relying on lazy evaluation of dependencies), this will much more difficult with bom dependencies. As such are dependency management entities that need to be resolved before the first time any dependency needs to be resolved as maven can not known what artifacts are contained within the bom.
If actually there is a usecase that absolutely requires such bom to be provided dynamically, then the only chance is a two layer process, where the top layer is providing the bom and the lower layer is then using it. Please note, that such a solution absolutely needs two independent maven processes (so, NOT just a simple multi-module project) in order to get the resolution of the depenceManagement dependency deferred until it is known.
I have a project contains two sub projects:
A. a common library for external api
B. a program depends on above library
They are inside same directory. How I made B refer to A with maven?
Normally you will always share through a maven repository. That is mavens way to ensure a consistent and correct solution and a solution shareable by all developers.
You should search for a public maven repository with project A (e.g. http://search.maven.org or http://mvnrepository.com) and include in your pom
If it does not exist in public (is proprietary in someway or other), consider using an enterprise-wide maven repository such as nexus or artifactory to push to repositories.
Finally, some developers resort to either installing a mvn-local file if you are ever only going to work on an explicit workstation.
If you still prefer a filebased acces, it is possible to define a maven file repository and reference it in your pom. E.g. Heroku use this for bundling extra dependencies into their system.
Declare A as dependency in B's pom.xml. Make sure A has valid pom.xml and is deployed to your repository (local/nexus). We do that all the time. Take care to assign SNAPSHOT version if you always want latest to be pulled from repository.
I'm trying to find a command that does the opposite of mvn dependency:tree. I want to find out all the projects that depend on a specific module. As trivial as it may sound, I couldn't find such thing.
The use case is in order to find, in a very large project, if I can delete a module or if there are other modules that use it as their dependency.
Try this:
mvn dependency:tree -Dincludes=module
Where module is the dependency you're interested in. You should get the list of libraries that depend on the module you've specified, either directly or transitively.
Although outdated since the question is from 2014, I was looking for something similar:
matching dependencies (f.e. junit) to a list of projects (f.e. maven-compiler-plugin 3.6.0) in use, which should give a list of dependent dependencies currently in use (f.e. junit 4.12). That should point us (for our own projects) to outdated dependencies (f.e. junit 3.8). This will be used for the undeployment of overgrown services (in this case).
Since I was unable to find an automated version (other than manual nexus/repo-plugins or maven-dependency-greps), I wrote a small java tool: reverseDependencies. Feel free to use if you come across a similar task. Note: it will check against the online Nexus-like repository or cache file that you specify.
This is something that is not part of Maven. But it can be implemented in Maven repositories like Nexus and Bintray. The closest I've found is in Bintray and its Build Integration.
But since my clients are using different Maven repositories I needed something that works for any repository. So I created Pom Dependency Analyzer Web that can keep track of dependents, and dependencies.
Typically, a maven built jar artifact will have it's pom included under META-INF. I recently noticed that the Spring jars don't have this. So, that causes me to wonder about the purpose of that pom.
It seems like maven retrieves the pom directly from the repository when it's doing things that require knowledge of the artifacts meta-data, e.g. when determining dependencies.
So, what's the embedded one for?
The Maven docs suggest two reasons for the pom in this location.
1) Merely for reference, as a convenience. As the docs say, it makes the artifact "self describing"
2) You can get at this information from within your application using Java. This enables the arfiact to auto-report it's version within the application.
http://maven.apache.org/guides/getting-started/index.html
The pom you will find in the repository is not necessarily the one used to build the artifact. It is aimed at the users of the artifact and can be customized when building your artifact.
The one included inside the artifact IS the one used to produce the artifact.
There are options to not have it included in the artifact.