I'm having a problem on my machine where a specific dependency is not being resolved causing a ClassNotFoundException at runtime. Running grails dependency-report on my machine shows the artifact in question as having no dependencies, while on another developer's machine it shows dependencies properly.
Why would grails on my machine think the artifact has no dependencies, yet on another developer's machine the dependencies are correctly shown?
All other dependencies are resolved. Just this one artifact is not having its dependencies resolved on my machine.
Environment: Grails 1.3.7, Java 1.6.0_29
Problem solved. It had to do with our local Artifactory having a bad pom. Our artifactory is actually composed of multiple repositories that are exposed as one virtual repository. The artifact in question was contained in two of those repos. One of the repos had a pom showing no dependencies for the artifact. This repo took precedence in the "virtual" view. We removed the corrupted version and then things started working.
How/why our Artifactory got this pom is still a mystery. But somehow it happened between the time my co-worker built out their environment and when I built out mine.
Related
I'm using maven 3.1.1 and am working on a big Java project in which we have a large number of dependencies on different components of the Spring Framework. Whenever I build via mvn clean install the build takes forever. I've looked at the terminal, and essentially the build takes long because maven is trying to download metadata from a source from which it can't establish a connection:
It basically blocks here:
Downloading: http://source.mysema.com/maven2/releases/org/springframework/spring-beans/maven-metadata.xml
After a while, I'll get a connection refused before the client can even proceed any further. I have no such direct dependency from source.mysema.com so I'm not exactly sure why maven would even attempt to download from here.
A few questions:
1) How does metadata actaully work? When does maven actually attempt to pull this information? Does metadata exist for every dependency, or is this repository-specific?
2) Is there a way to force a timeout on the client to not pull this metadata if it can't establish a connection after let's say, 2 seconds?
3) I've looked into our own internal repository in which this project depends via the <repository> tag. In trying to debug this issue, I've looked directly at our Nexus repository and saw that the metadata.xml file contains a huge list of versions for this specific Spring dependency. Why should my build always download ALL the versions for this dependency?
My suspicion was that my repository definitions in my pom.xml was causing maven to download from that source.mysema.com transitively (via some remote repository I've definied). So I commented out all my repository definitions in hopes that maven wouldn't talk to any remote repositories and instead pull out dependencies from my local m2, but somehow it keeps trying to download from source.mysema.com.
Thoughts? Thank you.
Answering your questions
1) How does metadata actaully work? When does maven actually attempt to pull this information? Does metadata exist for every dependency, or is this repository-specific?
Answer : maven-metadata is downloaded since you have specified Release into one of your version tags for eg
<spring.version>3.2.4.RELEASE</spring.version>
So now with daily build, you will see the metadata being downloaded as maven checks for latest build versions for this release. You will be seeing something like this in your screen
Downloading: http://nexus.mynexuslocation/nexus/content/repositories/public/org/springframework/spring-tx/maven-metadata.xml
Downloading: http://central.maven.org/maven2/org/springframework/spring-tx/maven-metadata.xml
Also check the updatePolicy in your pom.xml if it is has been set to daily
2) Is there a way to force a timeout on the client to not pull this metadata if it can't establish a connection after let's say, 2 seconds?
Answer : Not sure of this one.
3) I've looked into our own internal repository in which this project depends via the tag. In trying to debug this issue, I've looked directly at our Nexus repository and saw that the metadata.xml file contains a huge list of versions for this specific Spring dependency. Why should my build always download ALL the versions for this dependency?
Answer : You have to move nexus repository up in the hierarchy. Maven will look at nexus first and only when not able to find it, will go outside nexus.
We have a project where I upload the artifacts to a nexus repository using ant and ivy. Things have gone smooth for a long time, but now we must deploy the same artifact twice (because we are generating the same product for windows and mac). The code of the application is the same, it just changes the packaging. I have configured the deploy process to use a maven classifier. The problem is that the uploads are done from 2 different machines because each one has the appropiate build environment for the destination platform.
So, the first deploy is done right and it uploads:
myproduct-1.0.pom
myproduct-1.0-mac.zip
When I try to deploy the windows artifact, that will deploy
myproduct-1.0.pom
myproduct-1.0-win32.msi
It fails because the repository policy does not allow redeploying (and it should stay that way), so trying to deploy a new pom file for the same artifact and version fails, even if the pom contents are the same.
Also it is possible that in the future we have a similar problem, deploying various artifacts of the same product and version but different classifier from the different machine but in different build processes.
Is it possible to tell nexus to not fail if when deploying a classified artifact with a pom, does not fail if the same pom file already exists in the repository? If it is not possible, I understand that the only way to deploy various artifacts with different classifiers is to deploy them all at the same time. Is it true?
In the end, I created a task that deployed just the pom without any classifier, and modified the deploy of the windows & mac artifacts to just deploy the packages but not the pom:
deploy pom without classifier
deploy mac artifact with classifier (mac)
deploy win artficat with classifier (win32)
Nexus doesn't complain when deploying the artifact without deploying a pom file at the same time when I thought I would complain.
I feel it's a dirty trick, but it works :)
We are using maven in the development process. Maven provides a nice feature of configuring the repositories. Using this feature I have created a remote internal repository and I can download the dependencies from that repository.
The development machines are pointing to this remote internal repository. Each development machine has its own local repository(~/.m2/repository/) and hence the dependencies of the project are downloaded from the remote internal repositor**y to the **local repository(~/.m2/repository/) on each developer machine.
Is there any way that the local repository(~/.m2/repository/) on developer machines can be set to the internal remote repository that we have created and which is used for downloading the dependencies from.
If take a look on Maven Introduction to Repositories first paragraph says:
There are strictly only two types of repositories: local and remote.
There is no way how you could change this behavior.
If you would handle that differently it would cause many problems. E.g. build would take much longer because of downloading file all files, IDE would work not work properly (project dependencies would not be stored local), ...
May I suggest another approach to share dependencies and artifacts. In our projects we use nexus as a proxy and repository for our artifacts. It works well with no issues. A basic configuration I already posted here.
After nexus is running you could also setup continous integration using jenkins and enjoy a fully automated environment.
Is your requirement to avoid each developer from having to download all dependencies to his local repository?
Assuming your remote internal repository has the same format as a maven local repository, you can achieve this by adding the following line in the settings.xml of all your developers.
<localRepository>shared-drive-location-of-remote-repository</localRepository>
My environment is STS 2.8.0-M2 with Grails 1.3.7. I have a Grails project and a plain Java/Maven project in my workspace.
I am used to M2Eclipse workspace dependency resolution for plain Java/Maven projects and I'd love to see something similar working with Grails. According to the docs it appears like Maven dependencies can only be pulled from a repository or a flat directory but NOT from another plain Java/Maven project in the same workspace. As far as I know, that's a feature coming from M2Eclipse, but enabling this one on the Grails project just causes STS to crash and I assume that it would still conflict with Grails even if I would use the Grails Maven plugin.
Do you guys have any advice or practical experience how to enable workspace dependency resolution with Grails in STS 2.8? I want to avoid having to rebuild a dependent project during development over and over.
Thanks!
For Beta/UAT releases I use artifactory to deploy my jars and grails picks up from the local artifactory with the mavenRepo variable in BuildConfig.groovy pointing to the local artifactory.
eg
mavenRepo "http://maya:8081/artifactory/plugins-release-local/"
Development environment:
1)For plugins I use the line
grails.plugin.location.'plugin-name'="../PluginProject"
2) For normal java project I reference it directly using the build properties of the java project.
BuildConfig.groovy fulfills all my requirements and I never used maven in grails projects
Good day,
I'm trying to integrate our company's Grails plugins into our Maven repositories (our repositories are named 'snapshots' and 'releases').
To do that, I installed the maven-publisher plugin in all of our plugins, and I'm deploying them using the "grails maven-deploy" command. This works well.
However, if I deploy a SNAPSHOT version of a plugin (say, version 1.0.0-SNAPSHOT), it gets properly deployed in our repository, but I can't install it in our applications (using version "latest.integration").
I'm using Grails 1.3.7.
First of all, when deployed, the actual artifact name has a timestamp added to it ("blablabla-1.0.0-20110421.122823-1.zip"). However, the version is still 1.0.0-SNAPSHOT. I'm guessing that it's Maven that does that transformation.
However, Ivy doesn't seem to understand the transformation, or to handle SNAPSHOT versions. I get errors like:
==== http://myRepo/repository/snapshots: tried
-- artifact myOrg#blablabla;latest.integration!blablabla.zip:
http://myRepo/repository/snapshots/myOrg/blablabla/[revision]/blablabla-[revision].zip
Initial research has revealed that I could create a resolver pattern, but that seems a little bit complicated for something that should work out of the box, and my initial tests were not conclusive anyway (I tried a few patterns, none of which worked).
I should note that deploying my plugins locally using the "maven-install" command works, because the script create an artifact with the proper version (blablabla-1.0.0-SNAPSHOT.zip) alongside the one with timestamps.
Does anybody have a solution?
Thanks!
Guillaume.
I resolved this modifying Artifactory snapshot repository configuration:
<snapshotVersionBehavior>non-unique</snapshotVersionBehavior>
Now when you have foo-plugin-1.0-SNAPSHOT.zip and you upload it the name stays same.