Ok, so when I build my plugin I get (for example)
bas-plugins-l10n-1.0.0-SNAPSHOT.jar in
~/dev/sag/bas/trunk/modules/plugins-l10n/build/libs directory.
We have an init.gradle in ~/.gradle which adds in a global repo for all
gradle projects. So I added in the plugin lib dir to the init.gradle as
h
Can't you just use buildSource then? That is exactly what I do for
prototyping plugins.
On Wednesday, March 23, 2011, at 02:55 pm, phil swenson wrote:
> I have a plugin project I am starting. Others in the company have already
> written some plugins, but the way they have it set up to work is y
Thanks everyone.
On Mar 23, 2011 12:05 AM, "Brett Cave" wrote:
> On Tue, Mar 22, 2011 at 6:24 PM, Merlyn Albery-Speyer <
> curious.attempt.bu...@gmail.com> wrote:
>
>> Hi all,
>>
>> I've a gradle project with a reasonable number of dependencies*. I'm
>> using an Artifactory server as my mavenCentr
Hi Phil,
You can definitely do that. You just need to define a flat directory inside
of your repositories closure (make sure it's within the buildscript
closure).
buildscript {
repositories {
flatDir(dirs: "")
mavenCentral()
}
dependencies {
classpath '::'
I have a plugin project I am starting. Others in the company have already
written some plugins, but the way they have it set up to work is you have to
upload a plugin to the artifact repository to actually execute it from the
build.gradle script(s).
What I want is an ability to put the built plug
I have the following at the top of my build.gradle file:
apply plugin: 'groovy'
apply plugin: 'idea'
apply from:
'https://github.com/valkolovos/gradle_cobertura/raw/master/ivy/gradle_cobertura/gradle_cobertura/1.0-rc4/coberturainit.gradle'
After running 'gradle cobertura', I open the coverage
On Debian Testing: If I use OpenJDK 6 then uploading archives works
fine. If I use the Sun JDK then I get:
Execution failed for task ':extra166y:uploadArchives'.
Cause: Could not publish configurations [configuration
':extra166y:archives'].
Cause: Error deploying artifac
Figured it out - I had proxy settings in gradle.properties but wasn't
connected to our VPN. So the proxy server was not found and Gradle was
unable to resolve any dependencies that had not already been downloaded.
Mike
On Wed, Mar 23, 2011 at 11:40 AM, Mike Hugo wrote:
> Hello,
> I'm trying to
>We do want to add something to allow you to pass arbitrary configuration
from the command-line.
>For example, there might be a general capability where you can do something
like 'gradle createModule >module= plugin=' or perhaps 'gradle
createModule --module --plugin ' and Gradle will automatical
Hello,
I'm trying to include the Postgres JDBC Driver jar via our Gradle build.
build.gradle looks like this:
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'groovy'
version = 1.0
repositories {
mavenCentral()
}
dependencies {
groovy group: 'org.codehaus.groovy', name: 'gro
Gradle configures all tasks, even ones that eventually don't get executed.
One way to solve your problem is to wrap the asserts with doFirst {}:
task revertServerVMImage( type: Exec ) {
doFirst {
assertPropertySet('remoteHostname')
assertPropertySet('shortname')
}
I am fairly new to gradle so this might be a silly question.
I have the following code:
task revertServerVMImage( type: Exec ) {
assertPropertySet('remoteHostname')
assertPropertySet('shortname')
commandLine = ...
}
task someOtherTask << {
println 'Foo..
i didn't want to type every time in commandline gradle copy...
i wanted it in some automatic way and from log in the console it seems to be
executed after all tasks. I'm using the java plugin, report plugin, and the
eclipse plugin and here is the output
:clean
:compileJava UP-TO-DATE
:compileGroov
On Wed, Mar 23, 2011 at 3:41 PM, shadowlaw wrote:
> in case someone need it, i've done it this way
>
> task copyToLib(dependsOn: configurations.default.buildArtifacts, type:
> Copy)
> {
>into "$buildDir/output/lib"
>from configurations.default
>from configurations.default.allArtifactF
Hey,
jvmArgs property is the way to go. See the documentation on the Test task:
http://gradle.org/1.0-milestone-1/docs/dsl/org.gradle.api.tasks.testing.Test.html
Example:
test {
jvmArgs '-Xmx1024m', '-XX:MaxPermSize=256m',
'-XX:+HeapDumpOnOutOfMemoryError'
}
Cheers!
Szczepan
On Wed, Mar 23,
in case someone need it, i've done it this way
task copyToLib(dependsOn: configurations.default.buildArtifacts, type: Copy)
{
into "$buildDir/output/lib"
from configurations.default
from configurations.default.allArtifactFiles
}
then call my task like this
defaultTasks: 'copyToLib'
wi
Hi I've got some unit tests failing with OutOfMemoryError's. How can I add
the vm argument :+HeapDumpOnOutOfMemoryError to the tests so I can get heap
dump.
Is it the test jvmArgs property I need to set? Will this affect my
maxHeapSize setting?
My test task look as follows:
test {
On Wed, Mar 23, 2011 at 10:17 AM, Adam Murdoch
wrote:
>
> On 23/03/2011, at 7:40 PM, Jeppe Nejsum Madsen wrote:
>
> Adam Murdoch writes:
>
> On 22/03/2011, at 7:24 AM, Jeppe Nejsum Madsen wrote:
>
> On Mon, Mar 21, 2011 at 6:39 PM, Peter Niederwieser
>
> wrote:
>
> Jeppe Nejsum Madsen wrote:
>
>
On 23/03/2011, at 7:40 PM, Jeppe Nejsum Madsen wrote:
> Adam Murdoch writes:
>
>> On 22/03/2011, at 7:24 AM, Jeppe Nejsum Madsen wrote:
>>
>>> On Mon, Mar 21, 2011 at 6:39 PM, Peter Niederwieser
>> wrote:
Jeppe Nejsum Madsen wrote:
>
> I just upgraded from 0.9.2 to 1.0-M1
Adam Murdoch writes:
> On 22/03/2011, at 7:24 AM, Jeppe Nejsum Madsen wrote:
>
>> On Mon, Mar 21, 2011 at 6:39 PM, Peter Niederwieser
> wrote:
>>>
>>> Jeppe Nejsum Madsen wrote:
I just upgraded from 0.9.2 to 1.0-M1 and now the test results seem
> to get
the package name wrong.
>
On Tue, Mar 22, 2011 at 6:24 PM, Merlyn Albery-Speyer <
curious.attempt.bu...@gmail.com> wrote:
> Hi all,
>
> I've a gradle project with a reasonable number of dependencies*. I'm
> using an Artifactory server as my mavenCentral. When I get a fresh
> checkout of my project and generate an idea proj
21 matches
Mail list logo
