I have a configuration with local, shared, public resolvers. I would like to create a report after resolving a module that tells me which resolver actually satisfied each dependency. Say my module depends on bar 1.2.+, and the public resolver provided bar 1.2.3, the report would say resolved bar 1.2.3 from public
The Ant task ivy:report is the way to go: http://ant.apache.org/ivy/history/latest-milestone/use/report.html
Then look at the xml attribute: ivy-report/dependencies/module/revision/#resolver
Related
I'm trying to create a GroovyDSL script which references some external libraries. Here's my script:
import com.github.javaparser.ast.Node
import org.reflections.Reflections
def ctx = context(
ctype: 'groovy.util.ObjectGraphBuilder',
paths: ['com/example/scripts/.*'],
filetypes: ["groovy"]
)
Map<String, Class> candidateClasses = new Reflections(Node.packageName).getSubTypesOf(Node)
.collectEntries { Class type -> [(type.simpleName.uncapitalize()): type] }
contributor(ctx) {
candidateClasses.each { String methodName, Class type ->
method name: methodName, params: [props: "java.util.Map", closure: "groovy.lang.Closure"], type: type.name
}
}
Trying to enable it in Intellij, I'm getting:
startup failed: transformDslSyntaxgdsl: 1: unable to resolve class com.github.javaparser.ast.Node
# line 1, column 1.
import com.github.javaparser.ast.Node
Now, I have the proper external dependencies declared in pom.xml, the rest of the code that depends on them is working just fine. I've also put the script inside a source folder (which some other answers here suggested might be relevant).
I have seen some examples for GDSL reference Intellij types like PsiClass, which tells me the classpath for GDSL files seems to be different from the project classpath. Is there any way to make sure project dependencies are appended to that classpath?
I also tried using #Grape only to get this error. Adding Apache Ivy as a dependency doesn't help, because again, project dependencies don't seem to influence the GDSL classpath.
After a bit more digging, I found that it is pretty easy to modify the IDE's classpath itself.
All you need to do is to drop a dependency into Intellij installation directory's lib subfolder, and reference the jar inside classpath.txt.
Initially, I added the jars my GDSL depends on directly, but then I realized I could simply add a dependency on Apache Ivy to classpath.txt instead and #Grab annotations would start working.
I have two modules - core and auth. In auth module I am trying to integrate Google Sign In to Firebase. All dependencies resolving correctly, but not a GoogleSignInClient. I don't want use dagger for this entity to provide this client somewhere. I want to use it only in this class. But dagger shows me an error :
class file for com.google.android.gms.auth.api.signin.GoogleSignInClient not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.google.android.gms.auth.api.signin.GoogleSignInClient not found
e: D:\Projects\<project path>\build\tmp\kapt3\stubs\internalProductionDebug\<class path>\di\components\AppComponent.java: error:
[ComponentProcessor:MiscError] dagger.internal.codegen.ComponentProcessor was unable to process this interface because not all of its dependencies could be resolved. Check for compilation errors or a circular dependency with generated code.
Unfortunately it wasn't dagger problem. It happens with using several Android modules when you use api and implementation in gradle incorrectly.
I don't know why, but when I fixed my dependencies in Gradle - all become working.
I've got a number of SMS providers, each in a separate directory in the file system. The main class inside each provider directory extends abstract class ProviderAbstract.php which is located elsewhere in the filesystem and outside the provider directories.
I want to make each provider a separate composer package so it can be developed, tested and deployed independently. The problem is the ProviderAbstract class that each provider extends... what is the best approach in this situation? having a copy of the class inside each Provider package isn't the solution.. what is the best approach to resolve this type of dependency..
Thanks in advance
I don't know if this is the correct way. If you have a log at e.g. Monolog or Swiftmailer, they all have the "Providers" inside their one composer package. They can develop one Provider without looking at the others, testing them and deploy the whole package afterwards. If you decide to put components so small into own composer packages, you will end up with much overhead.
However, if you want to go on with that, you could extract the abstract class into it's own composer package and have all the other packages have this as a dependency. This is the way the PSR3 logger interface is used.
I have a main plugin project which does not depend on any of Eclipse APIs. But I do want to use Eclipse API's in one of its fragment plug-in. Will it cause any problem for the main plugin?
If you add a dependency (to a plug-in or a package) in a fragment, then you effectively modify the class path of the host project as well. Whether that will cause any changes to the semantics of the host project or any other fragment for the same host project, depends on the specific use in the project.
Having said all that, the normal answer is: no, it should not cause problems, unless you have code that depends on the class path - e.g. if you are using Class.forName(...) or similar...
One final note: when you test this, use -clean argument in the launch configuration to force OSGi to accept the changed dependency. Otherwise, it will be ignored.
I'm happily using the Maven bundle-plugin to create OSGi manifest headers for my modules. However, when there are configuration files that pull in classes which aren't referenced directly in the code, the plugin can't tell which packages it's going to need.
One example is a bundle with domain models that constitute a Persistence Unit for JPA. The driver class is part of the PU configuration and either set in an XML file or at runtime when the EntityManager is instantiated. I have to manually add an Import-Package header for the driver class that I want to load, or I get CNF errors.
Another example is a Struts war, where the web.xml pulls in the Struts dispatcher that's otherwise not found anywhere in the code and has to be manually added to the headers.
How can I avoid this?
I tried adding the required packages as dependencies with a provided scope, but that didn't help.
In the plug-in section of the bnd configuration you can specify plug-ins to analyze these files and contribute to the import-package header. For spring it looks like this:
<_plugin>aQute.lib.spring.SpringComponent</_plugin>
I am not sure, what descriptors are supported on top of spring. Just take a look at the source (it's in the Apache Felix SVN) and see for yourself. In the worst case you have to write your own plug-in, but at least it is possible! Also peter kriens site about the bnd explains the usage and some internals.
Other then that I am not aware of any simple solution.