Nabble - codehaus - Gradle

Re: Adding two new features to Gradle

2009-11-26T13:07:46Z

John Murph wrote:

On Mon, Nov 23, 2009 at 4:20 PM, Adam Murdoch <a@...> wrote:

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

LOL, thanks Adam. I was worried about 2 seconds, then realized that there was no way you wanted me to do all that. I think I like the unification of these items, they are obviously very related. What class would have the configure(*) methods? This would need to be available to almost everything. Your unification thoughts almost relegate init/settings/build scripts to different flavors of a single thing. Maybe a common base class for the delegate objects for these scripts? Or maybe composition? I think I prefer composition here, but there are several methods that will need to be delegated. Maybe a "ConfigurableScript" interface to describe the method signatures, a "ScriptExecutor" class that contains the implementation (and implements the "ConfigurableScript" interface). Then each of the appropriate classes can implement the interface and delegate those methods to the class. Seems inelegant, but reasonable.

This is a good plan. Every script that Gradle compiles ends up as a subclass of org.gradle.groovy.scripts.Script, so you could change that to implement ConfigurableScript. This means that the configure(*) methods will be available from every script. Then, you could perhaps just change Project or Gradle to implement ConfigurableScript as well, so that the configure(*) methods are available outside the scripts (eg plugins, java classes, etc).

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

From forum: gradle-dev

Re: conditional artifact publication

2009-11-26T12:59:40Z

Ross Black wrote:

> Hi,
>
> Is there a way to conditionally add an artifact to a configuration,
> where the condition is evaluated at runtime?
> eg. I only want to add an artifact if a specific directory exists.
>
> I was hoping the following would work (but it does not):
> ---
> project.configurations {
> api
> }
>
> Task apiTask = project.task('apiJar', type: Jar, dependsOn:
> 'classes') {
> fileSet(dir: project.apiClassesDir)
> }
> apiTask.onlyIf {project.apiClassesDir.exists()}
>
> project.artifacts {
> api apiTask
> }
> ---
>
> The apiJar task correctly only generates the jar if the directory
> exists, but the artifact handler always expects that the file
> specified by the apiJar task exists even if the task has not run.
>
> Is there some other way to achieve this?
>

Not really. Could you add a JIRA issue for this?

I can't think of a good work-around, either. Is it possible to figure
out at configuration time whether the api jar is needed?

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Java heap space during uploadArchives execution

2009-11-26T09:39:08Z

Change your max heap size via GRADLE_OPTS

~~ Robert.

Erwan.LACOSTE@... wrote:

>
> Hi all,
>
> I'm facing a Java heap space during the upload of my files to Maven.
> I've looked into the mailing list, but the only matching problems
> actually come from the compiler. Here the execution of the task is in
> error:
>
> Caused by: org.gradle.api.GradleException: Could not publish
> configurations [configuration 'archives'].
> at
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:44)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
>
> at org.gradle.api.tasks.Upload.upload(Upload.java:57)
> at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy)
> at
> org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)
> at
> org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125)
>
> at
> org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123)
>
> at
> org.gradle.api.internal.AbstractTask.doExecute(AbstractTask.java:257)
> at
> org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:222)
> ... 11 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338)
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305)
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267)
> at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:238)
> at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143)
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:148)
>
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
>
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
>
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
>
> at
> org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117)
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.CustomDeployTask.doExecute(CustomDeployTask.java:42)
>
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
>
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.execute(AbstractMavenResolver.java:186)
>
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.commitPublishTransaction(AbstractMavenResolver.java:178)
>
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:263)
> at
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyPublisher.publish(DefaultIvyDependencyPublisher.java:62)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyService.publish(DefaultIvyService.java:127)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.ShortcircuitEmptyConfigsIvyService.publish(ShortcircuitEmptyConfigsIvyService.java:61)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:42)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
>
> at org.gradle.api.tasks.Upload.upload(Upload.java:57)
>
> Any ideas? Trying :
>
> uploadArchives {
> (…)
> options.fork(memoryMaximumSize: '512m')
> }
>
> Didn't work for me…
>
> Thanks in advance.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Java heap space during uploadArchives execution

2009-11-26T09:37:54Z

Java heap space during uploadArchives execution

Hi all,

I'm facing a Java heap space during the upload of my files to Maven. I've looked into the mailing list, but the only matching problems actually come from the compiler. Here the execution of the task is in error:

Caused by: org.gradle.api.GradleException: Could not publish configurations [configuration 'archives'].
at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:44)

        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
        at org.gradle.api.tasks.Upload.upload(Upload.java:57)
        at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy)
        at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)
        at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125)

at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123)

        at org.gradle.api.internal.AbstractTask.doExecute(AbstractTask.java:257)
        at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:222)
        ... 11 common frames omitted
Caused by: java.lang.OutOfMemoryError: Java heap space
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338)
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305)
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267)
        at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:238)
        at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143)
        at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:148)
        at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
        at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
        at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
        at org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117)
        at org.gradle.api.internal.artifacts.publish.maven.deploy.CustomDeployTask.doExecute(CustomDeployTask.java:42)
        at org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
        at org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.execute(AbstractMavenResolver.java:186)

at org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.commitPublishTransaction(AbstractMavenResolver.java:178)

at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:263)
at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyPublisher.publish(DefaultIvyDependencyPublisher.java:62)

at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyService.publish(DefaultIvyService.java:127)
at org.gradle.api.internal.artifacts.ivyservice.ShortcircuitEmptyConfigsIvyService.publish(ShortcircuitEmptyConfigsIvyService.java:61)

at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:42)

at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
at org.gradle.api.tasks.Upload.upload(Upload.java:57)

Any ideas? Trying :

uploadArchives {
(…)
options.fork(memoryMaximumSize: '512m')
}

Didn't work for me…

Thanks in advance.

From forum: gradle-user

Downloading *-sources

2009-11-26T05:10:29Z

Hi,

Is there a way to tell Gradle to download the sources of the jar files as well? I looked at this thread: http://old.nabble.com/Dowloading-*-sources.jar-td22064471.html#a22064471, but it looks like Artifact is no longer there, and wondered if there is a better way to do this.

Cheers,
Shay

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T21:10:09Z

Just wanted to verify that this works, thanks for the help.

My eyes simply glanced over it (its late) ..., sorry.

Paul Speed-2 wrote:

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:
> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T20:59:16Z

My eyes simply glanced over it (its late) ..., sorry.

Paul Speed-2 wrote:

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:
> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

[ANN] SmokejumperIT Gradle-Plugins 0.1

2009-11-25T15:47:39Z

I'm starting to release my plugins, and I've figured out a reasonably
simple way for people to use them. See my README here:
http://github.com/RobertFischer/gradle-plugins/blob/master/README.md

Currently, I've released two plugins: ClassLoaders and Exec. They allow
you to gain access to a classloader based on a configuration and execute
shell scripts (respectively).

A RunJRuby and a Cucumber plugin are coming presently. The goal will be
to eat Cuke4Duke's lunch: I've been underwhelmed with Cuke4Duke's
ease-of-use.

Also thinking about a Conventional plugin, which would add source sets
based on the existence of directories, use the ~/.m2 repo, and maybe do
a few other standard stunts. And, finally, I'm considering two
ease-of-use plugins: com.smokejumperit.gradle.AllPlugins (which simply
pulls in all the plugins in the com.smokejumperit.gradle suite) and
com.smokejumperit.gradle.FavoritePlugins (which pulls in all my favorite
plugins with some pre-configuration).

Just FYI, Gradle is featuring prominently in my book on Polyglot
Programming. :)

~~ Robert.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T14:53:06Z

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:

> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T14:25:27Z

Thanks!,

I will try it, but won't it copy over the java files as well? Can I control the inclusion / exclusion for it?

Shay

Adam Murdoch-2 wrote:

Shay Banon wrote:
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
>

Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
will ignore any files it finds in the resource dirs which are also
included in the java dirs (or groovy or scala dirs, if appropriate).

To do this, you can do something like:

sourceSets.main.resources.srcDir 'src/main/java'
sourceSets.test.resources.srcDir 'src/test/java'

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T14:22:02Z

Shay Banon wrote:
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
>

Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
will ignore any files it finds in the resource dirs which are also
included in the java dirs (or groovy or scala dirs, if appropriate).

To do this, you can do something like:

sourceSets.main.resources.srcDir 'src/main/java'
sourceSets.test.resources.srcDir 'src/test/java'

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T13:37:28Z

Yea, I know that this is a possibility. I simply don't like that structure. Is there a way to solve what I asked?

Philip Crotwell wrote:

If you put them in src/main/resources instead, then they are copied
automatically. Just make a parallel directory structure to reflect the
java packages they are now in.

Philip

On Wed, Nov 25, 2009 at 4:27 PM, Shay Banon <kimchy@gmail.com> wrote:
>
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
> Thanks,
> Shay
> --
> View this message in context: http://old.nabble.com/Copy-non-java-files-into-the-target-directory-tp26520594p26520594.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Copy non java files into the target directory

2009-11-25T13:30:36Z

If you put them in src/main/resources instead, then they are copied
automatically. Just make a parallel directory structure to reflect the
java packages they are now in.

Philip

On Wed, Nov 25, 2009 at 4:27 PM, Shay Banon <kimchy@...> wrote:

>
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
> Thanks,
> Shay
> --
> View this message in context: http://old.nabble.com/Copy-non-java-files-into-the-target-directory-tp26520594p26520594.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Copy non java files into the target directory

2009-11-25T13:27:46Z

Hi,

What is the simplest way to configure gradle to copy non java files that exists within src/main/java or src/test/java into their respective target classes directory?

Thanks,
Shay

From forum: gradle-user

Re: Creating multiple jars

2009-11-25T08:20:10Z

Thanks Adam, 2 more questions:

- Is there a way to merge a signed jar - I would need either to remove the signatures or recompute them ?
- How can I have this jar (with the modified classifier) uploaded together with the "regular" one ?

On Tue, Nov 24, 2009 at 4:08 AM, Adam Murdoch <a@...> wrote:

tog wrote:

Hi folks,

In my project I would like to create multiple jars:
- one containing only the classes of my project (classic targer)
- a second one containing all dependencies,

In the cookbook, it is said that I can do this:

jar.doFirst {
for(file in configurations.compile) {
jar.merge(file)
}
}

What is the best way to achieve this ?

You can add another jar task to build the fat jar:

task fatJar(type: Jar) {
dependsOn classes
from sourceSet.main.classesDir
classifier = 'all' // Give the jar a different name
doFirst { task->

for(file in configurations.compile) {
task.merge(file)
}
}
}

Clone the jar task ?

Do something like a :
jar.doLast{
jar.copy(jar-minimal.jar)
for(file in configurations.compile) {
jar.merge(file)
}
}

Thanks for your help

Guillaume

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
PGP KeyID: 1024D/69B00854 subkeys.pgp.net

http://cheztog.blogspot.com

From forum: gradle-user

RE: Deploying to Maven

2009-11-25T06:24:50Z

Thanks for the answers Hans.

As promissed, I created a page inside the examples section of Gradle's Confluence. I cover there not only the Maven deploy part, but also environment configuration, which I started to speak about earlier this year.

For all of you who are interested in the problems raised by this topic, please have a look here for some answers:

http://docs.codehaus.org/display/GRADLE/complete+example+-+environment+managment+and+maven+deploy

But of course you're not gonna get out of here so easily as I have some other questions :) (most of them raised as TODOs in the previous link). I'll try to ask only the ones that would take me too long dig for, and I'll update the WIKI with the answer I get from myself eventually.

1) any SVN plugin? Anyway to Gradelly commit, tag or even branch something?

2) Anyway to change the project version number from the command line?

3) disable the disabling of tests. Meaning that skipping the tests would NOT be possible when running some definite tasks?

4) I noticed some behaviour with my multiproject tasks.

Here's roughly the structure:

ROOT/

SERVICE/

WEB-LAYER/

WAR-PROJECT/

WEB-LAYER is not a project, just a folder containing projects. When I run at the root "$gradle release", then the output would be:

:RASFF-core:compileJava
:RASFF-core:bind
[ant:echo] Binding with jibx...
:RASFF-core:processResources
:RASFF-core:classes
:RASFF-core:jar
:RASFF-core:uploadDefaultInternal
:RASFF-core:uploadArchives
:RASFF-core:release
:RASFF-web:compileJava ???????
:RASFF-web:processResources ????????
:RASFF-web:classes ??????????
:RASFF-web:jar SKIPPED ?????????
:RASFF-web:uploadArchives SKIPPED ???????
:RASFF-web:release ?????????
:RASFF-web:RASFF-web:compileJava
:RASFF-web:RASFF-web:processResources
:RASFF-web:RASFF-web:classes
:RASFF-web:RASFF-web:initConfiguration
no environment specified, skipping.
:RASFF-web:RASFF-web:war
version is: 2.2.0.DEV13-BUILD-6-SNAPSHOT
:RASFF-web:RASFF-web:uploadArchives
:RASFF-web:RASFF-web:release

As you see, I had to manually disable the 'RASFF-web' tasks. Why would Gradle run the tasks though I never declared RASFF-web as a project? This is not a blocker since I disabled the tasks, just a question of mine.

Thanks for your help,

Erwan

From forum: gradle-user

Re: Upload via SCP

2009-11-24T16:19:30Z

Okay, sorted it out: needed to set up a configuration and connect the
configuration a la the docs. Relying on 'classpath' is what was causing
the issue.

~~ Robert.

Robert Fischer wrote:

> The user guide (Table 29.1) says that I need
> 'org.apache.maven.wagon:wagon-scp:1.0-beta-2' for
> scp upload. But there is no such beast, at least not in the maven
> central repo. Is there a different repo I should use, or am I missing
> something?
>
> ~~ Robert.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Upload via SCP

2009-11-24T15:37:12Z

Okay, I changed to using wagon-ssh (the docs should be fixed), and now
I'm getting this error when I attempt to upload:

Caused by:
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error
deploying artifact: Unsupported Protocol: 'scp': Cannot find wagon which
supports the requested protocol: scp
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94)
at
org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117)
... 28 common frames omitted
Caused by: org.apache.maven.wagon.TransferFailedException: Unsupported
Protocol: 'scp': Cannot find wagon which supports the requested
protocol: scp
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:191)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
... 29 common frames omitted
Caused by: org.apache.maven.wagon.UnsupportedProtocolException: Cannot
find wagon which supports the requested protocol: scp
at
org.apache.maven.artifact.manager.DefaultWagonManager.getWagon(DefaultWagonManager.java:135)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:185)
... 31 common frames omitted
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component repository:
org.apache.maven.wagon.Wagonscp.

Upgrading to the most recent beta (1.0-beta-6) doesn't help.

Is anyone actually successfully uploading using scp? Can I see the
configuration file?

My build file is at:
http://github.com/RobertFischer/gradle-plugins/blob/master/build.gradle

~~ Robert.

Robert Fischer wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Upload via SCP

2009-11-24T14:54:31Z

The user guide (Table 29.1) says that I need
'org.apache.maven.wagon:wagon-scp:1.0-beta-2' for
scp upload. But there is no such beast, at least not in the maven
central repo. Is there a different repo I should use, or am I missing
something?

~~ Robert.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Adding two new features to Gradle

2009-11-24T08:21:58Z

On Tue, 2009-11-24 at 09:15 -0600, John Murph wrote:

> Thanks Tomek! My initial research shows that TestNG is much better in
> this respect than JUnit, so I don't think it'll be a problem.
>
First let us remove the extraneous words:

" . . . TestNG is much better . . . than JUnit. . . . "

then let us elide the elisions:

"TestNG is much better than JUnit."

Now as this is a true statement it would be really cool if everyone
thought "How do we do this for TestNG?" and then as a follow up "How do
we do this for JUnit".

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

From forum: gradle-dev

Re: Adding two new features to Gradle

2009-11-24T07:15:21Z

On Tue, Nov 24, 2009 at 12:22 AM, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

Hi John

TestNG definitely support listeners ! See
http://testng.org/doc/documentation-main.html#testng-listeners

Thanks Tomek! My initial research shows that TestNG is much better in this respect than JUnit, so I don't think it'll be a problem.

--
John Murph
Automated Logic Research Team

From forum: gradle-dev

Re: Adding two new features to Gradle

2009-11-24T07:13:36Z

On Mon, Nov 23, 2009 at 4:20 PM, Adam Murdoch <a@...> wrote:

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

LOL, thanks Adam. I was worried about 2 seconds, then realized that there was no way you wanted me to do all that. I think I like the unification of these items, they are obviously very related. What class would have the configure(*) methods? This would need to be available to almost everything. Your unification thoughts almost relegate init/settings/build scripts to different flavors of a single thing. Maybe a common base class for the delegate objects for these scripts? Or maybe composition? I think I prefer composition here, but there are several methods that will need to be delegated. Maybe a "ConfigurableScript" interface to describe the method signatures, a "ScriptExecutor" class that contains the implementation (and implements the "ConfigurableScript" interface). Then each of the appropriate classes can implement the interface and delegate those methods to the class. Seems inelegant, but reasonable.

--
John Murph
Automated Logic Research Team

From forum: gradle-dev

Re: Deploying to Maven

2009-11-24T04:29:55Z

On Nov 24, 2009, at 2:54 AM, <Erwan.LACOSTE@...> <Erwan.LACOSTE@...> wrote:

Hi all,
I'm trying to customize my Maven deploying tasks.
Here's what I would like to do in one task:
Generate the WAR file, generate the sources of the WAR project (including WEB-INF) and the sources of the depending project sources, upload to maven all 3 jar files (2 sources and WAR file).
Depending on command line arguments, the WAR release (and WAR source) could have a classifier.
I wish to block the release, if it's not a SNAPSHOT and the dependencies contains a SNAPSHOT.
I can do some of the things, but I'm stuck with others. I'll post all my work, so people can criticize if I'm too far from best practice, and give ideas to people having the same needs.
Root gradle:
subprojects {
    usePlugin 'java'
    version '2.2.0.DEV13-SNAPSHOT'
    task sourcesJar(type: Jar) {
        from sourceSets.main.allSource
        // wont work because of GRADLE-704

GRADLE-704 is fixed in trunk.

        classifier = 'sources'
    }
}
WAR gradle:
task initConfiguration << {
    // creates a ConfigSlurper containing all kinds of settings if an environment was set as a command line parameter.
    deployConfig = // whatever
}
war.doFirst {
    if (project.hasProperty('deployConfig') {
        // wont work because of GRADLE-704
        war.classifier = deployconfig.environment
        // Do some other things on the war
    }
}
sourcesJar {
    // How can I add the default WEB-INF directory to my sources?

from(projectDir) {

include "path_to_webinf"

}

// simply include "path_to_webinf" should do the job also. But there is a bug that prevents this from working ATM.

}
artifacts {
    archives war
    archives sourcesJar
}
uploadArchives {
    repositories.mavenDeployer {
        configuration = configurations.release // when I will need to deploy using WEB-DAV, configuration called 'release' is declared.
        repository(url: 'file://d:/erwan-dev/tmp/REPO')
        snapshotRepository(url: 'file://d:/erwan-dev/tmp/REPO-SNAPSHOT')
    }
}
def isSnapshotDependent() {
    def containsSnapshot = false
    // TODO I want to run the following only if i am releasing on the main repo.
    // should I check the presence of the string 'SNAPSHOT' in the projects version? How does the maven plugin knows that I'm uploading a SNAPSHOT or a main version?
    configurations.default.allDependencies.each { dep ->
        if (dep.version.indexOf('SNAPSHOT') > 0)
            containsSnapshot = true
    }
    return containsSnapshot
}

We use the Ant Maven tasks under the hood for deploying. The check the full artifact name for the 'SNAPSHOT' pattern and decide based on that whether to deploy to 'repository' or 'snapshotRepository'. But they don't make this information available.

task release(dependsOn: initConfiguration) << {
    // check that i'm not depending on a SNAPSHOT
    if (isSnapshotDependent()) {
        throw new GradleException("cannot release since dependencies contains a SNAPSHOT")
    }
    uploadArchives.execute() // is there a bug? Executing the task with the command line runs the 'war' task. Executing the same command from another task will not launch the 'war' task.
    // unless a parameter says NO
    uploadSources.execute() // knowing that I would wish for both this project and the "service" project sources to be uploaded. Maybe ServiceProject.uploadSources.execute() ?
}

What I would do is the following:

uploadArchives {

if (gradle.taskGraph.hasTask('release') {

if (isSnapshotDependent()) throw ...

}

...

}

task release{dependsOn: initConfiguration, uploadArchives) {

// do nothing at the moment.

}

uploadArchives will upload all artifacts that are only distinguished by the classifier.

As you see, I'm a little stuck until issue 704 is fixed (I will DL the latest trunk version soon).
My main concern is to create a task that will launch the 'uploadArchives' task. As I explained in a comment, right now launching 'uploadArchives' from another task wont trigger the 'war' task. Maybe this is a bug.

I don't think this is a bug. There are other, cleaner, ways to achieve this I think. Usually you shouldn't be forced to use the execute method at all.

I could get away from that by including the dependency manually of my custom task on 'war' and 'sourcesJar' tasks.
I wish there was an easy way to detect that a library version is a SNAPSHOT, including my own project.

I guess the Maven plugin could provide such a functionality. Could you file a Jira?

The documentation on Maven plugin is, how to say, evasive. Maybe I could post this draft on the wiki, so the community can bring their experience to it?

That would be excellent.

- Hans

Hans Dockter

Gradle Project Manager

http://www.gradle.org

Thanks in advance for the community help,
Erwan

From forum: gradle-user

conditional artifact publication

2009-11-24T04:14:07Z

Hi,

Is there a way to conditionally add an artifact to a configuration, where the condition is evaluated at runtime?
eg. I only want to add an artifact if a specific directory exists.

I was hoping the following would work (but it does not):
---
        project.configurations {
            api
        }

        Task apiTask = project.task('apiJar', type: Jar, dependsOn: 'classes') {
            fileSet(dir: project.apiClassesDir)
        }
        apiTask.onlyIf {project.apiClassesDir.exists()}

        project.artifacts {
            api apiTask
        }
---

The apiJar task correctly only generates the jar if the directory exists, but the artifact handler always expects that the file specified by the apiJar task exists even if the task has not run.

Is there some other way to achieve this?

Thanks,
Ross

From forum: gradle-user

Deploying to Maven

2009-11-24T00:54:54Z

Deploying to Maven

Hi all,

I'm trying to customize my Maven deploying tasks.

Here's what I would like to do in one task:

Generate the WAR file, generate the sources of the WAR project (including WEB-INF) and the sources of the depending project sources, upload to maven all 3 jar files (2 sources and WAR file).

Depending on command line arguments, the WAR release (and WAR source) could have a classifier.
I wish to block the release, if it's not a SNAPSHOT and the dependencies contains a SNAPSHOT.

I can do some of the things, but I'm stuck with others. I'll post all my work, so people can criticize if I'm too far from best practice, and give ideas to people having the same needs.

Root gradle:

subprojects {

usePlugin 'java'
version '2.2.0.DEV13-SNAPSHOT'

    task sourcesJar(type: Jar) {
        from sourceSets.main.allSource
        // wont work because of GRADLE-704
        classifier = 'sources'
    }
}

WAR gradle:

task initConfiguration << {
// creates a ConfigSlurper containing all kinds of settings if an environment was set as a command line parameter.
deployConfig = // whatever
}

war.doFirst {
    if (project.hasProperty('deployConfig') {
        // wont work because of GRADLE-704
        war.classifier = deployconfig.environment

// Do some other things on the war
}
}

sourcesJar {
// How can I add the default WEB-INF directory to my sources?
}

artifacts {
archives war
archives sourcesJar
}

uploadArchives {
repositories.mavenDeployer {
configuration = configurations.release // when I will need to deploy using WEB-DAV, configuration called 'release' is declared.

        repository(url: 'file://d:/erwan-dev/tmp/REPO')
        snapshotRepository(url: 'file://d:/erwan-dev/tmp/REPO-SNAPSHOT')
    }
}

def isSnapshotDependent() {
    def containsSnapshot = false
    // TODO I want to run the following only if i am releasing on the main repo.
    // should I check the presence of the string 'SNAPSHOT' in the projects version? How does the maven plugin knows that I'm uploading a SNAPSHOT or a main version?

    configurations.default.allDependencies.each { dep ->
        if (dep.version.indexOf('SNAPSHOT') > 0)
            containsSnapshot = true
    }
    return containsSnapshot
}

task release(dependsOn: initConfiguration) << {
    // check that i'm not depending on a SNAPSHOT
    if (isSnapshotDependent()) {
        throw new GradleException("cannot release since dependencies contains a SNAPSHOT")
    }
    uploadArchives.execute() // is there a bug? Executing the task with the command line runs the 'war' task. Executing the same command from another task will not launch the 'war' task.

// unless a parameter says NO
uploadSources.execute() // knowing that I would wish for both this project and the "service" project sources to be uploaded. Maybe ServiceProject.uploadSources.execute() ?

}

As you see, I'm a little stuck until issue 704 is fixed (I will DL the latest trunk version soon).
My main concern is to create a task that will launch the 'uploadArchives' task. As I explained in a comment, right now launching 'uploadArchives' from another task wont trigger the 'war' task. Maybe this is a bug. I could get away from that by including the dependency manually of my custom task on 'war' and 'sourcesJar' tasks.

I wish there was an easy way to detect that a library version is a SNAPSHOT, including my own project.

The documentation on Maven plugin is, how to say, evasive. Maybe I could post this draft on the wiki, so the community can bring their experience to it?

Thanks in advance for the community help,
Erwan

From forum: gradle-user

Re: Adding two new features to Gradle

2009-11-23T22:22:36Z

Hi John

TestNG definitely support listeners ! See
http://testng.org/doc/documentation-main.html#testng-listeners

thanks

--
Tomek

2009/11/23 John Murph <jmurph.alc@...>:

> On Mon, Nov 23, 2009 at 12:02 AM, Tomek Kaczanowski
> <kaczanowski.tomek@...> wrote:
>>
>> Hi John and all,
>>
>> > First is TestListener. This (if you can recall that far back) was the
>> > reason I did the listener manager changes. We need to have an init
>> > script
>> > that can register a listener that gets testing feedback from JUnit.
>> I read "JUnit", and immediately red light bulb started to blink in my
>> head :) - will it also work for TestNG ?
>>
>> --
>> Tomek
>>
>
> Hi Tomek,
>
> I am not very familiar with TestNG, but I would assume that it has support
> for listeners. If so, it would be reasonable to make it work for that as
> well. I will get JUnit working first, then we can see how difficult TestNG
> might be (I doubt it'll be hard).
>
> Is that a good enough non-answer for you? :)
>
>
> --
> John Murph
> Automated Logic Research Team
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-dev

Re: Creating multiple jars

2009-11-23T14:38:42Z

tog wrote:

> Hi folks,
>
> In my project I would like to create multiple jars:
> - one containing only the classes of my project (classic targer)
> - a second one containing all dependencies,
>
> In the cookbook, it is said that I can do this:
>
> jar.doFirst {
> for(file in configurations.compile) {
> jar.merge(file)
> }
> }
>
> What is the best way to achieve this ?
>

You can add another jar task to build the fat jar:

task fatJar(type: Jar) {
dependsOn classes
from sourceSet.main.classesDir
classifier = 'all' // Give the jar a different name
doFirst { task->
for(file in configurations.compile) {
task.merge(file)
}
}
}

> Clone the jar task ?
>
> Do something like a :
> jar.doLast{
> jar.copy(jar-minimal.jar)
> for(file in configurations.compile) {
> jar.merge(file)
> }
> }
>
> Thanks for your help
>
> Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-user

Re: Adding two new features to Gradle

2009-11-23T14:20:50Z

Adam Murdoch wrote:

John Murph wrote:
On Fri, Nov 20, 2009 at 3:53 PM, Adam Murdoch <a@...> wrote:

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task, so that the events are available just below the surface of the NativeTest task. We'd need to add some methods for adding a TestListener to NativeTest, with an impl of that used a ListenerManager to create its broadcaster. Then, the TestListener events would be available in the init script.

I don't think we should bother with trying to fit this into the AntTest task as well, and should instead focus on getting the NativeTest stuff ready.

OK, I'll have a look at the NativeTest stuff and see what I can figure out. This is the change that is most pressing for us as we currently don't have a workaround, so hopefully I can figure something out.

If you need something really soon, it might be better to try this with AntTest. Will be a little while before we make NativeTest the official test task. It's up to you. We can figure a way to merge the two implementations if you decide to go with AntTest.

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

Why do you need to do the configuration using external scripts? What do they configure? I want to get a feel for the use case before we discuss a solution.

We showed and explained this to Hans when he was here. It's a bit difficult to explain in an email, but let me try. We have the concept of multiple modules being put together to form products, and multiple products forming installs and multiple installs forming distributions. Each of these three levels (products, install, dists) have logic and therefore need configuration of that logic. For example, what modules does this product need? What is the name of the product? What native launchers does the product need, and what are it's settings (Xmx, etc.)? Similarly, installs and distributions have configurations as well.

To support this, we have three domain objects in our buildSrc that hold this information. We also have various "xxx_product.gradle" and "xxx_install.gradle" and "xxx_dist.gradle" files in our project that are used depending on what is being built. These special .gradle files are executed on the associated domain object by our settings.gradle. This allows our developers to only say what's important to them, and not have to see our giant build.gradle scripts (or our buildSrc module). What our developers actually think is Gradle is all these special scripts, they never see "true" Gradle.

The thing is that I want these special Gradle files to be very similar in treatment to normal Gradle files. All I'm really doing is extending the concepts that Gradle knows about into my own custom domain. (This ability is at the heart of what we love so much about Gradle.) Unfortunately, to do this right now I had to copy-paste some Gradle implementation code into our buildSrc (the stuff than runs a script, knows when/where to cache it, knows when to ignore the cache and rebuild it, knows how to "delegate" to an object, etc.) Every time you guys touch that stuff it breaks us, because we are using internal APIs of Gradle. The idea of this feature is to make an easy to use public API so that we don't get broken so much. It will also make it easier for others to do this same thing.

As a matter of fact, we've talked to Hans about our idea that large projects should generally be structured this way. I don't want to go into details right now (I intended to write up something more complete eventually), but most large projects have lots of concepts centered around what they are doing and the way they work. Formalizing those concepts into "extensions" to Gradle can product a much easier to use build engine that is designed for them. It's why I've always agreed that Gradle should be a toolkit. One that works out-of-the-box for simple projects, and one that lets large projects implement their own custom build engine on top of it. Part of the power of Gradle is that it can be both.

Thanks for writing this up. I agree 100% with you on the goal. I think this is an excellent pattern for large builds, where the 'build scripts' describe what to build in some high-level build language (custom or otherwise), and some build logic in the root script/buildSrc/some plugin takes care of how to build those things.

I have a different suggestion for how we solve this problem. To me, it feels like we want some unified theory of build logic composition. That is, these all feel like the same thing:

Things we do now:
- configure a Project using a plugin
- configure a Project using a build script
- configure a Gradle instance using an init script
- configure a Settings instance using a settings script

Things we want to be able to do:
- implement a plugin using a script
- configure a Project using an arbitrary script
- configure a Gradle instance using a plugin
- configure a SourceSet/Configuration/RepositoryContainer/etc using a plugin/extension
- configure an arbitrary domain object using an arbitrary script
- auto-configure a Project using scripts or plugins or java source in a well-know location (such as buildSrc)
- ...

So, I think we could get rid of Project.usePlugin(), and replace it with a general method. Let's call it 'configure' for now. In any script you would be able to do:

configure(object) { a closure }
- this is a generalisation of Project.configure(), available from any script

configure(object, 'path/to/a/script.gradle')
- executes the given script with the given object as its delegate

configure(object, SomePluginClass)
- configures the given object using the given plugin, i.e. a generalisation of Project.usePlugin()

The target object would default to the delegate of the current script, ie in a build script the target object is a Project:

configure('path/to/a/script.gradle')
configure(SomePluginClass)

We could also add some additional ways to locate the build logic artifact:

configure(object, 'path/to/a/plugin.jar')
- locates the plugin(s) in the provided jar and applies them to the given object

configure(object, 'http://some.corporate.server/global-config.gradle')
- uses the artifact (script or jar) from the given url

configure(object, 'path/to/some/directory')
- treats the directory as a Gradle project which produces a plugin jar, ie exactly the same as buildSrc

configure(object) {
dependency 'some.org:sharedConfig:1.4+'
}
- uses the artifacts (scripts or jars) from the given dependency.

Then, our existing behaviours can be implemented in terms of configure()

- init script -> configure(gradle, initScriptPath)
- settings script -> configure(settings, settingsScriptPath)
- build script -> configure(project, buildScriptPath)
- buildSrc -> configure(gradle, "$rootDir/buildSrc")
- usePlugin('name') -> configure(project, getClassForName('name'))
- usePlugin(pluginClass) -> configure(project, pluginClass)

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

From forum: gradle-dev

Re: Re: detecting if usePlugin "xyz" for a project

2009-11-23T14:18:25Z

Philip Crotwell wrote:

> Hi
>
> Just realized that the problem was that the code was running in the
> plugin init instead of the task execution so the project was not be
> completely set up at that point. I had the usePlugin "eclipse" before
> the usePlugin "scala" in the build file, so the order was backwards.
>
> So, I guess it almost works. However, because the eclipse plugin seems
> to do its checking at init time instead of task execution time, it can
> fail to properly detect the scala plugin if usePlugin "eclipse" comes
> before usePlugin "scala".

The eclipse plugins uses this kind of construct to detect whether the
java plugin has been applied:

public void use(final Project project, ProjectPluginsContainer
projectPluginsHandler) {

projectPluginsHandler.withType(JavaPlugin.class).allPlugins {...
some action ... }

}

The action passed to allPlugins() is invoked when the JavaPlugin is
applied, whether that has already happened, or whether it happens at
some point in the future.

You should do a similar thing to detect whether the scala plugin has
been applied.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-dev

Re: Adding two new features to Gradle

2009-11-23T14:17:42Z

On Mon, Nov 23, 2009 at 12:02 AM, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

Hi John and all,

> First is TestListener. This (if you can recall that far back) was the
> reason I did the listener manager changes. We need to have an init script
> that can register a listener that gets testing feedback from JUnit.

I read "JUnit", and immediately red light bulb started to blink in my
head :) - will it also work for TestNG ?

--
Tomek

Hi Tomek,

I am not very familiar with TestNG, but I would assume that it has support for listeners. If so, it would be reasonable to make it work for that as well. I will get JUnit working first, then we can see how difficult TestNG might be (I doubt it'll be hard).

Is that a good enough non-answer for you? :)

--
John Murph
Automated Logic Research Team

From forum: gradle-dev

Re: eclipse classes in gradle-core and gradle-plugins

2009-11-23T14:14:30Z

Philip Crotwell wrote:
> Hi
>
> Is there a reason that EclipseProject is in gradle-core instead of
> gradle-plugins?

We're halfway through splitting up gradle-core, and there's still some
stuff left in gradle-core which belongs in gradle-plugins.

> This means that EclipseProject can't refer to
> EclipsePlugin due to the compile order of the subprojects.
>

Generally, our tasks don't refer to the plugins. The dependency usually
goes the other way. So, it shouldn't matter that EclipseProject is in
gradle-core.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-dev

eclipse classes in gradle-core and gradle-plugins

2009-11-23T13:49:47Z

Hi

Is there a reason that EclipseProject is in gradle-core instead of
gradle-plugins? This means that EclipseProject can't refer to
EclipsePlugin due to the compile order of the subprojects.
EclipseProject is, as far as I can tell, only used in EclipsePlugin,
so it would seem like it would be better in the plugin than core, or
is there a larger plan to make ide integration that would require
being in core? This relates to my trying to get the eclipse plugin to
correctly generate eclipse .project files for scala.

thanks,
Philip

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-dev

Re: detecting if usePlugin "xyz" for a project

2009-11-23T13:34:57Z

Hi

Just realized that the problem was that the code was running in the
plugin init instead of the task execution so the project was not be
completely set up at that point. I had the usePlugin "eclipse" before
the usePlugin "scala" in the build file, so the order was backwards.

So, I guess it almost works. However, because the eclipse plugin seems
to do its checking at init time instead of task execution time, it can
fail to properly detect the scala plugin if usePlugin "eclipse" comes
before usePlugin "scala". Presumably the scala plugin detection needs
to move from the initialization to the task execution, I suppose
effectively moving the setProjectType from configureEclipseProject()
in EclipsePlugin to generateProject in EclipseProject?

thanks
Philip

On Mon, Nov 23, 2009 at 1:56 PM, Philip Crotwell <crotwell@...> wrote:

> Hi
>
> Is there a way to tell if a project uses a plugin?
>
> I tried
> project.getPlugins().hasPlugin(ScalaPlugin.class)
> but get always get false regardless. It is false even if I am inside
> the executing ecplise plugin and do a hasPlugin(EclipsePlugin.class).
>
> Perhaps a related question, why is the plugin container passed as an
> arg to Plugin.use() if it is accessuble via Project.getPlugins()? The
> second argument seems redundant, unless the Project.getPlugins() is
> not functional.
> void use(Project project,
> ProjectPluginsContainer projectPluginsHandler)
>
> My goal is to modify the EclipsePlugin in order to add the "scala
> nature" to eclipse projects if usePlugin "scala" is in the build file.
> Attached is a patch that shows what I have tried (along with some
> printlns), but this doesn't work as the hasPlugin returns false.
>
> I have created a issue for this and will upload my patch if/when I
> figure out the hasPlugin issue.
> http://jira.codehaus.org/browse/GRADLE-751
>
> Gradle 0.9-20091123133702-0500
>
> thanks,
> Philip
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: gradle-dev

detecting if usePlugin "xyz" for a project

2009-11-23T10:56:25Z

Hi

Is there a way to tell if a project uses a plugin?

I tried
project.getPlugins().hasPlugin(ScalaPlugin.class)
but get always get false regardless. It is false even if I am inside
the executing ecplise plugin and do a hasPlugin(EclipsePlugin.class).

Perhaps a related question, why is the plugin container passed as an
arg to Plugin.use() if it is accessuble via Project.getPlugins()? The
second argument seems redundant, unless the Project.getPlugins() is
not functional.
void use(Project project,
ProjectPluginsContainer projectPluginsHandler)

My goal is to modify the EclipsePlugin in order to add the "scala
nature" to eclipse projects if usePlugin "scala" is in the build file.
Attached is a patch that shows what I have tried (along with some
printlns), but this doesn't work as the hasPlugin returns false.

I have created a issue for this and will upload my patch if/when I
figure out the hasPlugin issue.
http://jira.codehaus.org/browse/GRADLE-751

Gradle 0.9-20091123133702-0500

thanks,
Philip

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

scala-eclipse.patch (3K) Download Attachment

From forum: gradle-dev

Re: Gradle Repository

2009-11-23T08:38:44Z

On Sun, Nov 22, 2009 at 19:15, Hans Dockter <mail@...> wrote:

> Hi,
>
> at the moment the Gradle build has only first level dependencies. We introduced this a while ago because there were some issues with multi-project builds and module dependencies. As module-dependencies have still issues with being published and having flat dependencies being pretty inconvenient, I'd like to switch to a standard repository based approach for dealing with transitive dependencies.
>
> Artifactory is offering free hosting for open source projects. So we would have a nice repository manage for managing our module descriptors.
>
> Thoughts?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

I've used artifactory in the past, it's a pretty decent repo manager. Nexus looks really nice, but I'm not sure what Sonatype does for hosting (or how close you'd want to get to them ;) )

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

signature.asc (285 bytes) Download Attachment

From forum: gradle-dev