According to the concept of transitive dependency, if a project, say it A has dependency on X jar and is included in A's pom.xml. Now my second project, say it B has dependency on both project A and X jar. So now in my B's pom.xml I'll add only project A in its dependency, as X jar is served by A by concept of transitive dependency.
But instead of X jar if I have an Uber(shaded) jar then when I build project B, it fails saying packages included in Uber jar are missing. Means the concept is failing.
Please help me understand if I'm missing any concept or miss understanding transitive dependency.
The com.adobe.aem:uber-jar dependency typically has the <scope> set provided. This also the case for most AEM maven dependencies.
provided dependencies are not transitive, please read the maven doc on transitive dependencies: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
in the maven doc link above, please read the "Dependency Scope" section.
From the doc:
provided:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
Related
I'm implementing unit tests for code used in a Jenkins Pipeline Shared Groovy Library. Specically, I need to mock the steps object available in the Jenkinsfile, which is an instance of org.jenkinsci.plugins.workflow.cps.DSL. In my Gradle build I've specified a dependency like so:
testCompile group: 'org.jenkins-ci.plugins.workflow', name: 'workflow-cps', version: '2.30', ext: 'jar'
which is the project hosting the class above. Without specifying the ext as a JAR, Gradle retrieves the .hpi file since this is the packaging defined in the project's pom.xml; obviously I need to override this and fetch the JAR for my project. However, in doing this Gradle does not download the transitive dependencies of the workflow-cps JAR and I find myself having to populate my build.gradle with all the dependencies determined via trial and error. Is there a way to retrieve the transitive dependencies, or is this a limitation of the workflow-cps project and how it defines its pom.xml?
The CPS class you're wanting to mock won't contain methods/variables introduced by plugins or your workflow lib, so this approach probably won't be fully satisfying.
Facing the same challenge I took the pragmatic approach of making my own TestScript interface in my test sources and Mock that, and not typing the script reference in classes.
The drawbacks are not having IDE code inspection for stuff referencing the script, and having to manually add signatures to TestScript as I add tests (which is also error-prone, since I have manually ensure that those signatures match).
But it works, and avoids getting dragged into plugin dependency hell.
I was trying to add some Java Libraries (AWS SDK for Java, Apache Commons Math, etc.) to my Grails project since some of my Java source code (placed in src/java) had dependencies. By following this answer, I was able to resolve compile errors by adding the jar files to the /lib folder and add it to the build path, as answered here: Add Java Libraries to a Netbeans Grails Project
However, when I call my Java source code from my controller during runtime, it is unable to find the Java libraries that I added, showing a NoClassDefFoundError. Should I be adding something to the BuildConfig.groovy file? I'm not sure what the name convention for the jar files to be added to the dependencies.
The question you refer to is 5 years old. You should use newer resources :)
The preferred approach now is to use dependencies in BuildConfig.groovy, and let Grails (via Ivy or Maven) download the jars for you once and reuse them for various projects.
It's not always obvious what the syntax is, and I find that http://mvnrepository.com/ is a great resource. For example if you search for "commons math" and click through to http://mvnrepository.com/artifact/org.apache.commons/commons-math you'll see a few versions. Click on version 2.2 and you'll see the Maven dependency XML but you can click on the Gradle tab and it's going to be similar to what you need for Grails. So I'd add
dependencies {
compile 'org.apache.commons:commons-math:2.2'
}
and if necessary change compile to runtime, build, etc. depending on what you need the jar in the build process.
In the rare case that you do have a jar that isn't available in a Maven repo (e.g. a shared library at your company) then you can put the jar file in the lib directory. As you've seen, Grails doesn't auto-detect it (this is as of version 2.0). But you can run grails compile --refresh-dependencies to get your jar added to the classpath.
My issue turns out to be the fact that AWS Java SDK had dependencies (Apache HTTP Client) that were not installed yet and that I was unaware of.
This is what I had to configure this for my BuildConfig.groovy file
dependencies {
runtime 'org.apache.httpcomponents:httpclient:4.2.5'
runtime 'com.amazonaws:aws-java-sdk:1.4.7'
}
All the dependencies for AWS Java SDK 1.4.7 can be found here: http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.4.7. All the dependencies outside of HTTP client were already installed for me, but may not be for your Grails setup.
I want to generate a P2 repository from OSGI bundles that reside on maven central.
I have
defined a POM-first feature project using dependencies=consider
defined Maven dependencies with scope compile and type jar
defined a feature.xml with exact references to the bundle symbolic names and versions as declared in their manifest.mf
When I attempt to build the feature, I receive
No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-mapper-lgpl [1.9.12,1.9.13).", "Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-core-lgpl [1.9.12,1.9.13).", "No solution found because the problem is unsatisfiable."]
Where org.codehaus.jackson.feature is the feature I am building and jackson-mapper-lgpl [1.9.12,1.9.13) and jackson-core-lgpl [1.9.12,1.9.13) are the specifications of the OSGI bundles I am trying to include.
When I switch on debug mode, I see that the components are being found, which makes the behavior more odd:
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-core-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-core-lgpl/1.9.12/jackson-core-lgpl-1.9.12.jar resolves installable unit jackson-core-lgpl/1.9.12
[DEBUG] P2resolver.addMavenArtifact org.codehaus.jackson:jackson-mapper-lgpl:jar:1.9.12:compile
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-mapper-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-mapper-lgpl/1.9.12/jackson-mapper-lgpl-1.9.12.jar resolves installable unit jackson-mapper-lgpl/1.9.12
[DEBUG] Registered artifact repository org.eclipse.tycho.repository.registry.facade.RepositoryBlackboardKey(uri=file:/resolution-context-artifacts#/home/jsuess/workspace/org.codehaus.jackson/features/org.codehaus.jackson)
I believe taking bundles from maven and creating P2 must be a common use case, so I wonder if someone can point me to a working sample POM that I can use as a template.
Note that every module in a Tycho build has a separate target platform.
So if you are using pomDependencies=consider, but you only configure this switch and/or the dependencies on an eclipse-feature module, the POM dependencies will only be in the target platform of the module. If you then try to package the feature into an eclipse-repository, the dependency resolution of that module will fail because of missing (transitive) dependencies of the feature.
In most cases, you don't need different target platforms per module, so in general you should put all target platform configuration and POM dependencies into the parent POM.
If you have done this, but one of your modules still seems to have a different target platform, make sure that the parent POM reference of that module is correct - and that you don't reference an older version of your parent POM.
I have a Grail application that references a Java library (as an IntelliJ Module dependency). This works, but as soon as I add hibernate as a dependency of the Java library the Grails will no longer run.
Loading Grails 2.0.1
Error Error executing script RunApp: Provider for javax.xml.parsers.SAXParserFactory cannot be found (Use --stacktrace to see the full trace)
In my Java module, I am adding hibernate with the following:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>4.0.0.Final</version>
</dependency>
I can't see any good way around this. The Grails dependency-report does not show any libraries in conflict. The error occurs if the hibernate plugin is installed in the Grails application or not.
Bear in mind that (in this case) the Java library is not being incorporated via the BuildConfig.groovy. It is being incorporated as an IntelliJ Module dependency. If I incorporate the module as a jar via BuildConfig.groovy, everything works, but I lose the ability to step into the Java code.
Clarifying:
Per the JetBrains folks, the Java library is incorporated both as an IntelliJ Module dependency and in the BuildConfig.groovy. When executed from the command line, the project works, this is only an issue when starting from the IDE.
Suggestions?
Return dependency to java library to BuildConfig.groovy and use last version of IDEA: http://confluence.jetbrains.net/display/IDEADEV/IDEA+11.1+EAP . Navigation should work fine.
After experimentation, I stumbled upon the following which seems to be working very well (at least in IDEA 11.1):
Your Java library JAR should be referenced from the
BuildConfig.groovy (we use Maven, so we had to add the local Maven
repo as well)
Also reference your modules as module dependencies of the Grails module
(this is critical) in the run config for your grails project, uncheck the "add --classpath ..." option
The module dependency gives you:
Immediate awareness of the Java classes and their methods from the Grails project
Support for stepping into the Java code from your Grails project.
The BuildConfig reference gives you:
support for the grails commands, including run-app (which is how IntelliJ kicks things off when running/debugging a project)
If you leave the --classpath option checked, then you foul up the way that grails resolves its dependencies. There may be a better way to do this, but I haven't found it.
Additional Note
There's a bug in the interaction of grails and maven which causes grails to not pull in dependencies from local Maven 3 repositories if the pom.xml wasn't changed.
Therefore, our complete dependency refresh cycle looks like:
goto top
mvn clean install
find the relevant POM files in the repo and touch them
back to grails app directory and grails refresh-dependencies
run the app
You only need to do this when there are updates to the upstream Java libraries.
Hat tip to Sergey from Jet Brains for tracking that one down.
I'm working with IntelliJ IDEA 10.0.1 and Grails 1.3.7. I have a mavenized Grails project which depends on many logging libraries.
Here's the problem:
I have to use JCL as logging framework, but grails per default is working with SLF4J and has some default dependencies like jcl-over-slf4j, which are inherited by every grails project. First of all I have excluded every jcl-over-slf4j transitive dependency in my project pom file and verified with mvn dependency:tree that my pom is clean of any SLF4J bridging libraries.
But nevertheless jcl-over-slf4j is still beeing downloaded to my local maven repo when I try to start my grails app. This leads obviously to a StackOverflowError at runtime, since both jcl-over-slf4j and slf4j-jcl are in the classpath.
So because of which declaration the jcl-over-slf4j dependency is still beeing downloaded?
Since my pom is clean the obvious conclusion would be that Grails itself depends on those libraries. As mentioned before Grails has some default dependencies, on which every Grails project depends.
I know that I can exclude inherited depencencies in the BuildConfig.groovy file and if I run grails dependency-report I can also see that these dependencies are not listed anymore.
grails.project.dependency.resolution = {
inherits("global") {
excludes "jcl-over-slf4j", "jul-to-slf4j", "slf4j-log4j12"
}
}
But even then the jcl-over-slf4j dependency is still beeing downloaded to my repo when I start my grails app! Am I missing something? Is there a different way to exclude inherited grails dependencies when you're using a mavenized grails project?
Any help would be appreciated
Thanks!
Slash
Ok I think I got the answer now..
The problem is that the defined maven-grails-plugin (which is mandatory when you use maven + grails) within my pom file depends on jcl-over-slf4j and therefore gets downloaded when I start my application through maven. With my current maven version (2.2.1) it's not possible to exclude a dependency from a plugin. There is also a jjira issue regarding this problem. Can not exclude a dependency from a plugin
As soon as I remove the maven-grails-plugin the dependency is not downloaded anymore, but as drawback I'm not able to start the application through maven anymore..
Lessons learned: Don't use Maven + Grails + JCL in conjunction.
Note that with mvn dependency:tree just project dependencies are listed, but plugin dependencies are NOT listed.
Hope this is of any help!
Regards Slash