I have two detected dependencies with the same name (different paths) showing up in my setup project's detected dependencies. One's the "old" one, at an old path. How can i determine which portion of my primary project is causing the "old" one to show up? I can probably do it by trial and error, but is there a quick/direct way?
If you are using ReSharper you can right-click on the dependency and ask for the depenent code fragments.
Otherwise I would remove the dependency and look where the compiler gets errors.
I figured out the easiest way was to right click on each potential parent (only about half a dozen) and choose Dependencies ... working through them till I found the culprit.
Related
I have two pairs of projects that I develop in NetBeans, both of which have a GUI project, and a library project, where the GUI project depends on the library one. In one of them, NetBeans recognizes that the dependency is local, and indicates as such with an Ma symbol, as seen below, with the dependency project in green:
This provides some nice functionality, most notably that the "Navigate to" (ctrl+click) functionality from the GUI project takes me to the source code in the library project. I also don't have to manually rebuild the library project for the GUI project to pick up any changes.
However, for the other pair of projects, NetBeans will pick up that the dependency is in my local Maven repo, but does not recognize that the source code is a Maven project that it also has open:
I've tried looking through all the right-click menu options, removing and re-adding the dependency from the NetBeans GUI, comparing the pom.xml, comparing nb-actions.xml, and nb-configuration.xml, but cannot find any explanation of why one library is recognized as local, but the other is not. The only information I've found online is at http://wiki.netbeans.org/MavenBestPractices, where it notes:
"Hint: If you open a project that other projects depend on, the icon in other projects changes to a "maven project" icon to denote that the IDE knows about link between the projects. However such a link is only established when the groupId, artifactId and version all match in the dependency and project declaration. Frequently occurring problem is that you change an API signature in your library project, but the application is not picking up. Often it's caused by the fact that the application is using an older version of the library artifact. The artifact icon can help you track down these problems."
However, I've verified that the pom.xml of the GUI project depends on the version being built in the library project, and even made the versions identical between the GUI project and library, and the "maven project" icon still doesn't show up.
Does anyone know how to debug this issue, or if there's a magic setting somewhere that I'm missing for how to make this link work? I've been trying with both NetBeans 8.2 and 8.1, and am compiling with Java 8 for both the successful pair of projects, and the unsuccessful ones.
Revisiting the project a couple years later, I finally figured out a way to get the dependency to connect locally.
Change the artifact ID of the dependency, and update the dependent pom to match the new name.
This is admittedly bypassing the root issue rather than addressing it, but given the inability to pinpoint the root cause, seems the best option at this time.
I'm relatively new to Android Studio and find myself very confused about the levels for dependencies in Gradle. Let me explain why, then I am seeking assistance with a specific issue and the broader issue of choosing dependency levels. I should mention that I am using Android Studio 3.1.3 with Gradle 4.4. My Min SDK Level is 24 and my compile level is 27).
I am doing my first experiments with Settings and have skimmed several tutorials (online and in YouTube). They all begin with the advice that you need to add a dependency for Preferences in your Gradle file. (They aren't consistent in WHICH dependency to add but I think that's because there are different approaches to doing preferences.) In any case, once you've chosen which approach you are going to take, you need to add the appropriate dependency to your build.gradle (Module app) file.
So, let's say we decide to add com.android.support:preference. According to the manual - https://developer.android.com/reference/android/support/v7/preference/Preference - the current version is v7:28.0.0-alpha1. If I add that to the Gradle file though and try to sync, Android Studio tells me I should not let the dependency be a higher level than the compile SDK level (which is 27).
So, I imitated the level that I used in other dependencies, like appcompat, and set the level to v7:27.1.1 and tried to sync again. That failed too. Apparently, no such version of the dependency exists.
Most of the tutorials I've seen are two years old and refer to dependencies that are at level 24, which I assume is going to be too low.
And that brings me to my question: How do I determine which versions of a dependency actually exist so that I can choose an appropriate level?
I read through this page on the Android developer site and I suspect you may have the syntax wrong for the dependency. The v7 should be part of the module name, not the version as I understand it.
Try:
dependencies {
implementation "com.support.android-v7:27.1.1"
}
This page makes reference to palette-v7:27.1.1 so I assume the same version exists for preference.
While searching for maven dependencies on mvnrepository.com, it shows one column with usages. What does it mean?
i.e. https://mvnrepository.com/artifact/org.springframework/spring-context when you click on this link it will show you different jars with version number and also it shows you one column called usages. Usages contains some numbers.
If you click through the 'usages' button you see the projects that are also listed (i.e. in maven central) which have that project as a dependency. If you pick a project from the 'usages' to click into and then click on the most recent version and look at the 'dependencies' section then you find the project that you started from in that list somewhere. At least I suspect it's based on the dependencies of the most recent version but it could be that it's used in a/any version (haven't been able to determine that from my clicking around).
Did you click on the number and see the information it shows you?
i think it means how many mvnrepository.com maven project dependenied it
When I click on the library,
It appears to be Used by (numeric) artifacts.
So my guess is, to put it simply
I think it's the number of other libraries that used that library.
As the people above have already explained.
I am cleaning up dependencies from the build.gradle file for a big-sized Java project. How do I identify the usage of a certain dependency in the code-base ?
The solution that comes to my mind right away would be to remove the dependency and run compile to see if it was needed. You can of course skip checking the ones you are sure that are needed. If there's a lot of suspects you can comment out several at a time and if build fails and you don't know which one is a valid dependency, you can use binary search ;) to speed up the process.
I have a maven java project in Eclipse IDE, and it needs to communicate with components on a weblogic server. When I first coded this, it worked without importing too many jars. However, I needed to make my project a part of a bigger assembly, and now my dependency requirements have gone out of control. I am still a little new to maven, and how it integrates with eclipse, but I've found that most of my ClassNotFoundExceptions points to classes that do exist, but with slight variances in path. See image below.
I suspect that I have imported a wrong library somewhere in the beginning of my dependencies, that now seems to be dependent on a great big tree structure of Classes that actually already exist, but with another path, and I'm stuck retrieving each of them individually, when they are already there...
Just look at the image: I have com.sun.xml.internal.bind.marshaller.SAX2DOMEx.class, but not com.sun.xml.bind.marshaller.SAX2DOMEx.class
Am I right in assuming that I am trying to fix symptoms, when I should focus on fixing the cause? If so, how can I retrace my imports, and find the root cause, in other words where I start importing the wrong jar?
#KjetilNordin,
You wrote:
I've found that most of my ClassNotFoundExceptions points to classes that do exist, but with slight variances in path
This suggests that somewhere along the way, one or more of the jars you depend on has 2 conflicting versions, between which the class moved between different packages. Maven's dependency resolution mechanism is resolving the jar to the version where the class sits in a different package from where you expect.
Run mvn dependency:tree on your project to see the entire hierarchy of transitive dependencies organized so you can track what depends on what. You'll likely see your jar come up in multiple locations, and presumably the wrong version is getting precedence in terms of Maven version resolution.
Next decide which version you want to go with.
Finally, add a <dependencyManagement> block in your pom.xml file to force the version to match your desired version.
Hope that helps.