When I run mvn site with no site.xml on a simple Maven project (meaning it will use the maven-default-skin) which site.vm file site used?
I have looked into maven-site-plugin, maven-project-info-reports-plugin, maven-doxia-sitetools and of course maven-default-skin, but I could not find it anywhere.
For the maven-fluido-skin, I can find the site.vm in src/main/resources/META-INF/maven. But there is no such file for maven-default-skin.
When using maven-site-plugin 4.0.0-M3, the maven-doxia-sitetools version used is 2.0.0-M3. This version provides the default-site.vm file in its resources, which is used as the default template in the DefaultSiteRenderer class if the skin doesn't provide any (e.g. maven-default-skin).
In maven-site-plugin 4.0.0-M4, the version of maven-doxia-sitetools is 2.0.0-M4. In this version, the default-site.vm has been removed and the default skin has been changed to maven-fluido-skin.
This means it's not possible anymore to use a skin that doesn't provide the site.vm template. If one tries to force the use of the maven-default-skin with version 4.0.0-M4, it will fail with the message Skin does not contain template at META-INF/maven/site.vm.
This change has been done in https://issues.apache.org/jira/browse/DOXIASITETOOLS-270. maven-default-skin is unmaintained and will be replaced by maven-fluido-skin, see https://issues.apache.org/jira/browse/MSKINS-196.
For information, the site.vm is a Velocity template file and is rendered by maven-doxia-sitetools (doxia-site-renderer to be precise) on maven-site-plugin's request.
We recently updated to JDK 11 and the javadoc team has seen fit to remove frame generation from the javadocs in favor of a search box. Our community is comprised heavily of students who don't know what keywords to search for, but who can browse a sidebar and find what they need. For them a search box is useless. They require discovery through browsing. For that reason, we would like to turn frames back on by adding the --frames option to the javadoc task, and then we'll just never move off of JDK 11.
We are using Gradle 7.4.2 and there doesn't appear to be a method exposing the --frames option in the StandardJavadocDocletOptions class.
If the options section of my Javadoc task looks like this:
options.memberLevel = JavadocMemberLevel.PROTECTED
options.links "https://developer.android.com/references"
options.encoding = 'UTF-8'
Then I see those options in gradle's generated options file.
Adding...
options.setStringOption('-frames')
...does not result in any new option appearing in the generated options file. To be honest I have no idea what setStringOption() without the second string parameter actually does.
Adding...
options.setStringOption('-frames', '')
... results in --frames '' appearing on the generated options file, but that confuses javadoc.
I don't see anything in the Gradle documentation that indicates how one might add simply '--frames' to the command line of the javadoc executable. Or any other option that javadoc might expose, but the gradle version one is sitting on does not expose for that matter.
To set flags use addBooleanOption()
// build.gradle.kts
tasks.javadoc {
options {
require(this is StandardJavadocDocletOptions) // workaround https://github.com/gradle/gradle/issues/7038
addBooleanOption("frames", true)
}
}
Note that the Kotlin DSL requires a workaround https://github.com/gradle/gradle/issues/7038#issuecomment-448294937
After export versionCatalogs as a library, and being used by other applications, the error state
> No matching variant of io.github.elye:plugin-dependencies:1.0.0 was found. The consumer was configured to find attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog' but:
- Variant 'apiElements' capability io.github.elye:plugin-dependencies:1.0.0:
- Incompatible because this component declares attribute 'org.gradle.category' with value 'library', attribute 'org.gradle.usage' with value 'java-api' and the consumer needed attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog'
- Variant 'runtimeElements' capability io.github.elye:plugin-dependencies:1.0.0:
- Incompatible because this component declares attribute 'org.gradle.category' with value 'library', attribute 'org.gradle.usage' with value 'java-runtime' and the consumer needed attribute 'org.gradle.category' with value 'platform', attribute 'org.gradle.usage' with value 'version-catalog'
My versionCatalogs library is writen as below
plugins {
id 'java-library'
id 'kotlin'
id 'version-catalog'
}
java {
sourceCompatibility = JavaVersion.VERSION_1_7
targetCompatibility = JavaVersion.VERSION_1_7
}
catalog {
// declare the aliases, bundles and versions in this block
versionCatalog {
alias('androidx-core').to('androidx.core:core-ktx:1.6.0')
alias('androidx-appcompat').to('androidx.appcompat:appcompat:1.3.1')
alias('androidx-constraintlayout').to('androidx.constraintlayout:constraintlayout:2.1.0')
alias('android-material').to('com.google.android.material:material:1.4.0')
bundle('androidx', ['androidx-core',
'androidx-appcompat',
'androidx-constraintlayout'])
}
}
ext {
PUBLISH_GROUP_ID = 'io.github.elye'
PUBLISH_VERSION = '1.0.0'
PUBLISH_ARTIFACT_ID = 'plugin-dependencies'
}
apply from: "./publish-module.gradle"
When I try to access the versionCatalog library, it is just as below
dependencyResolutionManagement {
// Some other codes
versionCatalogs {
xlibs {
from("io.github.elye:plugin-dependencies:1.0.0")
}
}
}
How can I fix the error?
Looks like I just need to remove the below from the library's build.gradle file.
plugins {
id 'java-library'
id 'kotlin'
}
Hence the code looks like below
plugins {
id 'version-catalog'
}
catalog {
// declare the aliases, bundles and versions in this block
versionCatalog {
alias('androidx-core').to('androidx.core:core-ktx:1.6.0')
alias('androidx-appcompat').to('androidx.appcompat:appcompat:1.3.1')
alias('androidx-constraintlayout').to('androidx.constraintlayout:constraintlayout:2.1.0')
alias('android-material').to('com.google.android.material:material:1.4.0')
bundle('androidx', ['androidx-core',
'androidx-appcompat',
'androidx-constraintlayout'])
}
}
ext {
PUBLISH_GROUP_ID = 'io.github.elye'
PUBLISH_VERSION = '1.0.0'
PUBLISH_ARTIFACT_ID = 'plugin-dependencies'
}
apply from: "./publish-module.gradle"
I didn't quite follow the Elye's answer, so I'll explain what I changed in my build.gradle.kts file to get around the problem.
I have a separate project that contains the toml version catalog. That project is simply responsible for publishing the version catalog to my nexus repository. In my case, I not only publish the toml version catalog, but I also publish 4 properties files. Those properties files correspond to the values of the versions, libraries, bundles and plugin sections of the toml version catalog. I do that so my runtime application can get access to the information contained in the toml file. Normally the toml version catalog is only available to the build components. This allows me to make that data available to either runtime components or externally built custom gradle plugins.
Here's what my settings.gradle.kts file contains:
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
maven {
url = uri(System.getenv()["MyReleaseRepoUrl"].toString())
credentials {
username = System.getenv().get("MyRepoUser").toString()
password = System.getenv().get("MyRepoUserPW").toString()
}
}
google()
mavenCentral()
}
versionCatalogs {
create("libs") {
from(files("src/main/resources/libs.versions.toml"))
}
}
So the settings file creates a version catalog for the toml file which I store in the "src/main/resoures" directory
Here's what my build.gradle.kts file contains:
plugins {
id ("version-catalog")
id ("maven-publish")
kotlin("jvm")
id ("com.xyz.versions.plugin")
}
publishing {
publications {
create<MavenPublication>("VersionCatalog") {
groupId = "com.xyz"
artifactId = "com.xyz.version.catalog"
version = libs.versions.toml.get()
//artifact("src/main/resources/libs.versions.toml")
from(components["versionCatalog"])
}
create<MavenPublication>("VersionsProperties") {
groupId = "com.xyze"
artifactId = "com.xyz.version.versions"
version = libs.versions.toml.get()
artifact("src/main/resources/versions.properties")
}
...
The plugin "version-catalog" is what makes "components["versionCatalog"]" available. Maven-publish is the plugin I use to do the publishing. And "com.xyz.versions.plugin" is a buildSrc plugin that is written in Kotlin. That plugin iterates each section of the version catalog and produces a corresponding properties file.
And lastly you see my definition of what I publish. I show how I publish the toml version catalog, and I show how I publish the versions.properties file that I generated. You should notice that I have the "artifact" line commented out in the publication description for the toml file. If I published the file using the "artifact" line I get the "no matching variant..." issue when I try to use the published version catalog in some other project. If I use the "from components" line instead, I don't get the "no matching variant..." issue when I import the version catalog in another project.
As I explained in the comment to my previous solution, it actually doesn't work. The problem with the code I posted is that it ended up publishing an empty version catalog; and with an empty published version catalog that ends up avoiding the error. But of course, that's not what you want happening. The solution to getting the version catalog published was for me to publish the version catalog using the "artifact" line instead of the "components" line. I don't totally understand the circumstances that cause you to publish an empty version catalog but publishing it as an artifact instead of a component gets around that issue. There are lots of people who have observed this same issue and I think it's a Gradle bug.
With that said, the issue of "no matching variant..." would come up when I tried to use that published version catalog. In my case, it turns out that I was publishing the version catalog reusing the previous version number. I had set up my maven repository to let me do that. What I did to get around the problem was to run "gradlew build --refresh-dependencies" in the project that I was importing the version catalog artifact. When I watched the build, I got the clear sense that the version catalog was be reloaded by watching the build output screen. I let that task run for a while, but the task seemed to be hung. After 10 minutes of waiting, I just went ahead and control C'ed out of the task. I then ran the task "gradlew build" without the refresh dependency option. This time, it ran without producing the "no matching variant...". I also had the build script print out the value of one of the versions and libraries aliases. It printed out the values that was contained in the imported version catalog.
I'd posted two answers and both of these answers at first seemed to resolve this problem, and then days later the problem started reoccurring. I think this time I have a better understanding of what's wrong and I'll try to set the record straight in hopes that this info is useful to someone else experience this problem.
The first thing to understand is that the Gradle documentation on how to publish a version catalog and later on import that published version catalog is close to nonexistent or impossible to find. Like most Gradle documentation, the best you can hope for is some coding examples that shows you what to do; usually you get a coding example with no explanation as to what it doing. When it comes to publishing a version catalog, you'll see examples that show you how to publish using "from(components["versionCatalog']). So, the question is why do you need to publish it as a component? After much searching around, I discovered that beginning in Gradle version 6, the publish of Gradle Module Metadata in now the default when using the "maven-publish" or "ivy-publish" plugins. What's harder to find is that the importing a version catalog from a repository relies on this additional metadata in order to work. This additional metadata gets stored in the repository along with the other required maven files when you publish an artifact to the repository. For most of us, we don't really need to know about these other files that get automatically generated and when you publish an artifact to a repository. The publishing plugin hides that detail from us. When you publish an artifact, you not only add the artifact to the repository, but you also add a POM, maven-metadata, and a number of message digest calculation. There's also a define directory structure as to where these files get store in the repository. And now beginning with Gradle version 6, maven-publish adds the file "module" to the mix.
Here's an example of what that "module" file contains:
{
"formatVersion": "1.1",
"component": {
"group": "com.mycompany",
"module": "com.mycompany.version.catalog",
"version": "0.0.1-SNAPSHOT",
"attributes": {
"org.gradle.status": "integration"
}
},
"createdBy": {
"gradle": {
"version": "7.4"
}
},
"variants": [
{
"name": "versionCatalogElements",
"attributes": {
"org.gradle.category": "platform",
"org.gradle.usage": "version-catalog"
},
"files": [
{
"name": "com.mycompany.version.catalog-0.0.1-SNAPSHOT.toml",
"url": "com.mycompany.version.catalog-0.0.1-SNAPSHOT.toml",
"size": 12663,
"sha512": "0078f8cd00d4a49577bdee7917cafaac0a292761d197012529580c2a561c630360ced5689c07ff40373c32f5e3873b0910987acbc74a659b160c50fb35598b6b",
"sha256": "051977a0ecdccea2e0708fa34d12390f3b4505010e7f00f4390c0c0cc5459e1d",
"sha1": "8ce5ca0cda001dd67799c98a2605107674a3c92b",
"md5": "8f348b9eef2b0ccb7d77d0fe17989f31"
The important thing to notice is the presents of the attributes "org.gradle.catalog" with value "platform" and "org.gradle.usage" with the value "version-catalog".
If you look at Elye's original posted message, those are the attributes that can't be found. So, what the error message is saying that when it tried to import the version catalog artifact from the repository it first retrieved the module file and found that this artifact is not publish as the kind of artifact that it was expecting to find. Instead, the artifact that it did find had the attributes 'org.gradle.category' with value 'library' and the attribute 'org.gradle.usage' with value 'java-api'. The other possibility is that the repository, did not contain a "module" file, and if that's the case, it assumes those attributes and values as the default values. So, what the error message is telling us is that it found an artifact that match the request, but it's not been published as the type of artifact that we were expecting.
So that is what I believe is what's going on, and if that's all you're looking for you can stop here. The message means you've not properly published the version catalog. What I'll now attempt to explain is what happened to me and how I got confused. I'll also explain how I manifested the same problem but from a different angle.
In my situation, I have a project, whose only purpose is to define a version catalog that can be published. I have a number of other external projects that import that published version catalog. I've authored the version catalog so that it contains the version number of the version catalog that it publishes. When I publish the version catalog, I publish it using the version number contained in the version catalog itself. In order to do that, the version catalog needs to be created in the setting.gradle.kts script file. The build.gradle.kts script that that does the publishing get access to the version number using the accessor "libs.version.toml.get()".
The problem is that I can't publish that version catalog using the version catalog in my settings file as a component. Hence that got me publishing it as a file instead of a component. If I publish it as a file and not a component, the "module" file is not published, and that cause the error about mismatched attributes. The only way I could get it to be published as with the module file was to apply the "version-catalog" plugin. That resulted in publishing an empty version catalog. In other words, it didn't know that I had a version catalog created in the setting file. Later I discovered that I could add a "versionCatalog" section to my build.gradle.kts script. In that section I added a catalog that came from the same file that the version catalog in my settings file was using. In other words, I've got two instances of version catalogs both derived for the same file. That works, and when I now publish from component["version-catalog"], I no longer publish an empty version catalog In doing it this way, the module file gets added to the repository. And because I got the version catalog in the settings file, I can extract the version number I need in my build.gradle.kts file. Life is good!
One of things that I was doing that added to the problem was that I was republishing the catalog using the same version number. I would of course refresh my dependencies each time I did this. When I first started this, I was publishing using "components", when I later discovered that the catalog was empty, I started publishing using "files". The problem with that is I believe that a republish using files, didn't cause the "module" file to go away. So with the presents of the "module" file, that masked the problem that I wasn't properly publishing the version catalog. What's funny is that it worked for a couple of days and then the problem started reoccurring. I did look at the contents of my repository, and I saw that the module file was still there. And I recall that it had the right attributes, but after about 3 days, and refreshing my dependencies, the error came back. So they's a bit of a mystery as to why? I couldn't find anything in the maven repository from a data perspective that would signal that the module file shouldn't be associated with the given artifact. The only thing that comes to mind is perhaps the datetime of the module file is not timewise near enough to the datetime of the artifact. I think that may be what's happening, but that's pure speculation. It could also be some weird caching issue. I don't power my machine off every day, and the problem might have emerged after a reboot of my computer. The problem is that how Gradle interacts with the repository in retrieving a version catalog is not describe.
Since this problem, I took the time to learn a little more about maven snapshot artifacts. I had avoided it use only because I was unaware how snapshots are implemented. I've started using snapshots and have learned a little more on how snapshots get added to the repository. I've a good feeling that this is going to straighten out some of the weird things I've been observing.
I have projects that are developed with xml and python code mostly (Odoo modules). There is a bit of .po files for translation and csv fields for data.
I would like to enforce specific policies in xml files, for example:
No duplicate id attributes.
A specific attribute must be present if child elements contain a specific tags.
On python, I want to enforce rules like:
Look for SQL queries, and make sure that they use specific parameter methods to prevent SQL injection
Follow a specific naming convention
Some attributes are required in classes that inherit a specific class
I hope that the idea is clear.
Is there any open source solution for this? Preferably linked with github and checks on every commit!
I found a python package made specifically for this, pylint-odoo, here.
It can also be installed with pip install pylint-odoo.
An example .pylintrc config file can be found at the web OCA module, here. They also have another file named .pylintrc-mandatory.
There is even a warning for duplicate xml id attribute W7902.
I have a gradle project with a gradle.properties file. One of the properties displays the current version of my project and I would like to include this proprerty in the project's README.md on github. How can I do this?
The Gradle Copy task is capable of such functionality. Simply use its expand method to specify the values to insert. Of course you'll need to define a template somewhere in your project:
task copy(type: Copy) {
from 'src/templates'
into "$buildDir"
include 'projectinfo.html.template'
rename { file -> 'projectinfo.html' }
expand(project: project, title: 'ProjectInfo', generated: new Date())
}
I took this example from a post of Mr. Hakis Blog.
This functionality is based on the Groovy SimpleTemplateEngine. Of course you can simply use this class or any other templating engine to implement the required functionality in your build script on your own.
#KrispyK,
I believe this would be possible. You could write a simple serverless script using webtask (or similar service) that reads your gradle properties file and creates a custom status badge using a badge service like shields.io. Finally, you would only need to add this badge to your markdown file.
Please refer to this webtask script that I created. This calls an external API and uses the data returned by that API to create a custom Shields badge.
I've then used this badge in my readme file.
Hope this helps.