I have some proto files and I am using bazel to build them. I am using proto-rules-grpc to generate the BUILD file for bazel. Then I'm running bazel build command. But the final artefact is in .srcjar.
This also what the rule says and I quote:
Generates a Java protobuf and gRPC srcjar file
But I want the final artefact in .jar format. Whereas .srcjar only contains the .java file.
The manual process I can think of is to extract the raw java file from the .srcjar artefact and then use them to create the .jar file. But this is a bit annoying to do all this manually.
Is there any way to do it without involving the manual process?
Use java_grpc_library.
java_grpc_compile produces a .srcjar. java_grpc_library produces a .jar.
Related
Running ./gradlew quarkusGenerateCode works well, however the generated sources fall under the build directory:
I wouldn't like to set this path as a Gradle SourcesSet, "Mark Directory As" Generated Sources Root in Intellij, and so on as it's under the build directory.
Is there a way to set the output dir to something such as src/quarkus-generated-sources? The Quarkus user guides and the gradle plugin documentation are not too informative regarding that subject.
There's the build.gradle, nothing much special about it
plugins {
id 'io.quarkus'
}
dependencies {
implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")
implementation 'io.quarkus:quarkus-grpc'
...
}
There is no way to specify an alternative path for the built-in code generation mechanism.
The classes generated by Quarkus from your *.proto files may change quite often. If you run Quarkus in the development mode, they will be regenerated on each change (in the *.proto files). In such a set up this is an outcome of the build rather than a source, that's why I put it in build.
I think you could use Gradle protobuf plugin to generate the java files. It has an option to specify the output directory. Don't forget to register quarkus-grpc-protoc-plugin similarly to Maven protobuf plugin configuration.
The drawback of switching to it is that you won't be able to use the full power of the development mode when modifying the *.proto files.
I was working on a maven project and this project is generating some weird file.
The file name are like:
[PROJECT]/target/classes.531226305.timestamp
[PROJECT]/target/classes.1241815416.timestamp
[PROJECT]/target/test-classes.-1983166104.timestamp
And the content of the file are only a .(dot) inside it. Anyone has any idea of how this is generated? Thanks!
Does the project use the scala-maven-plugin? The scala-maven-plugin adds ".<hashcode>.timestamp" to files in the target directory. It's used for the incremental compile feature that is available for that plugin.
I have an off the shelf application that ships a version of gradle with it. It also has scripts that are hard coded to set GRADLE_HOME to this location.
I want to zip up this dir, put it in nexus and replace it with the gradle wrapper.
How do I configure the gradle wrapper to download this zip from nexus and extract it to a specific location in the project?
EDIT: In the gradle-wrapper.properties I have
distributionPath=wrapper/gradle
However, I end up with it being unzipped to
...\wrapper\gradle\gradle-2.3-bin\8gn7esgljqyucijpbynjk93oc\gradle-2.3
How do I get it to unzip to the path I specified and not to the subdirs?
The location to which Gradle gets unpacked is a combination of the distributionBase and distributionPath properties in gradle-wrapper.properties file. The location specified by distributionPath will always be considered as relative to distributionBase. The only available values for distributionPath are GRADLE_USER_HOME and PROJECT. Even when using PROJECT the wrapper will still generate the folder structure you see above.
If you want to control this more precisely I'd suggest not relying on the wrapper to do this and instead add a task to your build specifically for this purpose.
We are using TeamCity as CI and we are struggling with the final build step: We pull a dependency from another build step (a zip) and want to add a few extra files. Do we really need to extract the zip (quite large file), copy the files over there and zip it again? Is there support or a plugin to add files to existing zip files?
TeamCity itself does not support this and I haven't seen any related plugins, however, if you really need to wait until the final step to add the extra files (maybe you are doing some kind of file generation at this point), then I would recommend using something like 7Zip.
you can update existing zip files (assuming they are not "solid" archives") with a very simple command:
7za.exe u targetZip.zip file.ext
this will add "file.ext" to the zip file "targetZip.zip" without decompressing and re-compressing the archive.
you can find 7Zip here: http://www.7-zip.org/
It would be much better to include those files at the previous step, which lists which files should be included to the final artifact. Rather than trying to modify the already generated artifact. So basically all you need is to add an additional build step that will simply copy those other files to the output folder from which you are producing your final artifact.
We are using the assembly plugin to build a zip package.
I would like to execute some custom java code during the execution of the Maven Assembly plugin. The java app should have access to the structure of the assembly but before the zip file is built. So, files which should go into the zip might possibly be modified/added/removed.
How would I configure that?
Cheers
Jonas
I do not think executing Java code is possible. Try getting along with exclusion patterns for file removal and maven filters for file modifications.
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html