What is the recommended way to include a grails plugin for in a 2.1.0 project?
1: Add it to the application.properties?
app.grails.version=2.1.0
app.name=testapp-local
app.version=0.1
plugins.build-test-data=2.0.3
plugins.fixtures=1.1
plugins.hibernate=2.1.0
plugins.pretty-time=0.3
plugins.mail=1.0
plugins.quartz=0.4.2
plugins.spring-security-core=1.2.7.3
plugins.tomcat=2.1.0
2: Specify it in buildConfig.groovy?
plugins {
runtime ":hibernate:$grailsVersion"
runtime ":jquery:1.7.2"
runtime ":resources:1.1.6"
// Uncomment these (or add new ones) to enable additional resources capabilities
//runtime ":zipped-resources:1.0"
//runtime ":cached-resources:1.0"
//runtime ":yui-minify-resources:0.1.4"
build ":tomcat:$grailsVersion"
runtime ":database-migration:1.1"
compile ':cache:1.0.0'
}
Thanks
I would always put it in buildConfig.groovy since this allows
to define the scope of the dependency
exclude unwanted dependencies, which can save you a lot of trouble
Btw: found an interesting thread on this here, that actually treats the exact same question:
http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-td4313370.html
HTH
Related
I am trying to provide an HttpClient from the outside to my ktor server so that I can mock external services and write tests, however I get this exception when I run my test:
Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
io.ktor.server.application.DuplicatePluginException: Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
at app//io.ktor.server.application.ApplicationPluginKt.install(ApplicationPlugin.kt:112)
at app//com.example.plugins.HTTPKt.configureHTTP(HTTP.kt:13)
at app//com.example.ApplicationKt.module(Application.kt:14)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:39)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:38)
and thats a bit unexpected to me because I am not applying the Compression plugin twice as far as I can tell. If I run the server normally and manually call my endpoint with curl then it works as expected. What am I doing wrong?
I added a runnable sample project here with a failing test.
sample project
official ktor-documentation-sample project.
The problem is that you have the application.conf file and by default, the testApplication function tries to load modules which are enumerated there. Since you also explicitly load them in the application {} block the DuplicatePluginException occurs. To solve your problem you can explicitly load an empty configuration instead of the default one:
// ...
application {
module(client)
}
environment {
config = MapApplicationConfig()
}
// ...
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
I followed the Kotlin tutorial for eclipse here : Getting Started With Eclipse Luna
However, I'm running into this error:
Error: Could not find or load main class _DefaultPackage
Anyone who knows to get around this?
This was a severe bug (KT-10221) in automatic generation of Launch Configuration in plugin version 0.4.0. It was fixed in 0.5.0 so the recommendend way to workaround is to update plugin.
The source of the problem was that the plugin used an old pattern for generating name of the class for main function that had been abandoned by Kotlin compiler.
It's possible to workaround it by editing launch configuration (Eclipse Menu -> Run -> Run Configurations...) by hand and changing Main class field in Java Application group. If the file is named hello.kt with no package directive, as it is described in tutorial, than corrected string should be HelloKt.
If file has name other.kt with package my.tutorial than the Main Class should contain my.tutorial.HelloKt. You can read more about it in the section Package-Level Functions of Calling Kotlin From Java page.
I have been getting the same issue. And after putting the right compiler output path, it got resolved.
Go to Project -> Project Compiler output :
In the text box, fill this:
[Absolute Path]/{Project Name}/out
In my case I was having this problem while trying to run the program using the Application Gradle plugin. The problem was in the mainClassName property using single quotes instead of double ones
This didn't work:
mainClassName = 'demo.HelloWorldKt'
With double quotes, it works:
mainClassName = "demo.HelloWorldKt"
For me it worked after I installed the correct JDK. I first had JDK 11 but the tutorial I did was with JDK 8 so after I installed this and set it in the "installed JREs" options it found the main class without having any "mainClassName" or any other option in the build.gradle file.
For me, it worked in a fresh eclipse workspace. Possibly, the Kotlin eclipse plugin is not playing well with other plugins (in my case, PyDev).
I'm creating a Kotlin Application with JavaFX and I had this issue until I went to:
Run > Run Configurations > Java Application > Common
I unticked "Allocate console" and it fixed the issue.
Trying to achieve this proposal to make a div size based on its background image I'm using Less 2.5.1 compiled by Web Essentials 2013 for Update 4 version 2.5.4 and some functions do not resolve:
My Less File:
.myClass{
height:image-height("myUrl.png"); //<-- Do not resolve
width:percentage(1/2); //<--Resolves
}
Resolved Css File:
.myClass{
height:image-height("myUrl.png"); //Not good
width:50%; //Good
}
I'm having this problem with image-height, image-width and image-size. Not with the rest of Misc Functions
There's no problem resolving the image by the compiler, because it's working fine when I used it like:
background-image:url("myUrl.png");
In the documentation there's a note for these methods saying:
Note: this function needs to be implemented by each environment. It is
currently only available in the node environment.
In the WebEssentials documentation it says:
Web Essentials uses the node-less compiler and it always uses the
latest version
And
NodeJS compilation - Web Essentials uses NodeJS to run the compiler.
It's the fastest and most accurate compiler for LESS available.
I'm missing something that I don't know. What does that note mean? What
should I do?
I've create a jsfiddle to share with you my goal.
I'm wrapping up the build for a web project which supports two ways of running:
locally using mvn jetty-run;
deployed on an application sever.
For the application server many libraries are marked as provided, since otherwise classpath conflicts occur. At the same time, I have redeclared these dependencies as compile dependencies for the jetty-maven-plugin, since otherwise the goals does not run properly.
The build works like this, but I have a large number of duplicated libraries. Is there a cleaner way of doing this?
Just to follow up on this JETTY-429 has been merged so you can with caution add a configuration parameter <useProvidedScope>true</useProvidedScope>. This will included the provided dependencies on the jetty plugin classpath.
It is worth reading JETTY-429 for details on the potential issues using this option can bring.
Well there's always the wicket solution. (It doesn't have to do anything with wicket, but it can be found in the wicket maven archetype.)
Use a main class that starts jetty programmatically with the project as webapp context. This should pick up all maven dependencies even in provided scope on all major IDEs. Here is such a class:
public class Start{
private static final Logger LOG = Logger.getLogger(Start.class);
public static void main(final String[] args) throws Exception{
LOG.addAppender(new ConsoleAppender(new SimpleLayout(), "system.out"));
final Server server = new Server();
final SocketConnector connector = new SocketConnector();
// Set some timeout options to make debugging easier.
connector.setMaxIdleTime(1000 * 60 * 60);
connector.setSoLingerTime(-1);
connector.setPort(9090);
server.setConnectors(new Connector[] { connector });
final WebAppContext bb = new WebAppContext();
bb.setServer(server);
bb.setContextPath("/");
bb.setWar("src/main/webapp");
server.addHandler(bb);
try{
LOG.info(//
">>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP" //
);
server.start();
System.in.read();
LOG.info(">>> STOPPING EMBEDDED JETTY SERVER");
server.stop();
server.join();
} catch(final Exception e){
LOG.error("Something bad happened", e);
System.exit(100);
}
}
// CHECKSTYLE:ON
}
The nice part: you can launch this as a standard eclipse run configuration, including easy debugging.
The downside: you need jetty as an additional provided dependency:
<!-- JETTY DEPENDENCIES FOR TESTING -->
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-util</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
I'm not saying this is the best solution, but how about doing this:
Your default dependencies list the provided dependencies as "provided". The default project configuration should produce WAR files which are going to run on non-Jetty servers.
Define a profile "jetty" and redeclare the provided dependencies in the compile scope. Then just run mvn -Pjetty jetty:run
It might not be the cleanest solution in the world, as it forces some repetition, but it should get the job done for you.
I'd also like some kind of flag to be able to include provided scoped dependencies when running Jetty. Actually, Jetty already has a useTestClasspath doing something similar for test scoped dependencies (why not including provided dependencies in that case) in order to avoid having to duplicate dependencies in a profile. This is tracked by JETTY-429 which has a patch for such a flag.