dependency-management

When IntelliJ opens a build.gradle file it will generate an IntelliJ project with the Gradle dependencies resolved and added to the project scope. This works great for the "compile" source set and the "test" source set, however I can not get this to work for custom source sets. I want to have IntelliJ resolve the dependencies for my componentTest source set. How do I tell IntelliJ to resolve these dependencies and add them to scope? dependencies { // main source set, "compile" scope in IntelliJ compile(group: 'com.google.guava', name: 'guava', version: '18.0') // test source set, "test" scope

We develop .NET Enterprise Software in C#. We are looking to improve our version control system. I have used mercurial before and have been experimenting using it at our company. However, since we develop enterprise products we have a big focus on reusable components or modules. I have been attempting to use mercurial's sub-repos to manage components and dependencies but am having some difficulties. Here are the basic requirements for source control/dependency management: Reusable components Shared by source (for debugging) Have dependencies on 3rd party binaries and other reusable components

I'm just cloned a repo , which recommends the use of Yarn to install dependencies. When I run yarn install , it seems to be okay, but it provides this warning: yarn install v0.20.3 [1/4] 🔍 Resolving packages... [2/4] 🚚 Fetching packages... [3/4] 🔗 Linking dependencies... warning "sass-loader@4.0.2" has incorrect peer dependency "node-sass@^3.4.2". [4/4] 📃 Building fresh packages... ✨ Done in 77.59s. I've looked online to find out exactly what "has incorrect peer dependency" means. But all I can find are reported issues on other repositories or questions about how to fix the problem. Can

I've created an environment and added a package django-paramfield via git: $ pip install git+https://bitbucket.org/DataGreed/django-paramfield.git Downloading/unpacking git+https://bitbucket.org/DataGreed/django-paramfield.git Cloning https://bitbucket.org/DataGreed/django-paramfield.git to /var/folders/9Z/9ZQZ1Q3WGMOW+JguzcBKNU+++TI/-Tmp-/pip-49Eokm-build Unpacking objects: 100% (29/29), done. Running setup.py egg_info for package from git+https://bitbucket.org/DataGreed/django-paramfield.git Installing collected packages: paramfield Running setup.py install for paramfield Successfully

One of the dependencies declared in my project has a transitive dependency on 'com.google.guava:guava:15.0' . But my application deployed on WAS/Weblogic doesn't work due to a CDI issue which has been fixed in 'com.google.guava:guava:15.0:cdi1.0' . (same version, but with classifier) I need to tell gradle to use this jar during build and packaging. I am trying to figure on how we can ovrride this transitive dependency with a jar specific version classifier. Tried the following approches: Added the dependency explicitly: compile 'com.google.guava:guava:15.0:cdi1.0' . But both jars got included

I have too many files in .m2 folder where maven stores downloaded dependencies. Is there a way to clean all old dependencies? For example, if there is a dependency with 3 different versions: 1, 2 and 3, after cleaning there must be only 3rd. How I can do it for all dependencies in .m2 folder? If you are on Unix, you could use the access time of the files in there. Just enable access time for your filesystem, then run a clean build of all your projects you would like to keep dependencies for and then do something like this (UNTESTED!): find ~/.m2 -amin +5 -iname '*.pom' | while read pom; do

I have a project with src/main/java and src/test/java structure, and I managed to use maven-jar-plugin to build a jar of the test branch. However, I want to package the test jar so that all the dependencies are resolved. Is there a way I can tell maven-jar-plugin to include the dependencies?? Thanks! Frank In a similar situation I ended up moving my test code to a separate jar and made it depend on the original one. You can use an aggregator project to ensure that tests are run when you build the main jar. I had a similar problem with integration tests I need to run on Hadoop. Our integration