I have an issue when reading properties from a dependent project.
I have a core project, and my application has a dependency on it.
under classpath of core, it has file core.properties.
and my application need to read this property file, but it couldn't. It requires the core.properties in my classpath of my application, instead of core.
Is there an solution for that? One solution in my mind is that when I build my application.war, can I explictly declare that I want the core dependency be exploded?
Thanks for help!
What do you mean by "read this property file"?
Since it will be on the classpath it should be accessible with getClass().getResourceAsStream().
If you really need it as a file, you can use the Dependency plugin's unpack-dependencies goal to unpack particular files as part of the build process.
Related
The official Kotlin documentation states:
Add kotlin.code.style=official property to the gradle.properties file at the project root.
I'm trying to understand how kotlin-gradle-plugin handles this property.
Which gradle task uses it?
When running gradle build, I don't see my code being reformatted, even if I format my code badly on purpose.
I went through the Github source code of the plugin but couldn't properly get to understand it.
Thanks for your help.
Kotlin Gradle plugin doesn't use this property, as it's not responsible for reformatting the code. Instead, this property is used by Gradle importer of Kotlin plugin for IntelliJ IDEA.
This facade provides access to Gradle properties defined for the project:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/GradlePropertiesFileFacade.kt
It checks local.properties first in case user wants to override this value in the local configuration (this file is usually added to .gitignore for VCS to skip it during it's operations), then in usual gradle.properties.
Then the property gets consumed to configure the project here:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/KotlinGradleSourceSetDataService.kt#L158-L159
Same thing goes for Maven-based projects. These are the only two places the property is used throughout Kotlin repository apart from tests right now.
Presently having an annoying time getting a jar added to the external library for the project, then in turn not disappear when syncing and the imports working. Adding I figured out and answered in another question. The issue is to keep persistent and accessible to a jar I create within the project for import.
I am not sure if I am missing a step or forgot to set something. I am using a modified gradle (forgegradle) to create the project. Have not found a solution with the documentation, or any for IntelliJ yet. I am generally new with IntelliJ, choosing to use it instead eclipse which I have previously used.
The goal is a to create an add-on for a mod to another jar. The main jar already in the external library from the start, now attempting to add the mod to it. I could modify the mod, but it is not my code, so rather not simply modify it directly and repackage it.
a jar added to the external library for the project, then in turn not disappear when syncing and the imports working
If you are using an external build tool / system that syncs with IntelliJ it is recommended to use that build tool / system to add dependencies.
IntelliJ will always take a backseat, and treat the build tooling / system as the source of truth for the project model as best it can.
You mention you are using gradle, I would recommend adding the dependency as a managed dependency that is, let gradle download it from a repository, and resolve the dependency/library itself.
If you can not do this, and you can't host a repository yourself, The next best recommendation I have, is creating a 'libs' folder inside the project, that contains jars that can't be found in repositories (They may be mods or plugins that were never published)
You can read up on how to add a library folder to gradle here: How to add local .jar file dependency to build.gradle file?
In fact I have 2 different problems, but I think they are kind of related:
I have an artifact, with an assembly descriptor set which will build an extra JAR (with extra classifier). By default, Maven2/3 will deploy the assembly generated together with the main artifact to remove Maven repository. Is there any way that I can deploy only the main artifact but not the assembly?
I have an artifact, in which I have jar plugin generate another artifact with different classifier (more specific, an EJB artifact, and I generate an client JAR). I want to deploy only the client JAR to Maven repo coz I think the main EJB artifact is not really going to be shared by other project. Is it possible to do so?
Thanks a lot
editied to provide more info:
The reason for avoiding deploy the EJB, is because the EJB main artifact is not going to be depended by other project except the containing project. The containing project will build a EAR (which contains the EJB), and normally we only need that build locally (by mvn package). However, the EJB client is something that we will deploy to our repo to let other project share when they need to communicate with our application.
Honestly it doesn't harm to deploy the EJB too, but I just want to see if I can save unnecessary waste of disk space on our repository.
Similarly, for deploying assembly, it is because the project is something we want to deploy to let other project to depends on. However, when building that project, we also have a separate assembly created on the same time (for example, an all-in-one executable jar) which we only need that built locally, and it is not something that other projects will depends on.
Turn off the 'attach' option to the assembly plugin. Then it won't be officially an artifact and it won't deploy; it will just lurk in the target directory, sulking that you don't love it as much as it's elder sibling and plot revenge.
Based on your first question i would like to know why do you create the supplemental assembly which is usually deployed as well as the main artifact. If you wan't to prevent you can put the creation of the assembly into a profile but this means you will not generate the supplemental artifact in your usual build only by activating the profile.
OK, lemme set the stage. I have a parent pom, project_maven, that contains 3 modules in its POM, project_common, project_explode, and project_client. project_client has dependencies on both project_common and project_explode. project_client also contains an /ext directory, which contains third-party executables, scripts, etc.
In our current Ant build of the project, there is a target, build-client-tarball, that copies the /ext directory to the build directory, copies the project_common.jar and project_explode.jar files into specific locations in the build dir, and tarballs the whole thing.
I'd like to duplicate this behavior in maven without having to resort to calling the ant tasks. From what I can tell, it looks like the assembly plugin might be the way to go, but I'm having trouble figuring out how to get it to work. Seems like I would need a custom assembly descriptor? Anybody have any boilerplate or examples I can work from?
You need to use the Maven Assembly plugin. It's worth the effort to investigate it. It will do exactly what you need.
You can use it to include dependencies and sources. Have a look at this link. There're a bunch of sample assembly descriptors there. You need to define a format tar in order for it to produce a tar for you. In addition, you also need to define <dependencySets/> in order to include the modules you mentioned.
In a single-module project, I don't see how to get a 'classified' artifact from the project itself into the descriptor and thus the assembly. Do I list it as a dependency?
Did you try the Build Helper Maven Plugin (I'm thinking to build-helper:attach-artifact)? See Attach additional artifacts to your project in the plugin Usage page.
If it doesn't work, then indeed declare your 'classified' artifact as dependency using one of the advanced identity pattern.