I had this problem when I was developing the GoLand plug-in and install plugin from build jar Plugin Gorm Generator depends on unknown plugin com.intellij.velocity
<depends>org.jetbrains.plugins.go</depends>
build.gradle：
intellij {
version '2020.2.1'
sandboxDirectory = "${rootProject.rootDir}/idea-sandbox"
type 'IU'
plugins = ['java', 'DatabaseTools', 'Velocity']
updateSinceUntilBuild false
setPlugins("org.jetbrains.plugins.go:202.7319.5")
}
i'm not find
You're setting the plugins list twice - by assigning an array to the plugins property and calling setPlugins method. That makes your first array simply overwritten by the Go dependency.
Try with the first approach only and simply append the Go entry at the end of your array.
Related
I migrated a 3rd-party tool's gradle.build configs, so it uses android gradle plugin 3.5.3 and gradle 5.4.1.
The build goes all smoothly, but when I'm trying to make an .aab archive, things got broken because the toolchain expects the output .aab file to be named MyApplicationId.aab, but the new gradle defaults to output MyApplicationId-release.aab, with the buildType suffix which wasn't there.
I tried to search for a solution, but documentations about product flavors are mostly about adding suffix. How do I prevent the default "-release" suffix to be added? There wasn't any product flavor blocks in the toolchain's gradle config files.
I realzed that I have to create custom tasks after reading other questions and answers:
How to change the generated filename for App Bundles with Gradle?
Renaming applicationVariants.outputs' outputFileName does not work because those are for .apks.
I'm using Gradle 5.4.1 so my Copy task syntax reference is here.
I don't quite understand where the "app.aab" name string came from, so I defined my own aabFile name string to match my toolchain's output.
I don't care about the source file so it's not deleted by another delete task.
Also my toolchain seems to be removing unknown variables surrounded by "${}" so I had to work around ${buildDir} and ${flavor} by omitting the brackets and using concatenation for proper delimiting.
tasks.whenTaskAdded { task ->
if (task.name.startsWith("bundle")) { // e.g: buildRelease
def renameTaskName = "rename${task.name.capitalize()}Aab" // renameBundleReleaseAab
def flavorSuffix = task.name.substring("bundle".length()).uncapitalize() // "release"
tasks.create(renameTaskName, Copy) {
def path = "$buildDir/outputs/bundle/" + "$flavorSuffix/"
def aabFile = "${android.defaultConfig.applicationId}-" + "$flavorSuffix" + ".aab"
from(path) {
include aabFile
rename aabFile, "${android.defaultConfig.applicationId}.aab"
}
into path
}
task.finalizedBy(renameTaskName)
}
}
As the original answer said: This will add more tasks than necessary, but those tasks will be skipped since they don't match any folder.
e.g.
Task :app:renameBundleReleaseResourcesAab NO-SOURCE
I have to create builds depending on environment and tag/push to nexus. Currently, I have tagTemplate = 'release-${version}' in my release settings. The first part of the tagTemplate (release) is what we're using in our pipeline to fire off the builds, which require slightly different args for each.
I need to be able to pass in an argument that will replace 'release' with some other build type.
Ideally, I'd like to be able to just pass in what goes in the 'release' part of the template, so the setting would look like:
tagTemplate = '${tagPrefix}-${version}'
Then I'd be able to run the command:
gradle release -PtagPrefix='build1'
I've tried passing it in like this:
gradle release -PtagTemplate='build1-${version}'
gradle release -Prelease.tagTemplate='build1-${version}'
gradle release -Pproject.release.tagTemplate='build1-${version}'
None of these work.
gradle release -PtagPrefix would be available via roject.findProperty('tagPrefix').
I'm not sure if you can use template strings for the property args as it depends when they are evaluated.
I would recommend either
release {
def tagPrefix = project.findProperty('tagPrefix') != null ? project.findProperty('tagPrefix') : 'default'
tagTemplate = '${tagPrefix}-${version}'
}
I'm used to Spring and Maven projects where I set up a multi-module project in Maven with projects like:
app-web
app-models
app-services
app-common
I'm now getting into using Play Framework 2 (Scala) and sbt.
Is there a similar concept with Play and sbt that I could group all of these projects into a single IntelliJ IDEA solution and sbt?
IntelliJ IDEA 13 (the latest version is 13.1.3) comes with the built-in SBT support, and the Ultimate edition adds Play support.
A multi-module sbt project can be imported to IDEA and is fully supported out of the box however it's Play-based or not (they're sbt projects after all).
You should try it out yourself with the following very simplistic build file build.sbt (or just generate a Play project with play new or better now activator new [your-project-name] play-scala):
lazy val a, b, c = project
and the following project/build.properties:
sbt.version=0.13.5
Nothing but these two above files are needed to get you started with sbt/activator.
In IDEA, open the project using File > Open... and select build.sbt.
Click OK to see another window where you specify additional configuration options for the project. Then the modules show up.
You probably wouldn't be able to group them into one single project in idea but you could have multiple projects for sure:
in your project/Build.scala:
{
val baseDependencies = Seq(
"org1" % "dep" % "latest.integration",
"org2" % "dep2" % "version"
)
val modelDependencies = baseDependencies ++ Seq("org3" % "dep3" % "version")
val appWeb = play.Project("app-web", "1.0", baseDependencies)
val appModels = play.Project("app-models", "1.0", modelDependencies, path = file("modules/models"))
val app = play.Project("app", "1.0", Nil).aggregate(appWeb, appModels)
}
In this case, you'll have a regular app called "app-web", a module appModels under modules/models without the project directory and regular confs like application.conf, and an aggregated app called "app".
When you start the play console you could switch to certain projects by typing "project (name)". For example you could type "project app-web" and then "idea" to generate the app-web project solution for idea. You can also switch to project "app" where all commands entered under it will be applied to all sub-projects.
For more, check the documentation here: http://www.playframework.com/documentation/2.2.x/SBTSubProjects
I would like to control 'global' config in Gradle build scripts using external property files on each build machine (dev, ci, uat,...) and specify the filename with a command line argument.
e.g. gradle -DbuildProperties=/example/config/build.properties
I specifically don't want to use gradle.properties as we have existing projects that already use this approach and (for example) we want to be able to amend database urls and jdbc drivers without having to change every project.
So far have tried:-
Properties props = new Properties()
props.load(new FileInputStream("$filename"))
project.setProperty('props', props)
which works but has a deprecated warning, but I can't figure out how to avoid this.
Have also tried using groovy style config files with ConfigSlurper:-
environments {
dev {
db.security {
driver=net.sourceforge.jtds.jdbc.Driver
url=jdbc:someserver://somehost:1234/some_db
username=userId
password=secret
}
}
}
but the colons and forward slashes are causing exceptions and we don't want to have to mess up config with escape characters.
There must be a non-deprecated way to do this - can anyone suggest the 'right' way to do it?
Thanks
You can get rid of the deprecated warning quite easily. The message you got probably looks something like this:
Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information on the replacement for dynamic properties.
Deprecated dynamic property: "props" on "root project 'private'", value: "true".
It can be fixed by replacing:
project.setProperty('props', props)
with
project.ext.props = props
Just to supplement the response given by #Steinar:
it's still possible to use next syntax:
project.ext.set('prop_name', prop_value)
in case you have several properties from file:
props.each({ project.ext.set(it.key, it.value)} )
How do I program one Mojo to set another Mojo's configuration? For example: Mojo A requires configuration parameter A.foo to be defined. A user can either specify A.foo manually or run plugin B which will calculate the value for him/her.
Answering my own question:
It's possible to access a plugin's configuration or project-wide properties at runtime using a MavenProject instance:
/**
* The maven project.
*
* #parameter expression="${project}"
* #readonly
*/
private MavenProject project;
You can then access a plugin's configuration at runtime:
private Plugin lookupPlugin(String key)
{
List plugins = getProject().getBuildPlugins();
for (Iterator iterator = plugins.iterator(); iterator.hasNext();)
{
Plugin plugin = (Plugin) iterator.next();
if(key.equalsIgnoreCase(plugin.getKey()))
return plugin;
}
return null;
}
...
Xpp3Dom configuration = (Xpp3Dom) Plugin.getConfiguration()
configuration.getChild("parameterName"); // get parameter
configuration.addChild(new Xpp3Dom("parameterName")); // add parameter
...
Note: Any configuration changes are discarded at the end of the current phase.
Source: Best way to access the runtime configuration of a maven plugin from a custom mojo?
Alternatively, you can get/set project-wide parameters using MavenProject.getProperties().
I guess the maven way would be to set a property in the first Mojo and to access it from the other Mojo.
This turns out to be a tricky thing to do mostly due to the timing of "configuration" of the plugins by the Maven runtime. Changing the "configuration" from getBuildPlugins is usually not going to work.
The best method is default-value if you are writing the target plugin, otherwise use properties.
With properties, but you have to be careful about how you use the properties. The caution is to realize that if your POM (or any parent) defines a value for a property, then the ${property} reference will be replaced when the POM is loaded. However if there is no "property" property then the ${property} reference stays and is only replaced with a null value at the last possible moment.
"default-value" is also evaluated at the last possible moment, and I think this is a safer solution because there is a logical reason why it must be evaluated at the last possible moment, where-as the non-existent property may just be an implementation detail that could change in future versions of Maven.
In my case I had to resort to properties because I wanted to control the "classesDirectory" of the surefire plugin. I wanted it to continue to default to ${project.build.outputDirectory} when Cobertura was not run, but when Cobertura was run I wanted it to use ${project.build.outputDirectory}/generated-classes/cobertura.
Define in your plugins section:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<classesDirectory>${instrumentedClassesDirectory}</classesDirectory>
</configuration>
</plugin>
Then in the "source" plugin:
getProject().getProperties().put("instrumentedClassesDirectory", coberturaDir);
And make sure under no circumstances ever put anything like the following in any POM:
<properties>
<instrumentedClassesDirectory>${project.build.outputDirectory}</instrumentedClassesDirectory>
</properties>
because if you do, even though the value of the property is set by your source plugin, your destination plugin will not see the value. You can ignore this last caveat if your using a property passed into the default-value of the source plugin, but as said in my case that would not work because I did not want to change the value of project.build.outputDirectory.