Hi,
as a plugin developer what is the recommended way of reading convention
properties and setting the values to fields of classes that implement
DefaultTask? In the past all my Task classes used to extend the internal
class org.gradle.api.internal.ConventionTask and had to access fields using
Hi,
When writing a custom plugin I came across the following situation. I'd like
to dynamically add a task based on the value of one of the fields in my
convention object. However, when I try to identify the task implementation
class the convention object's values haven't been initialized yet.
Thanks for you reply. The closure project.afterEvaluate makes it happen for
me. I was afraid the tasks wouldn't show up when running gradle tasks but
it turns out it that it works just fine.
Ben
--
View this message in context:
Hi all,
I just released a first version of a
https://github.com/bmuschko/gradle-izpack-plugin IzPack plugin .
http://izpack.org/ IzPack is a one-stop solution for packaging,
distributing and deploying applications for the Java platform. As always let
me know if you have comments or feature
I ran into the same issue and created a ticket for it:
http://issues.gradle.org/browse/GRADLE-1628 GRADLE-1628 .
--
View this message in context:
http://gradle.1045684.n5.nabble.com/gradle-clean-doesn-t-work-when-you-override-the-classes-dir-tp1431960p4511293.html
Sent from the gradle-user
Hi,
I am trying to define a repository in my build script simliar to the
mavenCentral() syntax. To make this work I created a method that returns an
instance of URLResolver.
def gitHub() {
def resolver = new URLResolver()
resolver.with {
name = 'GitHub'
I saw that better plugin support is on the roadmap for Gradle 1.0. I am
really looking forward to these improvements.
Sounds good. It would be great if we could discuss better ways to load
plugin classes and its dependencies via Skype. I'll shoot you a mail with my
Skype name and my times of
Rolf,
I added the property cargo.protocol and pushed out a new version of the
plugin. Give it a shot. However, it might not work for Jetty due to
http://jira.codehaus.org/browse/CARGO-977 CARGO-977 .
Cheers,
Ben
--
View this message in context:
The code doesn't actually use Class.forName(). It uses
Thread.currentThread().contextClassLoader.loadClass(). See this
https://github.com/bmuschko/gradle-tomcat-plugin/blob/master/embedded/src/main/groovy/org/gradle/api/plugins/tomcat/embedded/TomcatServerFactory.groovy
class for more
You're welcome. Keep us posted about your bugfix. ;-)
Cheers,
Ben
--
View this message in context:
http://gradle.1045684.n5.nabble.com/ANN-Cargo-plugin-v0-1-tp4433581p4439686.html
Sent from the gradle-user mailing list archive at Nabble.com.
Gradle provides the Java Servlet API and JSP API JARs in the
Gradle-home/lib/plugins directory by default. Both libraries are required
to run the Jetty plugin. BTW: I don't quite like this and hope that Gradle
will require plugins to define their dependencies in the future. They should
only pulled
Hi,
I read postings of people on this mailing list that were asking about
automatic deployment of their apps (mostly web apps). The
https://github.com/bmuschko/gradle-cargo-plugin Cargo plugin supports
deployment to a variety of local and remote containers by wrapping the
Hi,
The
https://github.com/downloads/bmuschko/gradle-tomcat-plugin/gradle-tomcat-plugin-0.7.jar
plugin JAR file in the GitHub download section definitely has the class in
it. Did you try to build the plugin from source? If yes you might have
called the wrong Gradle task. If that doesn't help
OK, great. The embedded Tomcat implementation requires you to put slightly
different JAR files into your classpath than the full-blown Tomcat
installation. Think of it as a minimalistic version of a Tomcat
installation. You also have to consider transitive dependencies that you
declare in your
My guess is that you have to include the dependency
org.eclipse.jdt.core.compiler:ecj:ecj-3.6.jar in your classpath.
Unfortunately, this dependency referred to by the Tomcat 7 dependencies does
not exist in the Maven Central repository. Apparently, the Tomcat guys did a
sloppy job of making sure
The library ecj-3.6.2.jar should be defined in the dependencies closure of
the buildscript closure...same place where you define all the other Tomcat
dependencies. Otherwise, you'll probably package the library in your WAR
which you don't want to do. This is a runtime dependency that Tomcat
Brett,
Check this
http://gradle.1045684.n5.nabble.com/Exclude-transitive-dependency-in-buildscript-closure-td4306720.html#a4308181
thread . It looks like this might be a bug in Gradle. I opened a
http://issues.gradle.org/browse/GRADLE-1478 ticket for this. As a
workaround you can exclude
From my point of view the easiest way to achieve that would be to set up a
Continuous Integration server instead. It's easy to configure emails
individually for each project. Furthermore, it doesn't complicate your build
scripts.
Ben
--
View this message in context:
Hi,
I was wondering what the recommended way is to get the Gradle home directory
of the current build being executed. I had a look at the JavaDoc of
Gradle.java and its method
http://www.gradle.org/latest/docs/javadoc/org/gradle/api/invocation/Gradle.html#getGradleHomeDir%28%29
Hi,
Vladimir Orany and I are happy to announce that we released a first version
of the https://github.com/bmuschko/gradle-gaelyk-plugin Gradle Gaelyk
plugin . At the moment the plugin provides the following tasks/task rules:
- gaelykInstallPlugin: Installs plugin provided by the command line
Thanks, individual exclusion in the dependencies closure worked. I put in a
ticket for the exclusion in the configuration closure:
http://issues.gradle.org/browse/GRADLE-1478 GRADLE-1479.
--
View this message in context:
Hi,
I would like to exclude a transitive dependency in the classpath
configuration of my buildscript closure. However, it doesn't seems to be
taken into account. Gradle still tries to resolve the dependency. The one I
want to exclude is org.eclipse.jdt.core.compiler:ecj:3.6. Is this maybe
related
Hi,
I released a new version of the
https://github.com/bmuschko/gradle-gae-plugin GAE plugin : 0.3. It contains
two new features:
- Support for running local development server as daemon.
- Allow providing password via gradle.properties or convention property.
If you have comments or feature
Hi,
I need users to store their password in a Gradle script. For security
reasons I don't want them to store the password in plain text. Does Gradle
provide some kind of password encryption mechanism like e.g.
http://maven.apache.org/guides/mini/guide-encryption.html Maven does ?
Thanks,
Ben
Thanks for your reply. Yeah, that would be an option. In my case I want to
run the Gradle build on a Continuous Integration server so everybody that
has access to the login could read the plain text password. Maybe I should
just make sure all other users don't have a read file permission on
Hi,
I'd like to pre-define the value of JAVA_OPTS in the shell startup script
generated by the application plugin. It looks to me as if there's no
convention property for it yet. Does anybody know how to make this work?
Thanks,
Ben
--
View this message in context:
Thanks for pointing me to your plugin. I'll def. have a look. Unfortunately,
it's not for artifact uploading. I guess what I actually want is obfuscation
which is easy enough to implement with a key stored somewhere else.
--
View this message in context:
Sure thing, here's the http://issues.gradle.org/browse/GRADLE-1456 ticket .
Thanks for the workaround.
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Convention-property-to-set-JAVA-OPTS-in-application-plugin-tp4264223p4264571.html
Sent from the gradle-user mailing list
Thanks! Luckily I read the warnings beforehand. I didn't update my Java on
OSX yet.
Ben
--
View this message in context:
http://gradle.1045684.n5.nabble.com/ANN-Google-App-Engine-Plugin-tp3914645p3966283.html
Sent from the gradle-user mailing list archive at Nabble.com.
Thanks for your feedback, Peter. I appreciate it.
The Spock Web Console is a Gaelyk app right? In Gaelyk apps the exploded WAR
directory is basically represented by the war directory. What you'd need
to do is to change the default webapp directory in your build.gradle.
webAppDirName = new
Alright, pushed out version 0.2 of the plugin that incorporates fixes for
your feedback. Give it a try. I tested it with the Spock Web Console project
as well as another project. gaeRun now uses the exploded WAR directory.
Optionally, you can override this behavior by setting the convention
Hi,
I am trying to add a classpath dependency in a custom plugin instead of
defining it in my build script like this.:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'commons-lang:commons-lang:2.5', --- shows an example of a
JAR I want to move
Hi René,
Thanks for your answer. The dependency needs to be applied before I run my
plugin code because it's using it. Yes, I am making the call in the plugin
apply method.
class ThePlugin implements Plugin {
@Override
public void apply(Project project) {
ThePluginConvention
Thanks for clarifying, Peter. It would be great if that could be incorporated
as a feature in future Gradle versions.
Ben
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Defining-buildscript-dependency-in-custom-plugin-tp3620230p3634827.html
Sent from the gradle-user
Not sure if it helps you for your specific case but you might want to have a
look at the Gradle Tomcat plugin:
https://github.com/bmuschko/gradle-tomcat-plugin. In case you want to use
Tomcat as a development container this might be the way to go.
Ben
DarthMaul wrote:
I would like to start
Can you double-check that the JSTL, JSP and Servlet JARs are not included in
the WEB-INF/lib directory inside your WAR file? Please also make sure you
delete the Tomcat work directory and a previously deployed version (WAR file
under webapps and it's exploded dir).
The providedCompile scope for
Robert, thanks for your suggestions. It looks like it doesn't work with the
regular GitHub download URL pattern e.g.
http://github.com/bmuschko/gradle-tomcat-plugin/downloads/[module]-[revision].[ext]
Instead I used this URL pattern which works fine:
I am trying to resolve a JAR file from GitHub but have the same issue. Is
there any kind of workaround to make this work? It would be great to use the
GitHub download section as repository.
Thanks,
Ben
--
View this message in context:
Hi,
I created an equivalent to the Jetty plugin to deploy your web application
to an embedded Tomcat container. The usage of the plugin is very similar to
the Jetty plugin. You can find a
https://github.com/bmuschko/gradle-tomcat-plugin first release and
instructions on how to use it on
This issue has already been filed here:
http://jira.codehaus.org/browse/GRADLE-1099
--
View this message in context:
http://gradle.1045684.n5.nabble.com/StackOverflowError-in-idea-plugin-tp3207809p3291668.html
Sent from the gradle-user mailing list archive at Nabble.com.
Russel,
you can add this to your Gradle build file:
[compileGroovy, compileTestGroovy]*.options*.encoding = 'UTF-8'
It tells the Groovy compiler to use UTF-8 encoding for Groovy (test)
sources.
Ben
--
View this message in context:
41 matches
Mail list logo
