We are using Ant+Ivy and I am a newbie on Artifactory. One very basic question is that we always publish resolved ivy.xml along with artifacts into the Ivy repository, but in Artifactory, I am confused if we should publish ivy.xml or pom.xml? Artifactory suggests to use a maven2 compatible layout so it's easy to migrate to Maven in the future.
You can store both ivy.xml and pom files in Artifactory, it will give you the ability to migrate to maven (if you wish), although Artifactory fully support automatic conversion of layouts from ivy layout to maven2 layout and vice versa. You can also use the convention user plugins to generate ivy.xml out of pom.xml and vice versa as well.
Here are the docs on Artifactory Ivy support.
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 SVN as a Maven Repositary. We knew that it isn't advisable to have SVN backed maven repository, but still we have to go with it due to limitation within our organization. SVN backed repository used currently is partially implemented.We have developers working from two different geographical location. Problem we face now is whenever a developer adds a artifact to maven repo(svn repository) all other developers have to update the local svn view manually to get the newly added artifact before we do mvn clean package.
IS there a way to automatically download the artifact from svn maven repository to local repo if the artifact doesn't exists locally?
SVN is hosted with a webserver so maven repositary is accessed using HTTPS protocol only. We use maven 2.2 version.
I tried with wagon plugin which would deploy the build output(jar\war) to scm directly. We are not interested in deploying the build outputs. We need a solution to download artifacts automatically from svn maven repo if it isn't exists locally?
You make no mention of how your SVN repository exposes it's artifacts to the development teams. If it truly a Maven repository (conforming to the standard Maven repository layout) then you could just specify it's URL in the "repositories" section of your POM. Updating the local repo would then no longer be necessary.
I suspect that what you have checked into subversion is not a Maven repository layout? You'd lose one of the key benefits of using subversion if each new version of an artifact was being checked in as a new file....
You are describing the functionality offered by any Maven repository manager, for example: Nexus.
I understand your reluctance to embrace a new repository technology, but SCM systems like subversion are primarily designed for tracking changes to textual files.
In conclusion, if you truly wish to keep subversion in the loop I'd suggest one of two options:
Use subversion to control the contents of the local repository. (3rd party dependencies and the artifacts generated by the developers)
Use a repository manager like Nexus. Let Nexus manage cached content from external repositories, but commit the contents of locally hosted repositories into Subversion.
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.
What would be the mechanism to deploy rar artifacts if they are not present in the repository. (e.g. I would like to deploy jackrabbit to my j2ee application, but it is not available as part of the maven repositories. Should I have to store the binary locally in SVN and use the antrun plugin to copy it?
A more specific answer to your question however is that Jackrabbit is available in the central repository:
http://repo2.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jca/2.0.0/
You can include it with:
<dependency>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>jackrabbit-jca</artifactId>
<version>2.0.0</version>
<type>rar</type>
</dependency>
One would typically use an enterprise repository (like Nexus) for this. If this is not an option, have a look at this previous answer for a way to store dependencies in your version control system.