I'm working on a rect-native project and I'm trying to add a custom component to an already existing library. I want to add my own component to this library. I don't want to fork on the original project and create it there because my component will have different libraries and I think it will be harder to maintain a fork.
So I'm trying to import the project as a gradle dependency on a project of my own to import the original class AbstractMapFeature and extend its features to create my own class. I'm new to gradle and I don't even know if this is possible.
But if so, how do I import the project?
I tried through jipack:
allprojects {
repositories {
...
maven { url 'https://jitpack.io' }
}
}
dependencies {
implementation 'com.github.rnmapbox:maps:+'
}
But got an error stating that it couldn't find the project. The project doesn't compile to jitpack as can be seen here.
I also tried to install it as a node dependency and import it local from there:
maven {
url "$rootDir/node_modules/#react-native-mapbox-gl/maps/android"
}
But I don't know how to import this into my code. Tried with:
import com.mapbox.rctmgl.components.mapview.RCTMGLMapView
Which is the same import statement they use, but got an error saying it couldn't find rctmgl.
So I have two questions. Is it really possible to import the original project's code and use it on my own? And if yes, how do I do this?
Jitpack can't successfully work on any Github repo. If you look at the instructions for that library, there is a specific open source fork of the library called MapLibre, which is what you'll need (assuming this is an Android project, since I otherwise don't see anything Java/Kotlin-specific). The library is published on mavenCentral() so you don't need Jitpack. You should specify the library as
implementation 'org.maplibre.gl:android-sdk:9.4.0'
If you're just creating a subclass of a class in the library, that's just normal usage of a library. If you need to actually swap out code that's in the library, you will have to fork it. If you're forking it, none of the above applies. You need to create a forked repo, make your changes, build it, and use the build from your fork as a dependency in your project.
Related
Hey I have created a Maven Project in IntelliJ and added some dependencies in my pom.xml for using external libraries. But I always have to import the classes in the class where I want to work with the classes of these libraries.
For example one dependency:
<dependency>
<groupId>org.datavec</groupId>
<artifactId>datavec-local</artifactId>
<version>${dl4j.version}</version>
</dependency>
And I use this line of code in my class:
DataAnalysis analysis = AnalyzeLocal.analyze(schema, recordReader);
HtmlAnalysis.createHtmlAnalysisFile(analysis, new File("X:/Churn_Modelling/analysis.html"));
I must import DataAnalysis.
I mean it would be ok if I would import the right class by clicking on import, but it is the wrong one.
You must use imports in your Java source code. Maven dependencies do not replace imports.
They make imports possible, though. Without the dependency, the import will fail.
If you can import the class then it means the dependency is successfully added to class path whether it is right or wrong.
Then the question is, is there only one DataAnalysis class in the class path. You can check by ctrl+space.
If it is the only one, then I think it is dependency problem. Your dependency version is dynamic,
${dl4j.version}
So in the build time may be it has different value. You can check it, IntelliJ maven tool Dependency part. In different dependency version, the class path would be changed.
If you are sure about, downloaded dependency with version is what you need, then it but the class is not what you expect, then try to restart the IntelliJ with clearing caches mode.
Hope one of these helps you.
I'm using OkHttp3 to build up a simple connection API for a pure Java app, and I've run into a build problem that seems triggered by the fact that Square uses the same package name for multiple dependency artefacts.
I've seen some previous Q&A that discusses Maven dependencies and messaging from Eclipse, but all of those indicate that a Maven or Gradle build still works even if Eclipse annotates imports with module errors. In this case the Gradle build fails as soon as I simply add a dependency and make no other changes.
The app is a pure Java 11 module build. I'm using a very recent Eclipse with Gradle nature as an IDE, but I don't think this is strictly relevant. I'm using OkHttp3 to turn private endpoints into API, and one of those endpoints requires a CookieJar. Hoping to just use the default implementation, I add 'com.squareup.okhttp3:okhttp-urlconnection:3.14.9' as a dependency in a project that has already pulled in 'com.squareup.okhttp3:okhttp:3.14.9' as a transitive dependency. Both of these technically offer classes using the same package name: "okhttp3".
e.g., all I do is uncomment the dependency line seen in this snippet and save the build.gradle:
dependencies {
implementation ('com.squareup.retrofit2:retrofit:2.9.0')
implementation ('com.squareup.retrofit2:converter-gson:2.9.0')
implementation ('com.squareup.okhttp3:logging-interceptor:3.14.9')
// implementation ('com.squareup.okhttp3:okhttp-urlconnection:3.14.9')
As soon as the project refreshes I get annotations in Eclipse for all "okhttp3" imports:
The package okhttp3 is accessible from more than one module: okhttp3, okhttp3.logging, okhttp3.urlconnection
A clean build results in:
$ ./gradlew clean build
[...]
> Task :compileJava FAILED
error: the unnamed module reads package okhttp3 from both okhttp3.urlconnection and okhttp3
error: module retrofit2.converter.gson reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module retrofit2 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module org.apache.commons.io reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module httpcore5 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
[...]
I don't think it matters, but I'm using Gradle wrapper 5.6.4.
All OkHttp3 libraries, as far as I know, have set module info enough to satisfy Java 9+. The module stuff in Eclipse seems satisfied by that. It looks like neither Eclipse or Gradle like the fact that two different dependencies advertise their Java package as "okhttp3". It seems to me that any Gradle or Maven based project using Java 9 or higher will fail with split-package dependencies.
Based on some advice I read elsewhere, I've tried excluding 'com.squareup.okhttp3:okhttp' from all the dependencies that include it transitively and then pull it in separately, but this did not help (not that I thought it would, but I'm trying any hail-mary at this point).
Workarounds include hacks like simply dropping the two Kotlin classes I want into the project directly and renaming the package that way. This is an egregious hack, and is probably contrary to the library license. I can also implement the cookie stuff I need directly, but I'm lazy (though, apparently, I want to spend my energy solving this problem instead of implementing a cookie class using the interface I already have).
I feel like this is a bug on the part of Square and how they package these libraries/modules. Since their focus is so much on Android maybe I'm the only one who has wanted okhttp-urlconnection on Java 9 or higher? So, this Question is more about seeing if I should raise this as a defect, and also maybe I've overlooked something obvious.
It's OkHttp’s fault and we can fix it for you. Please open a tracking bug with a link to this issue.
We'll move those two classes to a new package. For backwards compatible we'll also need to leave delegating implementations behind. Hopefully the tools permit this!
It's too bad that JPMS has this constraint. We already fixed some of our other open source projects but didn't fix this one.
What is the key difference between includeBuild(...) and implementation(project(...)) in the Gradle build system? I cannot really see the usecase difference after reading the documentation:
https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:project_dependencies
https://docs.gradle.org/current/userguide/composite_builds.html#separate_composite
What I am trying to do: Share same codebase for two separate projects: data classes (kotlix.serialization), external database dao, interfaces. It is not a full library but just some code snippets.
How can I connect the two projects in Intellij so that type hinting works?
Composite Build (by using includeBuild) is a way to create a dependency between autonomous Gradle Projects.
Project import, is a way to create a dependency between two modules within a same Gradle Project.
Composite Build is far more powerful and is also meant to be the new way of factorizing gradle configuration between multiple projects that you traditionally do with the buildSrc technique.
I found this "Structuring Large Projects" article to be easier to read than the "Composite Builds" doc.
An excellent sample project that demonstrates the power of Composite Builds can be found in Gradle sample_structuring_software_projects.
Project dependency case
The tree would look like this:
settings.gradle.kts
module1/build.gradle.kts
module2/build.gradle.kts
And you are declaring a dependency in module1/build.gradle.kts like this:
dependencies {
implementation(project("com.domain:module2"))
}
The dependency will be resolved only if both projects are declared as sub-modules of a common root project.
It means you have a root settings.gradle.kts like this:
rootProject.name = "rootProject"
include(":module1")
include(":module2")
Composite build case
The projects do not need to have common "umbrella" root project.
Each project is a totally independent project.
One project can simply declare a dependency on the other project (without even the target project knowing about it).
Tree:
project1/build.gradle.kts
project1/settings.gradle.kts
project2/build.gradle.kts
project2/settings.gradle.kts
In project1/settings.gradle.kts:
rootProject.name = "project1"
includeBuild("../project2") //No more ':' as it is not a module
In project2/settings.gradle.kts:
rootProject.name = "project2"
In project1/build.gradle.kts like this:
dependencies {
implementation("com.domain:project2")
}
I have the same problem. Reading on the first link, the next para says:
Local forks of module dependencies
A module dependency can be substituted by a dependency to a local fork
of the sources of that module, if the module itself is built with
Gradle. This can be done by utilising composite builds. This allows
you, for example, to fix an issue in a library you use in an
application by using, and building, a locally patched version instead
of the published binary version. The details of this are described in
the section on composite builds.
So, it should be implementation project according to me.
P.S. The code completion is working on one of my sub project but not on the other. I am still trying to figure that out
I have 2 gradle projects. One is my custom gradle plugin and the other one is project which uses this plugin.
I know I can build my custom plugin, publish it to some repository and use it in my other project but is there any way how can I set something like "dependency" for my plugin (in build.gradle of my other project) and use it without need of building/publishing it somewhere?
To get and idea what I am trying to accomplish, here is some code which hopefully demonstrates the idea:
buildScript {
dependencies {
compile project(":my-gradle-plugin")
}
}
apply "my-gradle-plugin"
You can do that if your plugin project can be moved inside buildSrc of the project that wants to include it. In that case, the plugin will be by default on the classpath of the project.
If that plugin is shared between multiple projects, you will need to produce the binary and then reference it. Note that a local repository can be used, it does not have to be a remote one. One advantage of using a local repository is that Gradle will not cache the resolved plugin and thus any update, even without a version change, will be picked up immediately.
I am having trouble bringing in a subrepository in my project. The idea is that I bring a module in /arbitrary/folder and I want to include it on my current project located at /important/project
When using the GUI Import Module... from the menu the actual folders are copied into my project subfolder. Given that both projects are in different repositories there is a maintenance problem as for every update the files need to be manually reimported and then committed to the main project. Mercurial also doesn't allow you to have subrepos at any depth bigger than root.
What is the correct approach to solve this problem?
You're right that the GUI for Import Module makes a copy instead of importing it in-place. Until that functionality is improved, you'll need to set it up by hand.
In your module being imported, make sure it has a build.gradle file that's properly set up to build the module. Then in your application's settings.gradle file, include it like this:
include ':some_module'
project(':some_module').projectDir = new File('/path/to/module')
Then you can depend on it from another module in the usual way, either by adding a dependency through the Project Structure UI or by adding this to the module:
dependencies {
compile project(':some_module')
}