Custom Maven Plugin: Programmatically Adding Source Directory to Project - maven

As a Maven end-user, it is simple to add an additional directory to the list of source directories that will be compiled during the "compile" phase. I would use the build-helper-maven-plugin approach.
However, in my own custom plugin I would like to do this programmatically. My plugin will generate some java code. I would subsequently like to add the output directory (containing generated .java files) to the list of source paths.
At the moment I’m manually having to set the build-helper-maven-plugin config in all of my POMs to get the files I’m generating to be compiled.
Any pointers on what part of the Maven API to be looking at? My searches have only yielded queries from end-users, which are solved with the build-helper-maven-plugin approach.

To find my answer I took a look at the source code for the ANTLR maven plugin, which I know adds sources to the path. See AbstractAntlrMojo.
The solution is to add a MavenProject member variable to your Mojo with an expression to bind it to the project:
#Parameter(defaultValue="${project}")
private MavenProject project;
Once one has a reference to the project, it's a simple method invocation:
project.addCompileSourceRoot("<DIRECTORY-PATH-HERE>");
This will ensure that the new directories housing generated code will be compiled.

Related

How to publish a binary generated by OpenAPI Generator with gradle/kotlin?

I'm trying to create and publish binary artifacts from an OpenAPI Spec to our internal Maven Repository.
First, I'm using the "org.openapi.generator" version 5.0.0-beta2 to generate an endpoint project from a spec. For example a Kotlin Spring service. Works fine, creates an entire gradle/kotlin project, with a build.gradle.kts file and a settings.gradle file.
If I navigate to that folder I can build that project just fine. I can also call that build from my original build to first generate the code and then build it.
I just don't know how to publish it. My publishing configuration is obviously not in the generated project, nor is there a maven-publish plugin. Is there a way I can 'inject' these? Can I call some kind of 'include' on a build?
For myself, I generate the files to $buildDir/generated/ and do what I want with the files in $buildDir/generated/src/main/kotlin from my own build script ... such as:
copy them to src/main/kotlin (if that's important to you),
compile them, jar them, publish them.
I don't really even appreciate that the openApiGenerate task went to the trouble of preparing a build.gradle file instead of a build.gradle.kts file, with arguably out-dated dependencies ... it should mind its own business.

Gradle search local maven or gradle repository

I am using gradle and its local repository is at \.gradle\caches\modules-2\files-2.1 which has all the downloaded jar but not my modules.Is there any specific place I should be searching it for ?
I need it as is in settings.gradle I am having a dependency path specified like :
include ':model'
project (':model').projectDir = new File(settingsDir, './model')
in a new project. Also I don't want to give path in that way because if I have a dependency from multiple projects on this project then mentioning path will be difficult and weird.
How can I make gradle search it from local maven or gradle repositories.
I'm still not sure what is being asked here, and I suspect there is some confusion over how multi-project builds work. So I'm going to attempt to provide a general-purpose answer.
The first question you need to answer is whether you're interested in dependencies between projects that are part of the same build — as in part of a multi-project build — or in separate builds.
Project dependencies (multi-project builds)
Project dependencies are covered in the user manual and only apply to multi-project builds. They use a logical path, using colons as 'path' separators, to specify the location of the target module, like so:
dependencies {
implementation project(":model")
}
At this point, Gradle needs to know where ":model" exists on the file system. There's no getting around that. You have a few options:
Follow the convention of directory structure matching the logical path structure, i.e. have a MyBigProject/model directory containing the ":model" child project
Specify the file path of ":model" in settings.gradle, e.g. with project(":model").projectDir = new File(rootDir, "unusual/path/to/model")
Automate the discovery of projects
The most common approach is the first one. The second is not unusual, particularly if you want to put child projects into a separate directory, like subprojects — something the build of Gradle itself does. I haven't seen the last option done, and I don't know whether it runs into problems.
For the sake of completeness, and at your own risk if you use something like it, here's an example of automatic discovery of projects in the settings.gradle file:
rootDir.eachDir { File dir ->
if ("build.gradle" in dir.listFiles()*.name) {
include dir.name
}
}
This fragment basically looks for directories within the root project folder that have a build.gradle file in them and adds them as child projects. The child projects' directory names become the projects' names.
It's not particularly clever, and you should really use different names for the build files, but it may give you some ideas to work with.
Non-project dependencies
As with project dependencies, Gradle needs to know where to get the corresponding JAR or other form of artifact for a specified module. You normally specify Maven Central or something similar for this, but there are other useful, but less common, options:
Copy a project's artifacts into the local Maven repository — both the Maven Plugin and Maven Publish Plugin support this
Publish to a Maven-compatible repository using a file:// URL rather than an HTTP/HTTPS one, which protects your projects from corruption of Maven Local
Worth noting is that Gradle supports composite builds that allow you to substitute a normal dependency with (effectively) a project dependency from another build. So if model were part of a separate build but you had the source code and build locally, you could make changes and immediately test them in another build's project without going through the whole "install" intermediate step that's common in the Maven world (and Gradle pre-composite-builds).
Hope all this makes sense.

Where in the Maven Standard Directory Layout should generated resources go?

I'd like to generate some resources (JavaHelp search index in this case), but I can't seen to see where those generate files should go to get into the jar. I put them in target/generated-sources, but they are ignored. Should it be target/classes?
/generated-sources directory is used by various tools generating sources (duh!), like xjc or wsdl2java. This directory is later included in the compilation phase.
/target/classes is everything that should be included in the final JAR, which answers your question. Also the contents of /src/main/resources is included, but this directory is typically part of version control and is not meant for generated artifacts.
It turns out that generated-source directories are not automatically included in the jar. However, Intellj assumes there are and treats them as such, hence my confusion.
You need to use the Maven build helper plugin to fix this issue, for example:
https://github.com/alexec/javahelp-skeleton/blob/master/pom.xml

IntelliJ automagically mark a target sub directory as "source"

I use IntelliJ since a few months back now for my Java development. I using IntelliJ as IDE and build my projects using Maven. A couple of my Maven projects generates code which my other Maven projects depends upon, the generated code ends up in a target/src-generated directory with "Maven-subdirectories" main/java, main/resource etc. Is it possible to make IntelliJ automagically mark the target/src-generated/main/java directory as source?
Thanks in advance.
Please refer to the IntelliJ IDEA Maven FAQ:
In order to get generated sources automatically imported as source
folders configure corresponding plugins so that they put them into
target/generated-sources/<subdir>, where subdir is any folder name you
prefer. The subdir folder is necessary to distinguish sources from
different tools and also to exclude some special generated sources
(e.g. groovy stubs).
Please note that even if you manually configure
some source folders under target/generated-sources of this folder
itself, IDEA will rewrite them according to your pom.xml.
Any time you
want to generate sources you simply execute the corresponding goal,
bound for generation (usually generate-sources,
generate-test-sources). After that IDEA will pick up new folders and
set them up. Generated test sources/resources should be placed in
target/generated-test-sources/<subdir>.

In a maven project, is it possible to use a plugin just built within the same project?

Suppose you have some sort of input files which are to be processed in some custom way (even the file format is very particular to the package of files in question).
To process them I decide to make a maven plugin, which happens to be useful only in the context of these files.
Is it possible to have them all (the afore mentioned files and source code for the plugin) in one project, build the plugin, run the plugin over the input files and collect its output as the output of this project?
Short answer is you can't, because Maven resolves plugin classpath on start.
However you can create separate modules, first being a plugin and second would use that plugin to process files. Both modules can be invoked from parent pom.

Resources