I have a project "A" in IntelliJ that has a Gradle dependency "B" (defined in "A"'s gradle.build). Both "A" and "B" source codes are in Bitbucket. I need to change some codes in "A" and "B". I had cloned both "A" and "B" repositories to my local. In IntelliJ, I want to remove "B" from "A"'s gradle.build, and then add "B"'s local directory as dependency of "A". How do I do that? Thanks in advance.
Related
I put a property placeholder in my domain project, Project A. However, I cannot access the property placeholder from Project B (dependent on Project A).
Project B returns the correct response when I directly put the property placeholder in Project B's global.xml. However, Project B does not return the correct response when I put the property placeholder in Project A's mule-domain-config.xml.
I expect Project B to successfully pull the property placeholder from Project A, but the actual output is that Project B is NOT successfully pulling the property placeholder from Project A.
[Using Mule 3.8 with Anypoint Studio 6.4.4]
For my application, I created 4 components, and want to 'install' only the applications and their docs. According to https://cmake.org/Wiki/CMake:CPackConfiguration, if in my config file I have the line
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};ALL;/")
then all the four components are installed. If I use the component names instead like
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps docs;/")
I receive a package with no component name appended, and it contains the top level requested directory but no files at all. If I provide only one component like
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps;/")
the package name does not contain the name of the component, but the files are generated in their right position.
What do I wrong?
EDIT: Just to add more strange things:
For the ALL case 4 files with names install_manifest_+comp name are created. For the second case I have install_manifest_apps docs.txt of zero length, and for the third case I have install_manifest_apps.txt, with the right content.
It seems to me that the macro can only accept one argument which can be either ALL or a component name; this means it cannot be used to install a 2-component system.
Moreover: if I use a component name, make package only produces that one package, without appending the component name, but with the right content. Till now I guessed that make install and make package are independent.
Set multiple values to CPACK_INSTALL_CMAKE_PROJECTS, one for each component you want to include:
set( CPACK_INSTALL_CMAKE_PROJECTS
"${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps;/"
"${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};docs;/"
)
I'm trying to make two packages using cmake 2.8.12: the first one contains a shared library, the second one contains headers files. Apparently, I want two packages with names libname and libname-dev respectively, so I used command install with no specified component for the shared library and the same command with COMPONENT dev for the headers files. Before this I had defined an empty default component name. So I have a code as follows:
set(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "")
install(TARGETS libname DESTINATION /usr/local/lib)
install(FILES ${header_files} DESTINATION /usr/local/include COMPONENT dev)
But as a result, despite the empty default component name libname-Unspecified and libname-dev are generated. I find this behavior quite weird, because it seems I have no way to define two packages with previously described names. Are there any ideas how to do this in any other way?
In case of debian:
Give your main component some temporary name, e.g. "runtime".
install(TARGETS my-target
COMPONENT runtime
DESTINATION ${INSTALLDIR}
)
Then remove the postfixed component name as follows:
set(CPACK_DEBIAN_RUNTIME_PACKAGE_NAME "${CPACK_PACKAGE_NAME}")
Might work with other generators, too if they provide something equivalent to "CPACK_DEBIAN_RUNTIME_PACKAGE_NAME".
I have a trunk branch "A", and a testing branch "B".
"B" is branched from "A".
Now I want to merge "B" into "A", and did a "bzr merge -pull ${HOME}/B" under "A".
Then I realize that if now I do a "bzr info" under "A", I will find a new "submit branch B".
This sounds bad to me because all the committed changes in "A" will go to "B".
So my question is:
1. Is "bzr merge -pull ${HOME}/B" under "A" a good way to do what I want?
2. How to remove the "submit branch B" under "A"?
The submit branch is primarily used as a default for bzr send and bzr bundle. This should not create any problems for you (if you do use these commands, you can override the submit branch on the command line). It is also the default location for future merges if for some reason you do not specify one. The "submit" in "submit branch" refers to submitting changes for review, not to commits.
Most other commands should not be affected. Commits will go to the original branch unless you've made it a bound branch via bzr bind or bzr checkout, and those will go to the bound location, not the submit branch; pushes will go to the default push location, which is also different.
You can use bzr merge --no-remember to not set the submit branch (or edit .bzr/branch/branch.conf to remove the path afterwards). Similarly, you can use --remember to override an existing submit branch location.
How can I control the name of the top directory of the maven module created by my maven archetype? Currently it creates a new folder named$artifactId. Or even more directly, is there a way that my archetype can create a folder named after the module's artifactId, but with dashes replaced by underscores?
The naming convention for artifactId's is to use dashes (hyphens). I don't think there is any way to make the module's directory named something other than the artifactId. That being said, it is onlvy convention, not a requirement, that your module be named the same as your artifactId. This means that after your project is generated, you could simply change either the artifactId or module folder name or both to whatever you want.
You can rename root folder by making an archetype-post-generate groovy script like :
import java.nio.file.Files
import java.nio.file.Path
import java.nio.file.Paths
Path projectPath = Paths.get(request.outputDirectory, request.artifactId)
// RENAME ROOT FOLDER INCLUDING A PREFIX FOR EXAMPLE
Files.move(projectPath, projectPath.resolveSibling("prefix-" + projectPath.toFile().getName()))
I got round this by adding a second required property to the archetype, and then using that in place of artifactId within the generated pom etc.
In archtype-metadata.xml:
<requiredProperties>
...
<requiredProperty key="projectCode"/>
</requiredProperties>
In pom.xml (and other substitutions):
<artifactId>${projectCode}</artifactId>
So the folder gets the name supplied for artifactId, but in the pom it is given the name supplied for projectCode.
Unfortunately you don't seem to be able to supply a default value for artifactId within archtype-metadata.xml (I always want the folder name to be the same).