I am planning to host some of my API jars in Git hub as Maven Repository.
I have some 3rd party dependent jars needed with my jars.
When user like to pull my API i like the 3rd party dependent jars also downloaded to the local repository. say the 3rd party jars are 5 and they are in different repository.
when user adds a dependency as my api with my githum repository url can maven automatically find api dependent jars and it fetch from different places into local repository ?
How can i do this ? do we have any way to do with this ?
This article describes the way to perform what you need: http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/
This plugin can help you to automate such task: http://synergian.github.com/wagon-git/index.html
Yes. Maven would be able to download all the dependent jars (based on dependencies mentioned in POM xml in your API).
Related
We are only using the basic feature of Artifactory for Ant-Ivy java projects. If we need new java libraries, we download JARs, craft ivy.xml, then "deploy" the bundle to our internal Artifactory repository. This has been working just fine. However, when we need a set of JARS that need many transitive dependencies, the tasks become very tedious. We don't use Maven and download JARS from Maven central does not provide ivy.xml file. I am wondering if there is an easy way to automate these process?
Thanks
You can try this Artifactory user plugin which generates missing ivy.xml files from .pom files.
Please note that using a user plugin will require the professional version of Artifactory.
We are using Maven to build our projects and Nexus as repository manager.
Is there a way to know where an artifact is a dependency of another artifact?
For example, we want to know which of the artifacts in our Release repository have a dependency on commons-io 1.2, or version x.y of our framework2, or ...
mvn dependency:tree should help you get this info.
Have you looked at the Maven Site plugin in conjunction with the dependencies and dependencies-convergence report from the Maven Project Info Reports plugin?
This will generate an html report that shows all the artifacts that the project uses and what other artifacts that are dependent on that artifact.
The Maven client will only tell you the dependencies of a single project. I'd recommend using Sonar as part of your build process. It's primarily used for source code analysis, but it will also report usage of a particular library by other projects in the same Sonar database.
I am working on converting websphere portal project to maven framework for CI build. I am wondering if there is a way to reference websphere jars other than via dependencies in pom.xml and loading them all to maven repository? I cannot imagine loading them ALL to the repository...
Please advice! Thanks!
When using Maven, it is advisable that all dependent jars are installed in the repository. Even Websphere ones.
Ideally a corporate repository will come in handy here, so that you keep a separate repository for all the Websphere jars accessible to all the users in your project. See http://maven.apache.org/repository-management.html for more.
If this is not an option, then use the local file repository explained on a previous questions - here.
You'll still need to add each dependency in POM.
Also read http://sdudzin.blogspot.com/2007/09/maven-2-and-websphere-automated-build.html
if you have a lot of projects that require this, you can also create a parent pom that would have all the dependencies so your project/module/portlet poms are cleaner.
I have some proprietary.jar that I need to include in my project, but I don't wish to install it to the local repository.
What I did initially was to put the jar into version control in my project's lib/ folder, and then specify the Maven dependency as:
<!-- LOCAL DEPENDENCY -->
<dependency>
<groupId>topsecret</groupId>
<artifactId>proprietary</artifactId>
<version>0.0.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/java/proprietary.jar</systemPath>
</dependency>
However, this becomes a big problem when my project becomes someone else's dependency. Maven will not be able to validate this POM because the path is not absolute.
What is the best way to overcome this problem?
I think the first question that needs to be answered is, why don't you want to install it in the local repository?
Maven follows a convention over configuration philosophy, so the more you fight "The Maven Way" the harder things are going to be for you. Unless you have a compelling reason for not installing the jar to the repository, that seems like the best solution to me.
If you are concerned about unauthorized users gaining access to the proprietary jar, there are alternative solutions such as using a repository manager like Nexus or Archiva.
I described in a previous answer how you can setup a file based repository and avoid the evil system scope when you can't use a corporate repository. Check it out.
For third party artefacts, it's cleanest and least pain free to create a separate repository dedicated to 3rd party artefacts. This makes it easy for anyone else in your team to build your project.
For example, I'm using Nexus (community editoin) to manage maven artefacts. When someone has a dependency on a 3rd party lib not in maven central, we add it to the third party repo. This allows everyone else to build without having to manually find and download the artefact.
Nexus supports various authentication strategies, including LDAP, so can guard sensitive artefacts from unauthorized use. Since moving to a repository manager, managing artefacts, particularly 3rd party artefacts has become a whole lot easier.
See
Repository management with Nexus
PS: Another plus with Nexus is that you can create a "virtual" repository that is the composition of several repositories "flattened" into one. This puts an end to adding repositories to settings.xml or putting repositories in the project pom. You can dd your own repository, your 3rd party repository, and other popular repositories (central, apache, codehaus, jboss etc...) and set nexus up as a mirror. All requests then go through Nexus, speeding up the build and easing repository configuration.
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)