After reading this question, I don't understand how we can find the configuration of the dependencies.
More precisely, in the example below, how retrieve the configurations (proxool,oscache) of hibernate ?
<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>
You have to look into hibernate's ivy.xml to see the list of all published configurations. Either you resolve the dependency and take a look into your local cache, or you can view the ivy.xml directly in the repository you are using.
Note: When you resolve from a maven repo there will be some translation/mapping from the POM to the ivy.xml.
Related
I can't get Ivy to update cache when snapshot dependencies are updated. The resolver (to has the following settings:
<url name="xxx" m2compatible="false"
checkmodified="true" changingMatcher="regexp"
changingPattern=".*-SNAPSHOT.*">
An example artifact filename (in Artifactory) is:
my-jar-1.999-SNAPSHOT.jar
A detailed Ant log of resolve includes:
[NOT REQUIRED] com.myorg#my-module;1.999-SNAPSHOT!my-jar.jar
There is no POM on the artifact.
The resolver is underneath a chain resolver; they both have all the relevant attributes set. I have read https://issues.apache.org/jira/browse/IVY-938 and https://issues.apache.org/jira/browse/IVY-1221, including all the comments, and AFAICT (perhaps incorrectly!) none of the workarounds are relevant.
Should I give up on snapshots and just use explicit versions with "integration.latest" dynamically versioned dependencies? I fear this may end up failing when we have integration builds happening for multiple major versions. At that point we'll need to split the major versions out into separate repositories, or put the major build number in the artifact name, or something equally clunky, just to make "integration.latest" work.
I'm not a fan of using the url resolver when talking to Maven repository managers.
The problem is Maven has special and rather unique handling for snapshot revisions..... The url resolver is better suited for use against ivy respositories.
I use Nexus, but the following should also apply to Artifactory. The following settings file sets up Maven Central and my two hosted repositories (Maven repositories come in two flavours, release or snapshot):
<ivysettings>
<settings defaultResolver="repos" />
<resolvers>
<chain name="repos">
<ibiblio name="central" m2compatible="true"/>
<ibiblio name="my-releases" m2compatible="true" root="https://myhost/releases"/>
<ibiblio name="my-snapshots" m2compatible="true" root="https://myhost/snapshots"/>
</chain>
</resolvers>
</ivysettings>
You'll notice I'm using the ibilio resolver which has internal logic to decipher Maven's special Snapshot handling.
When I require a snapshot revision I think declare it explicitly as follows:
<ivy-module version="2.0">
<info organisation="myOrg" module="Demo"/>
<dependencies>
<dependency org="myOrg" name="myModule" rev="2.7-SNAPSHOT"/>
..
</dependencies>
</ivy-module>
Under the hood the ibilio resolver is reading the Maven repository meta data files to determine which timestamped artifact should be fetched from the snapshot repository.
Update
I would suggest reading the following presentation:
Continuous delivery with Maven
It outlines pretty well the Maven philosophy separating releases from dev builds (or snapshots). It also explains one of the very clunky aspects of Maven... Two different ways to publish artifacts...
I suspect what you're trying to do is along the lines of the author which is setup a CD pipe-line. In that case every build is a potential release and should be treated as such (No dynamic dependencies which are allowed by snapshots).
I would suggest limiting snapshots to developer only builds. Only deploy release candidates. The problems with this approach will be in managing lots and lots of releases. Some of the repository managers (Nexus, Artifactory, Archiva) offer "staging" features which make it possible to certify or discard releases that don't pass your quality toll-gates.
Update 2
If you are using ivy to publish snapshots into a Maven repository then there are a couple of issues:
Ivy doesn't support the publication of snapshots with timestamps
Ivy doesn't update the Maven module's metadata.xml file
In my opinion time-stamped files is one of the killer features of using snapshots in the first place. With ivy it's only possible to provide the latest file (overwriting the previous latest file).
There are work-arounds to address these issues:
As suggested in the second link you can ignore metadata completely (setting the "useMavenMetadata" attribute to false) and default back to ivy's older mechanism of comparing file names. This only fixes the problem for ivy clients.
The repository manager should be able to regenerate the metadata files (Nexus at least has a task to do this).
Use the Maven ANT task.
The last suggestion is not as crazy as it seems. Firstly it's the only way I know to support timestamped snapshots and secondly the Maven client appears to do a lot of extra processing (updating the module metadata) that is largely undocumented.
After days of struggle...
The problem was that for
checkmodified="true" changingMatcher="regexp"
to work on a <resolver>, it has to be on every resolver in the hierarchy line - all parent <chain> resolvers and the <url>, <local>, or <ibiblio> resolver at the bottom.
I need to configure the jars in my pom.xml file in my web application in such a way that I need not use the lib folder to store all the jar files.
Please help.
If you really have dependencies which are stored in a lib folder (I assume those jar's don't exist in Central) you can use the system dependency
<dependency>
<groupId>...</groupId>
<artifactId>..</artifactId>
<scope>system</scope>
<systemPath>PathOnYourSystem</systemPath>
</dependency>
But i assume you mean something different, cause the above will procuce a warning on Maven 3. If you have a dependency which is provided by the Container (for example Tocmat) you can define a dependency as provided.
But the best is to put such dependencies into a local repository manager which i hope you are using (Artifactory, Nexus, Archiva).
You can mannually add them to your local repository (since it seems that they are not at central).
But the best would be to set up your own (or company) repository to hold them for you.
I want to setup jetty with jetty-blazeds extension. Everything looks fine but when I run maven to get the dependencies, I get:
UNRESOLVED DEPENDENCIES
com.adobe.flex#flex-messaging-core;3.2.0: not found
com.adobe.flex#flex-messaging-common;3.2.0: not found
I've tried many repositories but no success. I am wondering has anyone managed to successfully locate these dependencies through maven ? If yes, could you please share the repository !
Thank you,
-A
If you look at the pom of jetty-blazeds, for example jetty-blazeds-7.0.0.1beta3.pom, you'll see this:
<repositories>
<repository>
<id>project-repo</id>
<name>project repo</name>
<url>file:${basedir}/maven_repo</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
Jetty is using a file based repository. And if you look at this file based repository in their svn repository, you will see that it contains the mentioned artifacts (which are thus very likely not available in any known public repository).
So my suggestion would be to use the same strategy i.e. to install the artifacts locally, either in your local repository or in a file based repository in your VCS (you could also declare https://svn.codehaus.org/jetty/jetty/branches/jetty-7/jetty-blazeds/maven_repo/ as repository but this is extremely ugly).
If you have a corporate repository, the alternative is obvious: deploy the adobe artifacts in it.
It is recommended to set up a central Maven repository for your project/department and configure it in the project pom. Then you can download such dependencies by hand and deploy them manually to the project repo. Although this is a bit more extra work, it eliminates the whole class of problems in the long run.
I'd like to specify some artifacts that SHOULD NOT be downloaded from a remote repository, even if they are present there. Is there any way to achieve this in maven2?
Have you tried the offline mode?
mvn -o
Not sure if this is what you need, but you can declare a dependency with system scope, which tells Maven that a particular JAR is assumed to be in the classpath (e.g. one that is included in the java installation directory).
From the docs:
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
AFAIK, Maven treats the local repository basically as a cache of a remote repository, so there isn't any way to tell it not to get a particular dependency from a remote repo.
I'm not clear exactly what you're after, so here's answers to a few different interpretations:
If the artifacts are transitive dependencies, you can specify that the dependencies be excluded. See the Transitive Dependency Exclusion section of the Dependency Mechanism documentation.
If you want to make sure no artifacts are downloaded, you can set Maven to offline mode by passing -o as a command line switch, or adding <offline>true</offline> to your settings.xml
With the Nexus Maven repository manager, you can set up a proxy repository to the remote repository, and configure the proxy to block certain artifacts. You would do this by adding a "repository target" matching the artifact's groupId and artifactId, then create read permissions for the that target that the Nexus user doesn't have. Any user connecting to the proxy would then not be able to obtain that artifact. See the Nexus book for details, of configuring targets.
If none of these meet your needs can you elaborate on your question please.
One option would be to install a local copy of the file with the install-file mojo and give your copy a distinct name. Pre-pending "local." to the groupid name would make it easy to id in the pom files. If would also make it easy to switch out.
add it to your local repos like this:
mvn install:install-file -Durl=file://xmlthing.jar -Dinternal -Dfile=xmthing.jar -DgroupId=local.org.xmltool -DartifactId=xmlthing -Dversion=1.6.1 -Dpackaging=jar
You would then replace
<dependency>
<groupId>org.xmltool</groupId>
<artifactId>xmlthing</artifactId>
<version>1.6.1</version>
</dependency>
with
<dependency>
<groupId>local.org.xmltool</groupId>
<artifactId>xmlthing</artifactId>
<version>1.6.1</version>
</dependency>
Hi i am studying Spring In Action 2.0 and i am new to maven.
I am walking through the chapters and codes but i i got following error when i imported project through pom.xml on the pom editor in eclipse.
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activeio-core:jar:3.0-beta3:compile
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activemq-core:jar:4.0:compile
I downloaded the jar file and added to the library. still it does not work.
I am stuck what to do next? Can anyone help me with this?
Thanks in advance.
The referenced jars aren't available on the Maven2 central repository, so unless you have an additional repository declaration in your POM or an active profile in your settings, Maven will not know where to obtain the artifacts from.
There are a few public repositories like here and here hosting these artifacts.
To use these repositories you could add the relevant repository declaration to your POM or settings. See here for an example configuration.
Alternatively if you don't trust the repositories you could manually download the jars and put them into your local Maven repository, though you'd need to be careful to replicate the structure Maven expects, and you may well encounter the same problem for different jars.
Another alternative is to use a Maven repository manager like Nexus or Artifactory, to manage Maven's interactions with external repositories, though that is almost certainly too much information if you're just starting out.
For general help/information on Maven, check out the Maven book.