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')
}
Related
I need to figure out a quick/scripted way of excluding a set of folders across multiple IntelliJ gradle modules in an IntelliJ project imported from Gradle.
I have a Gradle multi-module project that I have imported into IntelliJ. The project is a refactoring of a legacy codebase into modules. Part of the resulted refactoring is that there are multiple copies of the same class across multiples modules (this was done to break dependency cycles in code): there is the original class and a number of "mock" copies
I'm trying to exclude a bunch of folders containing copies of classes in these "mock" sourcesets in a scripted manner.
I've imported the Gradle project into InteliJ. To begin excluding the folders I started by excluding one of the folders in one of the modules... ...
I then tried to determine where in my .idea folder this particular setting is persisted... I have been unable to find it...
My question is: can someone point me to the IntelliJ file (e.g. .idea/workspace.xml) that stores this setting? Alternatively can someone point me to the folder that stores this setting?
Update
I manually went and excluded all the folders that contain mock copies of my classes. Those settings appear to be persisted (still not sure where those settings are being stored).
The second problem I need to solve is that I need to declare custom dependencies between Gradle imported modules that are different from those configured in the Gradle project. I can add dependencies within the project, but whenever I refresh my Gradle project or import any changes, my changes are lost.
I'm not a Go expert, so I may be doing this in a way that is not the ideal approach for Go. Essentially, I have a main application that needs to be able to have plugins written for it. The plugins all adhere to a given format and are built with go build -buildmode=plugin. I don't want the end user to need to recompile the main application every time. Ideally, you should be able to drag and drop it to a new computer without issue.
To pass information between the plugins and the application, I have a third package defined called "common" that I treat similar to a C-header file. It only defines interfaces and a few integer constants that both can use. The application generates types that adhere to the interface and can pass them to the plugins to use.
When I compile, it seems to work fine, and the application can load the plugins using plugin.Open. The catch comes when trying to move the location of the common package. I built the original application in a local directory and I have a script that installs the application and the copies the common package into the GOPATH so that it can be found. Now, when I try to create plugins and compile them referencing the global copy of the common package, I can't load them in the main application because it sees the two occurrences of the package as being different versions.
My understanding is that to determine package version, a hash is made of all the Go files in the package at compile time. Is this hash including the location on the server where the package was found as well?
I know for a fact that the actual versions of the packages are identical. The only different is that I did cp -r src/myapp /usr/local/go/src. Is there a better way to accomplish this than my approach that still allows the user to move the main application around to different machines and not need to recompile it?
Further explanation:
Here is my directory structure
./
|-- main.go
|-- src/myapp/common
| |-- Common.go
|-- install.sh
Once I compile this into myapp, I copy src/myapp/common into the GOPATH and then build plugins with go build -buildmode=plugin against that package. When loading those plugins from myapp, it sees the two versions of myapp/common as being different, although the only difference is location on the server.
Have you tried instead keeping the path of the common package stable? You should probably have that in its own repo (so that both projects can refer to it), or keep it in your app repo, but allow plugins to link to it there.
So for example say your project lives at:
github.com/brianwest/myapp
you could make the import path (for both app and plugins):
github.com/brianwest/myapp/src/common
OR
github.com/brianwest/common
and keep it stable across the app and plugins, then it should just work and you won't need the script to copy it into gopath, or if you do it can put it at src/github.com/brianwest/common and use that path in both plugins and your app.
I am an Eclipse user having metaphysical question before fully switching to IntelliJ.
I have 2 Maven modules:
"main" module which is my main app which uses
"shared" module which is shared by misc applications
I'd like to:
work at the same time on both modules, meaning the changes in "shared" code would be automatically picked by my main app when I run it.
Ideally I would not have to be forced to create & install in my .m2 folder the artifact "shared-SNAPSHOT.jar" for my main app to use the updated code.
be able to work independantly on each one (own .idea containing each it's own launchconfiguration) while sharing in their own respective git repo their own configuration. It would mean:
each can have it's own set of launchconfigurations (the folders in the .idea where are defined the launch configurations)
each would have it's own code formatter setting
=> with this requirement, I want a new dev to be able to just git clone one project and work on it directly with minimal configuration.
What I managed to do:
If I open the "main" module with a .idea preconfigured inside it is ok: I directly have my formatter & my launch configs.
BUT if I then try to open the "shared" module, IntelliJ proposes:
either to open in a new window. The problem is then that I have to INSTALL the shared-SNAPSHOT.jar in my .m2 repo in order for the updated code to be seen by my main app. Is there any way for 2 IntelliJ windows to 'see' the code from one another ?
or to keep the same window, BUT it adds a new config for the imported "shared" module inside "main"'s .idea folder. Which I don't want because I'd like "main" module to be unaware of "shared" (apart from the maven dependency). And I don't want to force any colleague working on "main" to be forced to also import "shared".
Do you have a best practise for me or should I stay with Eclipse ;) ?
I have a custom task in buildSrc that, among other things, I want to copy a file from buildSrc into the main build. However, when actually running the custom task, the buildSrc project appears to be pretty much invisible, e.g. I can't reference it as a project. How does one refer to and copy a file from the buildSrc project to the main project?
You are correct that the main projects can not see buildSrc. buildSrc is run as a separate project.
The outputs of buildSrc project are put onto the classpath of the main Gradle projects.
One solution then is to generate a Jar artifact with all of your resources, and then use the classpath resource loader in the main projects to access the files you need.
A second option might be to just manually hard code the buildSrc path into your main projects. Of course you can not access it as project(:buildSrc') because it is not valid. The better option is to use file("${rootProject}/buildSrc/") (Not tested).
The follow structure
src
service
service1
Service.java
Service.properties
I want that the output generated by gradle would be
classes
service
service1
Service.class
Service.properties
So, I need that the files(.properties) keep in the same directory of the class after build, but the gradle copy the files .properties (resources) to another directory
how can I do it?
I assume you are trying to place them there so they can be loaded from the classpath? The best way to make them available to your class loader is to place them into src/main/resources which is part of the standard directory layout. Gradle will find them there and they will be placed at the root of your jar (by default I believe it ignores property files in src/main/java).
It would also be good to move your java files to to src/main/java. Using the standard directory layout is a convention that will help other developers understand the code. It also allows you to use certain tools out of the box with less configuration because those tools can make assumptions about where things live.
So the new structure would be like:
service1-project
src
main
java
service1.java
resources
service.properties
If you use the standard directory layout, I think you will achieve the end-result of what you are trying to do (which is really to load the properties file within Java). If for some reason you have to avoid the standard directory layout, then you have to start doing custom configuration (a downside of using a non-standard project layout). In Gradle, you should be able to do this by hooking into the Java Plugin's processSourceSetResources target.